Какое-то время назад я набросал несколько идей на тему того, что руководства в ХР-проекте технические писатели должны создавать, работая как часть команды разработчиков. Это вполне серьезное предложение, хотя и написано в несколько вольной форме. Давайте поразмыслим о методологии Extreme Programming, программных продуктах и руководствах к ним.

Начнем со следующего:

Каждый, кто когда-либо участвовал в создании программных продуктов, знает, что практически никто не читает руководств пользователя. Это подтверждается теми вопросами, которые поступают в службы технической поддержки. Это подтверждается и нашим личным опытом, потому что большинство из нас тоже никогда не заглядывает в руководства. К веб-приложениям руководств не пишут, но это никого не отпугивает. У некоторых таких приложений есть одна-две справочных страницы. Впрочем, у большинства из них нет ничего, кроме краткой инструкции, за которой следует набор кнопок. Все больше программных продуктов поставляется на CD-дисках, и единственное руководство, которое вы при этом получаете, имеет размер с упаковку для диска. Неплохая, кстати, идея - ученые обнаружили, что все больше и больше людей читают эти крохотные книжечки (может быть, они надеются найти в них стихи). И еще: ХР - это методология, в которой основное внимание уделяется ценности программного продукта с точки зрения бизнеса, а то что будет в конце, совсем не так важно, как то, что есть в начале.

Теперь суммируем все вышесказанное:

Создавайте ПО, которым легко пользоваться, в котором можно разобраться без толстенного тома руководства. Ну, а если вам это удалось - не пишите этот самый толстенный том! Не слушайте хлыщеватых товарищей, которые будут на все лады повторять: "но как же так, ведь наш заказчик желает получить большое толстое руководство". Ваш заказчик ненавидит толстые руководства. У него ими все полки забиты, точно так же, как у вас или у меня. Пусть ваша программа будет так же проста в использовании, как и веб-сайт. Это очень обрадует подавляющее большинство пользователей, которое все равно не будет читать "Руководство". Кроме того, это существенно уменьшит размеры "Руководства", что обрадует тех, кто-то все же будет его читать. Количество надорвавших себе спину читателей падает, количество счастливых пользователей возрастает. Акции компании выше крыши. Каждый разработчик покупает "порше". Создавайте документацию по мере работы. Запланируйте, чтобы документация отставала от разработок только на одну итерацию. Если вы (или ваш заказчик) захотите что-то изменить в этой итерации, не забудьте сообщить техническому писателю, чтобы он внес соответствующие исправления в следующей. Описать какое-либо свойство программы не сложнее, чем реализовать. Ведь если ваши программисты могут за одну итерацию изобрести и написать эту чертову штуку с нуля, то писатели должны описать ее за то же самое время, ну в крайнем случае, держаться на одну итерацию позади. В конце концов, это всего лишь составление отчета. Если писатели не успевают работать в таком темпе - что ж, суньте их пятками в камин, теперь их время подсуетиться. И пускай они через несколько лет опишут свой опыт в бестселлере "Extreme Writing - Embrace FrameMaker". Таким образом документация будет готова через две недели после окончания работы над кодом программы. Еще через две недели вы получите "Руководства" из типографии. Впрочем, если подойти к делу с умом, эти сроки можно немного подкорректировать. Например, отпечатайте "Руководство" еще до окончания работ, а потом вложите в него небольшую дополнительную книжицу, где будут описано все то, что было сделано за две последние итерации. Или еще лучший вариант: вообще не печатайте документы. Переведите их в формат HTML и разместите в Интернете или на CD с программой.

Не нравится такой вариант? Вам все-таки нужны книжки? Распечатайте их на своем принтере. Или поберегите лес: дайте людям купон для запроса документации. Многим пользователям даже в голову не придет заказать у вас "Руководство", а пересылка купона по почте даст вам неделю-другую дополнительного времени для работы над вычиткой и публикацией книжечек. Можно еще продавать "Руководства" за отдельную плату. Доходы, акции, опять-таки, все на "поршах".

Что - уже согласны? Подождите, я еще не закончил!

ХР-программисты работают с применением Непрерывной Интеграции и делают частые релизы. Маленькие релизы, помните? Значит, и ХР-писатели должны разбивать весь объем документации на маленькие порции - на каждый день, неделю, итерацию и релиз. Поверьте, они с этим прекрасно справятся, точно так же, как и программисты.

В области программных разработок Extreme Programming заставляет отказаться от весьма популярной техники под названием Extreme Business. Всем хорошо известно, что программа должна быть написана [вчера, позавчера, неделю назад - поставьте вашу дату] потому что еще нужно х дней на подготовку документации, у дней на упаковку и z - на отправку.

Интересно, что заставляет людей думать, будто уплотнить график работы программистов легче, чем попытаться уговорить писателя или отдел маркетинга работать быстрее? Наверное, потому что программисты настолько преданы своему делу, что всегда готовы поднапрячься, и настолько тугоумны, что думают, будто их напряги изменят ситуацию. Отдел доставки сам знает, что ему делать, а писатели (в отличие от программистов) всегда отличаются отменным красноречием.

Ну, давайте, укусите меня. Команда ХР-разработчиков может создать необходимый программный продукт, точно уложиться в график, да еще и сохранять контроль над тем, что войдет в поставку, а что будет отложено. ХР-команда, в которой работают технические писатели, поставит продукт в срок, а максимум через одну итерацию после этого появится и вся необходимая документация. Готов поспорить, что если писатели будут работать как часть команды с самого начала проекта, результаты будут еще более впечатляющими. И тогда всем сразу станет понятно, что вовсе не программисты ставят палки в колеса прогресса.

Теперь пускай достается отделу доставки. А вы возьмите хороших писателей и пригласите их работать в одной комнате с программистами. Не надо указывать, что они должны делать, просто пускай сидят и наблюдают, как продвигается работа над программой. Может быть, они начнут работать после первого релиза в конце итерации, может быть им будет удобнее начать с середины итерации. Бьюсь об заклад, помимо всего прочего они напишут книгу "Extreme Writing".

Extreme Programming. Вы отправляете программный продукт клиенту точно в срок, при этом продливаете срок жизни нескольким программистам и деревьям. Ей-богу, это гуманный подход! ХР - зеленая методология! Только запомните - быть зеленым очень и очень непросто!

Дизайн и поддержка: Silicon Taiga

Обратиться по техническим вопросам