Планирование программного обеспечения малой кровью

From The Joel on Software Translation Project

Jump to: navigation, search

Автор: Джоэль Спольски
Переводчик: AG
24 марта 2000 Оригинал: Painless Software Schedules

В предыдущем октябре (10'99 – AG) северо-восточные штаты США были покрыты толстым слоем рекламы какого-то Acela – нового экспресса Бостон-Вашингтон. Могло показаться, что телевизионные ролики, билборды и вездесущие постеры должны создать определённый спрос на новый экспресс Amtrak-а.

Что ж, возможно так и было бы. Вот только у Амтрака не были ни единого шанса узнать это. Запуск Acela откладывался раз за разом. Даже его рекламная кампания успела закончиться до того, как сам сервис стал доступен. Что напомнило мне слова одного маркетолога, который прочитал восторженный обзор своего продукта за месяц до того, как этот продукт должен был поступить в продажу. Он сказал: "Какая реклама! Очень жаль, что ты не можешь купить эту чёртову штуку".

PSSched01.jpg

Помешанные на тестостероне компании-разработчики игр любят похвастаться на своих веб-сайтах тем, что их следующая игра увидит свет, "когда будет готова". График? Не нужен нам никакой вонючий график! Мы крутые гейм-кодеры! У большинства компаний нет такой роскоши. Спросите Lotus. Когда они выкатили 123 версии 3.0, он требовал компьютер с процессором 80286, который в те времена был далеко не у всех. Они задержали выпуск продукта на 16 месяцев, в течение которых они пытались впихнуть 123 в 640K оперативной памяти, чтобы он работал на процессоре 8086. Когда им наконец удалось это сделать, Microsoft опережал их на те же 16 месяцев в разработке Excel. К тому времени (вот она - гримаса судьбы) процессор 8086 уже устарел!

Когда я пишу эту статью, пятая версия Netscape опаздывает с выходом уже почти на два года (версия 5 так и не увидела свет – AG). Частично, причина этому заключается в том, что они сделали самоубийственную ошибку, решив выбросить весь свой написанный код в корзину и начать с нуля. Та же самая ошибка, которая послала Ashton-Tate, Lotus и Эппловский MacOS в мусорную корзину компьютерной истории. В течение этого времени Netscape наблюдает за тем, как доля пользователей её браузера снизилась с около 80% до около 20% от общего количества пользователей. Всё это время Netscape не может сделать ничего, что могло бы спасти положение. Всё потому, что их основной программный продукт был дизассемблирован на 1000 мелких кусочков, рассыпан по полу, и нет никакой возможности склеить его снова, чтобы двигаться хоть в каком-нибудь направлении. Одно-единственное плохое решение более, чем что-нибудь другое, стало ядерной бомбой, которой Netscape подорвала сама себя (детали вы можете найти во всемирно известной тираде, произнесённой по этому поводу Jamie Zawinski).

Так что, ты обязан составлять график разработки. Тот самый график, которым практически ни один программист не хочет заниматься. По моему опыту, подавляющее большинство предпочтёт увильнуть, лишь бы вообще не заниматься планированием. Те немногие, кто все-таки планирует свою разработку, в основе своей делают это потому, что босс заставил их это делать. Делают они это без энтузиазма, и никто на самом деле не верит этим графикам, кроме разве что высшего руководства. Которое, в то же самое время, верит, что "ни один проект разработки ПО не может закончиться в срок", и в НЛО.

Почему же никто не составляет график разработки? Тому есть две основные причины. Первая: график – это головная боль. Вторая: никто не верит в то, что от графика будет хоть какой-нибудь толк. Зачем нужны все эти проблемы с планированием, если всё в итоге оказывается не так, как было запланировано? Если графики всегда врут, причём, чем дальше, тем прогноз всё сильнее отличается от действительности, то зачем же тогда мучиться, составляя их?

Вот тебе простой и безболезненный способ создания действительно верных графиков разработки.

1) Используй Microsoft Excel. Не используй никакие заморочки типа Microsoft Project. Проблема Microsoft Project в том, что он предполагает, будто ты тратишь кучу времени, беспокоясь о зависимостях между задачами. Зависимость – это когда у тебя есть две задачи, одна из которых должна быть решена прежде, чем начнется другая. Мой опыт говорит, что при разработке программного обеспечения зависимости настолько очевидны, что просто не стоит даже напрягаться, чтобы формально их отслеживать.

Ещё одна проблема с Project в том, что он предполагает, будто ты можешь вдруг захотеть нажать кнопочку и "пересчитать" (rebalance) график. Как следствие, это означает, что Project постарается перестроить задачи и переназначить их другим людям. Для программного обеспечения всё это не имеет никакого смысла. Программисты не взаимозаменяемы. Чтобы исправить баг Риты, Джону требуется в семь раз больше времени, чем это займёт у самой Риты. А если вы попробуете назначить разработчику пользовательского интерфейса решение проблемы с WinSock, она просто встанет и потеряет неделю на то, чтобы приобрести навыки работы в программировании WinSock. Суть в том, что Project был спроектирован для строительства зданий, а не для разработки программного обеспечения.

2) Будь проще. Стандартный формат, который я использую для ведения графиков, достаточно прост, чтобы его можно было легко запомнить. Просто начни с семи колонок:

PSSched02.jpg

Если у вас несколько разработчиков, ты можешь либо отвести каждому отдельный лист, либо добавить ещё одну колонку с именем разработчика, работающего над конкретной задачей.

3) Каждая фича (feature) может содержать несколько задач. Пример фичи – "Реализовать проверку грамматики". Чтобы "Реализовать проверку грамматики", программисту понадобится решить несколько отдельных задач. Самая важная часть в составлении графика – создать этот список задач. Вот основное правило:

4) Только программист, который будет писать код, может оценить время на решение задачи. Любая иная система планирования, в которой руководство составляет график, после чего вручает его для исполнения программистам, обречена на провал. Только программист, который будет работать над задачей, может представить себе, какие шаги ему предстоит сделать, чтобы реализовать данную фичу. И только программист может оценить время, которое потребует каждая из его задач.

5) Задачи должными быть небольшими и чётко сформулированными. Это наиболее важная часть в составлении работающего плана. Задачи должны измеряться в часах, а не днях. (Когда я вижу график, измеряемый в днях, или даже неделях, я знаю, он – нереален.) Тебе может показаться, что график с мелкими задачами лишь чуточку более точен. Ошибка! Большая ошибка! Если ты начинаешь работать с планом, в котором лишь крупные задачи, а затем попытаешься разбить их на более мелкие подзадачи, то обнаружишь, что получается совершенной другой результат. Не просто чуть более точный. Совершенно другой. Почему же так происходит?

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

Когда же ты крупными мазками набрасываешь несколько задач (типа "реализовать исправление грамматических ошибок") в план, это означает, что ты не очень-то задумываешься о том, что и как конкретно предстоит сделать. А когда ты не думаешь, что конкретно тебе нужно будет сделать, ты не очень-то и знаешь, сколько времени это займёт.

Вот тебе практичное правило: каждая задача должна длиться от 2 до 16 часов. Если у тебя есть в плане 40-часовая задача (на неделю), это значит, что ты не достаточно разложил ее по полочкам.

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

PSSched03.jpg

6) Отслеживай начальное и текущее ожидания. Когда задача только появляется в плане, оцени, сколько часов возьмёт её реализовать, и помести это значение в колонки Orig[inal] Est[imate] и Curr[ent] Est[imate]. Со временем, если задача оказывается больше (или короче), чем ты предположил вначале, ты можешь корректировать значение в колонке Curr Est по мере необходимости. Это лучший способ учиться на своих ошибках и обучаться тому, как оценивать время лучше. Большинство программистов не имеют ни малейшего понятия, с какого бока подойти к проблеме оценки времени. Это нормально. Пока ты постоянно учишься работать с планом и постоянно корректируешь план по мере обучения, план всё время остаётся в актуальном состоянии. (Вы можете убирать фичи из него или смещать сроки, но план всё равно будет корректен в том смысле, что он в любой момент сможет сообщить текущее состояние и подсказать, что пора убирать из него фичу или изменить оценку времени.) Я обнаружил, что большинство программистов становятся доками в планировании в течение одного года.

Когда задача окончена, значения в полях Curr Est и Elapsed становятся одинаковыми, а поле Remain становится равным 0.

7) Обновляй значение в колонке Elapsed каждый день. На самом деле тебе не нужно с секундомером отслеживать время, в течение которого ты пишешь код. Непосредственно перед уходом домой или перед тем, как лечь спать под стол (если ты один из тех гиков, которые прикидываются работающими непрерывно 8 часов (ха!)), прикинь, над какими задачами работал сегодня, и разбросай +/- 8 часов в колонке Elapsed между этими задачами. Поле со временем, которое ещё осталось на решение задачи (Remain), Excel посчитает автоматически.

В то же время обнови значения в колонке Curr Est по тем задачам, где это кажется тебе необходимым, чтобы план отражал твоё новое понимание ситуации. Ежедневное обновление плана должно занять около двух минут твоего времени. И это – причина того, почему Метод Планирования Малой Кровью так лёгок и прост.

8) Включай в план отпуска, праздники и т.п. Если график охватывает период около года, то весьма вероятно, что каждый программист 10-15 дней за это время побывает в отпуске. В вашем плане должна быть возможность указать "отпуск" (неважно, отпуск это, праздники или ещё что). Идея в том, чтобы посчитать дату поставки продукта, добавив время отпуска к значению в колонке Remain и поделив сумму на 40. Полученное значение -- это количество недель, которые остались до окончания работ с учётом всего-всего.

9) Учитывай в плане время, необходимое для отладки! Время, которое понадобится на отладку, сложнее всего предсказать. Вспомни последний проект, в котором ты работал. Весьма вероятно, что время, понадобившееся на отладку, составило от 100% до 200% от времени, которое заняло собственно кодирование. Так что в плане должна быть отдельная строка, и, возможно, это будет самая тяжёлая строка.

Вот, как это работает. Скажем, разработчик работает над wawa. Начальная оценка времени (Orig Est) была – 16 часов. Однако к настоящему моменту на задачу уже ушло 20 часов. И дела обстоят так, что понадобится ещё часов 10, чтобы закончить работу. Разработчик вписывает 30 часов в колонке Curr Est и 20 часов – в колонке Elapsed.

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

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

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

2) Исправление ошибок подобно научным исследованиям. Одинаково невозможно предсказать, когда ты сделаешь открытие или исправишь ошибку. Если в каждый конкретный момент времени имеется 1-2 ошибки, нетрудно предположить, что продукт будет готов в срок, поскольку в ближайшее время тебе не предстоят обширные научные изыскания. С другой стороны, если имеются сотни или тысячи неразрешённых дефектов, совершенно невозможно предсказать, когда все они будут разрешены.

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

10) Учитывай в плане время на интеграцию. Если у вас больше одного программиста, неизбежно найдутся несовместимые моменты в коде двух программистов, которые понадобится привести в соответствие. Возможно, оба программиста пишут однотипные диалоговые окна. И с этим проблем с несовместимостью нет. Но кто-нибудь третий должен пройтись по всем меню, шорткатам, панелям инструментов и т.п., чтобы единообразно организовать всё новые пункты меню. Компиляционные ошибки не заставят себя ждать, как только несколько человек запишут свой код в систему контроля версий. Подобные ошибки тоже надо исправлять. И на это требуется время и отдельная строчка в плане.

11) Внеси буфер в план. Жизнь такова, что сроки зачастую нарушаются. Тебе следует учесть 2 важных буфера. Первый – это резервное время для тех задач, решение которых потребовало большего времени, чем было запланировано. Второй – это буфер для задач, которых не было вначале и которые появились в середине разработки. Обычно, это происходит потому, что руководство вдруг решило, что реализовать фичу wawa – АРХИВАЖНО. Поскольку эта фича никак не может подождать до следующей версии.

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

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

Если твой руководитель приказывает тебе умерить аппетит и сократить время на разработку, вот что следует сделать. Добавь новую колонку в таблицу с планом. Назови её "Kolya's Estimate" (если, конечно, тебя Колей зовут). Помести в эту колонку свою начальную оценку времени. Теперь пусть твой менеджер делает в колонке Curr Est всё, что ей заблагорассудится. Просто игнорируй оценку руководства. Когда проект будет завершён, посмотрим, кто был ближе к реальности. Я обнаружил, что одна только угроза добавить такую колонку в график творит чудеса. Особенно, когда твой менеджер сообразит, что он только что записался участвовать в конкурсе "Давай-ка посмотрим, насколько медленно ты можешь работать!"

Так почему же глупые менеджеры пытаются заставить программистов уменьшить их оценки?

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

Глупые менеджеры пытаются решить эту проблему, придумывая, как бы заставить людей работать быстрее. Звучит не слишком реалистично. Возможно, вам удастся нанять больше людей. Однако им требуется время на разогрев. Вероятно, в течение нескольких месяцев новые сотрудники будут работать с эффективностью 50% (одновременно снижая продуктивность своих наставников). В любом случае, на этом рынке добавить в проект хорошего программиста занимает около 6 месяцев.

Возможно, вам удастся получать от людей на 10% больше сырого кода в течение непродолжительного времени. Однако люди при этом сгорят на 100% за один год. Не слишком крупный выигрыш; больше похоже на отпиливание ветки, на которой сидишь.

Возможно также, что вы получите от них на 20% больше сырого кода, призывая всех и каждого работать ещё упорнее, не взирая на то, как они устали. Ба-бах! Время на отладку увеличилось вдвое. Дурацкий шаг, который бумерангом вернулся и стукнул вас в лоб.

Но совершенно определённо, что вам никогда не добиться 3N из одного N. И если вы думаете, что вам это удастся, пожалуйста, сообщите мне биржевой символ акций вашей компании (stock ticker), чтобы я мог вовремя от этих акций избавиться.

13) План подобен деревянным кубикам. Если у вас имеются несколько деревянных кубиков, которые вы не можете поместить в коробку, то у вас есть два варианта: либо взять бОльшую коробку, либо выбросить часть кубиков. Если вы думаете, получится ли выпустить продукт через 6 месяцев притом, что график показывает вам 12 месяцев, вы либо должны отсрочить выпуск, либо выбрать функции, которыми следует пожертвовать. Вы не можете просто взять и уменьшить кубики. И если вы делаете вид, что способны на это, то это значит, что вы просто обманываете самого себя и лишаете тем самым самого себя возможности действительно заглянуть в будущее.

И знаете, ещё один замечательный побочный результат описанного здесь подхода к планированию заключается в том, что ты вынужден удалять фичи. Почему это хорошо? Предположим, требуется реализовать две фичи. Одну, действительно полезную, которая будет выделять ваш продукт среди аналогичных продуктов (например, таблицы в Netscape 2.0). И вторую, реализовать которую достаточно легко, такие обычно любят кодировать программисты (например, тег BLINK), но которая при этом абсолютно бесполезна, как для пользователей, так и для маркетологов.

Если ты не составишь график, программисты займутся сначала лёгкими/интересными фичами. Затем закончится время, и тебе не останется ничего иного, кроме как передвинуть график, чтобы таки реализовать полезные/важные фичи.

Если ты составишь график, то ещё до начала разработки сможешь понять, что чем-то придётся пожертвовать, чтобы уложиться в срок. Имея график, ты вычеркнешь из него лёгкие/интересные фичи и оставишь полезные/важные. Заставляя себя отбирать фичи для заклания, ты придёшь к тому, что начнёшь создавать более мощные, лучшие продукты с лучшим набором хороших функций и делать это в более короткие сроки.

Я вспоминаю время, когда мы работали над Excel 5. Начальный список функций был огромен, было очевидно, что мы не уложимся в срок, если станем реализовывать их все. "Ну и ну!" думали мы. Каждая из этих функций супер важна! Как же мы сможем прожить без визарда редактирования макросов?

Как оказалось, у нас не было выбора. Мы выбросили из графика те функции, которые считали основой нашего плана, чтобы уложиться в срок. Никто не был счастлив, отказываясь от них. Чтобы хоть как-то утешиться, мы убеждали самих себя, что мы не выбрасываем эти фичи, мы их просто откладываем до версии Excel 6, поскольку они чуть менее важны.

PSSched04.jpg
Когда Excel 5 был уже почти готов, мы с моим коллегой Eric Michelman приступили к созданию спецификаций на разработку Excel 6. Мы просмотрели список "функций Excel 6", от которых в своё время отказались при составлении плана разработки 5-й версии Excel. Мы были в шоке от этих функций, которые представляли собой самый претенциозный список функций, который вы себе только можете представить. Ни одна из функций в этом списке не стоила реализации. Не думаю, что хотя бы одна из них была сделана в последующих трёх версиях Excel. Процесс отбраковки функций, который мы предприняли, чтобы уложиться в срок, был лучшим шагом, который мы только могли предпринять. Если бы мы этого не сделали, разработка Excel 5 заняла бы в два раза больше времени, причём половина функций в нём была бы абсолютно бесполезна. (У меня нет никаких сомнений в том, что именно так и получилось в случае с Netscape 5/Mozilla: у них не было графика; у них, определённо, не было списка функций; никто не захотел заняться отбором функций; продукт просто-напросто не увидел свет. Если это таки случится, в нём будет множество функций типа IRC client, на которые просто не имело смысла тратить время.)

Приложение: То, что ты должен знать об Excel

Одна из причин, делающих Excel великолепным инструментом для планирования разработки программного обеспечения, заключается в следующем: большинство программистов, создавших Excel, сами использовали его с единственной целью, – чтобы вести в нем свои графики! (Следует знать, что очень немногие из них использовали в работе бизнес-сценарии what-if)

Shared Lists. Использование команды Tools/Share Workbook (в Excel 2000, или подобная команда в других версиях – AG) позволяет всей команде работать с файлом одновременно. Поскольку каждый участник группы разработки обязан обновлять информацию в графике, это очень полезная фича.

Auto Filter – это великолепная возможность отфильтровать график удобным для тебя образом. Например, ты можешь посмотреть только те фичи, которые назначены только тебе. В комбинации с функцией автоматической сортировки (Auto Sort), ты можешь получить список назначенных тебе функций, упорядоченных по убыванию приоритетности. Таким образом, перед тобой – список "to do". Крута!

Pivot Tables – это отличный способ подвести итоги и свести воедино данные из разных таблиц. Например, ты создаёшь диаграмму, на которой нужно показать оставшиеся часы по каждому разработчику в соответствии с приоритетностью задач. Pivot Tables подобны булочкам и шоколадно-молочному коктейлю. Тебе следовало бы изучить, как ими пользоваться, поскольку они делают Excel в миллион раз более мощным инструментом.

Функция WORKDAY из Analysis Toolpak Excel-я – это замечательный способ выводить календарные даты при Планировании малой кровью.


Небольшой ФАК по этой статье: Juggling Tasks in Excel.

Safari Software предоставляет бесплатный шаблон для Excel (MasterList-XL) для управления задачами на базе изложенных в этой статье принципов.

Personal tools