Painless specs 1 ru

From The Joel on Software Translation Project

Технические задания малой кровью, часть первая: А нужно ли?

После выхода статьи "Тест Джоэла" читательские письма подтвердили, что написание технического задания является самой болезненной частью в процессе создания программного обеспечения. Техзадание сродни чистке зубов: все знают о его пользе, но делают с ленцой.

Противники технических заданий считают, что они экономят время. Они ведут себя так, будто техзадания являются привилегией космических корпораций или гигантских страховых компаний. Чепуха. На самом деле, отказ от написания техзадания является совершенно неоправданным и наибольшим риском в процессе создания программного обеспечения, таким же глупым, как попытка пересечь пустыню Мохаве налегке, без карты местности и припасов. Создавая программный код на ходу, программисты мнят себя лихими ковбоями, метко стреляющими от бедра. На самом деле они редко попадают в цель, их работа чертовски непродуктивна. Код, создаваемый ими, написан на коленке и соткан из заплаток. Рискуя без необходимости, они подвергают опасности судьбу всего проекта.

Я убежден, что любой нетривиальный проект, требующий для завершения больше одной недели или усилий больше чем одного программиста, всегда получится худшего качества и займет дольше времени, если он не будет подкреплен техзаданием. И вот почему. Основной функцией технического задания является проектирование и детальное описание изделия, в нашем случае компьютерной программы. Даже если код создается только лишь вашими усилиями, и техзадание не увидит никто кроме вас, сам процесс его написания, а именно формальное описание работы программы, заставит вас спроектировать программу.

Сравним двух вымышленных программистов. Младший научный сотрудник Быстрова из компании "Торопыжки" никогда не готовит техзаданий. "Нам не нужны дурацкие техзадания!" - считает она. В отличие от нее инженер Смыслов из фирмы "Обоснованные решения" отказывается приступать к написанию кода до тех пор, пока техзадание не будет полностью завершено.

Быстрова и Смыслов работают в разных фирмах, и единственное что их объединяет — это необходимость обеспечения обратной совместимости второй версии программных продуктов, производимых в их компаниях.

Быстрова решает, что лучшим способом обеспечить обратную совместимость является написание конвертера, который преобразует файлы первой версии в файлы второй версии. Приняв решение, она начинает выдавать код на-гора, бешено стуча по клавишам. Дым стоит коромыслом, и через две недели она завершает написание конвертера удовлетворительного качества. Но ее клиенты недовольны: выбранный способ обновления программы требует, чтобы все пользователи перешли на новую версию одновременно. Самый крупный клиент Быстровой отказывается приобретать новую программу до тех пор, пока не будет обеспечена возможность работать с файлами первой версии без конвертации. Быстрова решает написать конвертер теперь уже из второй версии в первую, и подключить его к функции "Сохранить файл". Итогом ее работы становится мешанина. Новые функции версии 2.0 работают лишь до тех пор, пока файл не будет сохранен в формате версии 1.0, о чем пользователь узнает только после записи файла на диск. С учетом дополнительных двух недель, убитых на конвертер из второй версии в первую, на проект суммарно потрачено 4 недели и результат оставляет желать лучшего.

Посмотрим теперь на Смыслова. Он один из тех, кто не выносит беспорядка и делает все согласно правилам. Смыслов отказывается приступать к написанию кода без формального техзадания. В течение двадцати минут он обдумывает как обеспечить обратную совместимость новой версии продукта, и создает следующее правило:

• Файлы от предыдущей версии программы при открытии автоматически конвертируются в файлы новой версии.

Эта формулировка предьявляется клиенту, который сразу подпрыгивает на месте: "Постойте-ка, мы не хотим переводить сразу всех пользователей на новую версию!" Смыслов еще двадцать минут обдумывает возможные варианты и изменяет формулировку следующим образом:

• Файлы от предыдущей версии программы конвертируются в новый формат непосредственно в оперативной памяти. При сохранении данных на диск пользователь имеет возможность записать их в формате новой версии либо сконвертировать обратно в старую версию.

Начальник Смыслова, верный последователь принципов объектно-ориентированного программирования, взглянув на новую формулировку, чувствует, что чего-то не хватает и, сам подумав двадцать минут, предлагает следующий вариант:

• Программный код будет предоставлять два интерфейса: V1 и V2. V1 будет содержать функции только первой версии продукта. V2 будет наследовать от V2 и добавлять функции второй версии. Функция сохранения файлов V1::Save будет использована для поддержки совместимости с файлами первой версии, в то время как V2::Save будет сохранять на диске файлы второй версии. При попытке использования новых функций с файлом старой версии программа немедленно выдаст предупреждение, после чего пользователь должен будет либо сконвертировать файл в новый формат, либо отказаться от использования новых функций.

Смыслов возвращается к своему столу, ворча. Переработка кода займет три недели вместо изначально запланированных им двух. Однако новый вариант элегантным решает все проблемы клиентов, так что Смыслов соглашается с доработками и приступает к работе.

В итоге Смыслов потратил на выполнение работы три недели и один час. Быстрова потратила четыре недели и ее результат не так хорош. Мораль этой истории в том, что любую теорию можно подгнать под нужный результат. Постойте, это не то что я хотел сказать. Мораль в том, что проектирование продукта в нормальных человеческих терминах облегчает обдумывание ситуации, выбор вариантов решения и способов улучшения продукта. Кроме того, никто не будет сожалеть о удаленном абзаце текста из файла технического описания.

Напротив, проектирование продукта сразу на языке программирования занимает недели итеративного кодирования. Что еще хуже, программист, потративший две недели на написание избыточного кода, привязывается к результату своего труда независимо от того, правилен этот код или нет. Ни начальник, ни клиенты Быстровой не смогли убедить ее выбросить замечательный код написанного ей конвертера, несмотря на недостаток избранного подхода. В результате конечный продукт "Торопыжек" является компромиссом между первоначальным ошибочным подходом и идеальным решением: "это лучшее что мы могли создать, учитывая уже написанный код, который нам было жалко выбросить". А ведь могло быть просто-напросто "лучшее что мы могли создать". Вот вам и самая главная причина для написания техзадания.

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

В отсутствие техзадания разработчики все равно вынуждены обсуждать детали проекта, просто потому что иначе они не смогут работать, но им приходится дергать друг друга при возникновении каждого вопроса. Тестеры развлекаются с программой без четкого плана и каждый раз, когда программа начинает вести себя подозрительно, они бегут к программистам чтобы в очередной раз спросить, как программа должна работать. Эти вопросы отвлекают программистов и снижают их продуктивность. Кроме того, программисты предпочитают выдавать написанный ими код за то, что программа должна делать в реальности. Таким образом, тестеры сверяют программу с программой вместо, э-э, более полезного сравнения программы с требованиями к ней.

Если проект не имеет техзадания, то самые веселые минутки выпадают техническим писателям, создающим руководство пользователя. Техническим писателям обычно не хватает наглости отрывать программистов от важных дел. Более того, во многих компаниях программисты не считают зазорным пожаловаться своему начальнику на этих [вымарано цензурой] писателей, которые своими дурацкими вопросами о том, как должна работать та или эта функция, лишь мешают работать. И тогда начальники, в попытке сохранить производительность труда, запрещают техническим писателям тратить бесценное время программистов.

Такие компании очень легко вычислить, потому что ни документация, ни файлы помощи не дают больше информации, чем может быть прочитано непосредственно с экрана. Например, для параметра

• Включить поддержку для LRF-1914?

файл помощи может выдать следующее трагикомическое описание:

• Позволяет включить (по умолчанию) или выключить поддержку для LRF-1914. Для включения поддержки LRF-1914 выберите "Да", для отказа от поддержки LRF-1914 выберите "Нет".

Ну, спасибо. Совершенно очевидно, что технический писатель был абсолютно без понятия, что такое LRF-1914, но попытался это скрыть. Он не мог получить осмысленный ответ от программиста, (а) потому что ему не хватило духа признать, что он не знает "элементарных вещей", (б) потому что программист находится в Хайдерабаде, а писатель в Лондоне, (в) потому что начальство запретило отвлекать программиста от сверхважной интеллектуальной работы, или по какой-то другой, реальной или надуманной причине. Так или иначе, но корень проблемы в том, что проект изначально не имел техзадания.

Третья сверхважная причина для создания техзадания — это необходимость составить график работы. Университетский теоретик может потратить четырнадцать лет на подготовку своей диссертации, а хакер-неформал будет полировать следующую версию игры Duke Nukem до тех пор, пока она не будет полностью готова. Но любой серьезный бизнес требует четкой информации о сроках, потому что разработка стоит денег. Как никто не купит пару джинсов, не видя ценника, так и уважающий себя бизнесмен не сможет определиться с производством продукта, не оценив заранее сроков, а следовательно, и стоимости его разработки. (Подробнее о графиках и расписаниях читайте в статье "Расписания малой кровью") Поразительно частая ошибка — это собраться для обсуждения того, как что-то должно быть сконструировано, и не принять окончательного решения. Брайан Валентайн, ведущий разработчик Windows 2000, стал известен за свою способность решать важные вопросы в течение 10 минут.

Слишком многие программистские коллективы страдают тем, что во время обсуждения структуры будущей программы никто не хочет взять на себя ответственность за окончательное решение, обычно по политическим мотивам. Поэтому программисты работают над очевидными вещами, и по прошествии времени все серьезные проблемы оказываются нерешенными. Такие проекты являются первыми кандидатами на провал. Если вы основали фирму для того, чтобы продвигать новую технологию, и регулярно испытываете трудности с принятием решений, то можете закрыть лавочку прямо сейчас и вернуть вложенные капиталы инвесторам, потому что финального продукта вы так и не дождетесь.

Техзадание позволяет спроектировать все части программы с самого начала, как существенные, так и малозначимые, и не позволить им затеряться во время выполнения работы. Например, если вы создаете веб-сайт, пользователи которого должны регистрироваться, вы можете решить высылать пароль по электронной почте тем пользователям, которые его забыли. Замечательно. Но этого еще недостаточно, чтобы приступать к кодированию, для этого нужно дословно знать содержание письма. Многие компании не доверяют своим программистам составлять сообщения, которые может увидеть конечный пользователь (и обычно не без оснований). Поэтому кто-то из отдела рекламы или сбыта, или кто-то другой с хорошо подвешенным языком, должен будет придумать точную формулировку письма. Например, "Дорогой Василий Иванович, высылаем Вам забытый Вами пароль. Постарайтесь в будущем не быть таким беспечным." Когда вы заставите себя составлять хорошие, полные техзадания (это тема следующей статьи), вы станете замечать все мелочи и либо сразу примете нужное решение, либо по крайней мере отметите проблемные места большим восклицательным знаком.

Ну вот, теперь мы с вами понимаем друг друга: техзадания — это соль земли и родная мать. Я подозреваю, что большинство читателей понимает важность техзаданий, и мои причитания, возможно увлекательные, вряд ли произвели переворот в их сознании. Так почему же люди не пишут техзаданий? Вряд ли это ради экономии времени, потому что никакой экономии в результате не получается. (Во многих организациях все техзадание умещается на одной странице текста, написанного после завершения проекта, в котором программист в телеграфной манере объясняет, как же эта штука работает, потому что ему надоело объяснять одно и то же по сто раз всем подряд.) Я думаю, причина в том, что большинство людей не любит и не умеет писать. Пустое окно текстового редактора нагоняет на них страх. Лично я преодолел боязнь письма после того, как записался на курсы в колледже, и мне было нужно писать по сочинению в неделю объемом в 3-5 страниц каждое. Навыки письма сродни накачиванию мускулов. Чем больше вы пишете, тем больше сможете написать. Если вы не можете начать прямо с техзадания, заведите дневник, запишитесь в литературный кружок или просто напишите по письму каждому родственнику или бывшему сокурснику, с которыми вы не общались уже четыре года. Все, что включает перенос слов и мыслей на бумагу, пойдет вам в дальнейшем на пользу при составлении техзаданий. Если вы руководите разработкой программного продукта, и лица, ответственные за составление техзадания, не могут и двух слов связать, закажите им двухнедельные курсы творческого письма, лучше где-нибудь на свежем воздухе, вдали от работы, в горах. Возможно, вы никогда не видели техзаданий просто потому что ваша фирма не требовала их составления. В следующей статье я покажу вам пример короткого, но полного техзадания, и мы поговорим о том, что должно в себя включать хорошее техзадание. Продолжаем!