Планирование программного обеспечения малой кровью
| Joel on Software Джоэл о программном обеспечении | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
Автор: Джоэл Сполски Переводчик: Вадим Никитин 29 марта 2000 В прошедшем октябре, Северо-восточные США были обклеены объявлениями о некоем новом поезде-экспрессе называемом Acela, двигающимся от Бостона до Вашингтона. Можно было подумать, что такое количество рекламы на ТВ, объявлений и плакатов повсюду, создаст некоторый спрос на новую экспресс-службу Amtrak. Возможно, –Amtrak-у так и не удалось выяснять это. Acela был отсрочен, и отсрочен снова, маркетинговая кампания прошла, а Acela так и не начал работать. Это напомнило мне другой случай: менеджер по маркетингу говорил, когда его изделие получило бредовый обзор за месяц до поступления в продажу: "Огромная реклама! Плохо, что Вы не можете купить чёртову вещь!"  Теперь, когда я это пишу, появился web браузер Netscape 5.0 почти с двухгодичным опозданием. От части, из-за их самоубийственной ошибки: они выбросили все свои исходные тексты и начали сначала. Та же ошибка что и обрёкшая Ashton-Tate, Lotus, и Apple MacOS стать хламом истории софта. Netscape увидели как распространение их браузера шагнуло от около 80% до около 20%, и всё это время они ни чем не могли ответить конкурентам, потому что их ключевой продукт был разобран на 1000 кусков, так что нельзя было выявить ни каких контуров (was disassembled in 1000 pieces on the floor and was in no shape to drive anywhere).
3) Каждое свойство должно состоять из нескольких задач. Свойство, это нечто вроде добавления проверки орфографии к вашей программе. Добавление проверки орфографии состоит из нескольких совершенно отдельных задач, которые программист должен сделать. Наиболее важная часть создания плана, это составление списка задач. Таким образом кардинальное правило: 4) Только программист, который будет писать данный код, может распланировать его. Любая система, где начальство пишет план и вручает его программистам, обречена на неудачу. Только программист, который будет делать данную работу, способен определить, какие шаги нужно предпринять, чтобы реализовать данное свойство. И только программист сможет оценивать, сколько времени займёт каждый шаг. 5) Ставьте очень мелко дроблёные задачи. Это наиболее важная часть в вашей работе по составлению плана. Ваши задачи должны измеряться в часах, а не в днях. (Когда я вижу план, измеряемый в днях, или даже в неделях, я знаю –он не реален). Возможно вы думаете, что план с мелко дроблёными задачами просто более точен. Неправильно! Очень сильно ошибаетесь! Когда вы начнете с плана с грубо определенными задачами и затем разобьёте его на меньшие задачи, вы увидите, что получили другой результат, не просто более точный. Это будет полностью другое число. Почему так получается? Когда вы ставите мелко дроблёные задачи вы вынуждаете себя фактически вычислять то, какие шаги вы предпримите. Написать подпрограмму foo. Создать диалог такой и такой. Прочитать файл wawa. Эти шаги просто оценить, потому что прежде вы уже писали подпрограммы, создавали диалоги, и читали файлы wawa. Если вы неаккуратны и ставите большие "короткие" задачи ("реализовать исправление грамматики"), то вы в действительности не думали, что вам предстоит сделать. Поскольку вы не думали, что собираетесь делать, вы просто не можете знать, сколько времени на это потребуется. Как правило, каждая задача должна быть от 2 до 16 часов. Если у вас в плане стоит задача на 40 часов (одна неделя), значит вы не достаточно её разбили. Имеется другая причина устанавливать мелкодроблёные задачи: это вынуждает вас разрабатывать проклятое свойство. Если у вас в программе будет некое сомнительное свойство, названное "Межсетевая Интеграция" и вы на него планируете недели, то вы обречены, приятель. Если же вам нужно определить, какие подпрограммы вы собираетесь написать, то вы вынуждены выявить свойство. Заставляя себя планировать вперед на этом уровне, вы устраняете много неустойчивости в программном проекте.  6) Отслеживайте начальную и текущую оценку. Когда вы впервые добавляете задачу в план, оцените, сколько она займёт в часах и поместите свою оценку в поля Нач [альная] и Тек [ущая] Оценка. По прошествию времени, если задача оказалась более долгой (или короткой) чем вы думали, вы можете изменить столбец Тек Оцн так как вам необходимо. Это лучший способ учиться на собственных ошибках и тренироваться, оценивать задачи точно. Большинство программистов не имеют понятия, как сделать предположение, относительно продолжительности дел. Это - нормально. Пока вы непрерывно изучаете и непрерывно модифицируете план, в процессе своего обучения, - план работает. (Возможно, вам придется исключить какое-либо свойство или устранить неточность [в оценке времени], но план по прежнему будет работать правильно, в том смысле, что будет постоянно сообщать вам, когда вам нужно удалить свойство или исправить неточность). Я обнаружил, что большинство программистов становятся очень хорошими планировщиками после приблизительно одного года опыта. Когда задача выполнена, поля Тек Оцн и Прошло будут равны, а поле Осталось пересчитается в 0. 7) Обновляйте столбец Прошло каждый день. На самом деле вам не надо смотреть на секундомер, кода вы программируете. Перед самым вашим уходом домой, –или уходом ко сну за столом, если вы один из тех балбесов, симулирующих, что работают 8 часов (ха-ха!), - определите над какими задачами вы работали и раскидайте соответственно около 8 часов в столбце Прошло. Поле оставшегося времени Excel вычислит автоматически. Заодно исправьте и колонку Тек Оцн для своих задач чтобы отразить новую действительность. Ежедневное модифицирование вашего плана отнимет у вас не более двух минут. Вот почему это безболезненный способ - он быстр и прост. 8) Добавьте строки для Праздников, Отпуска, и т.д. Если ваш план будет охватывать более года, каждый программист вероятно возьмёт 10 - 15 дней отпуска. Вам необходимо свойство в вашем плане называемое Выходные, одно для праздников, и что-то ещё для всего остального, что потребляет народное время. Идея состоит в том, что дата отгрузки может быть вычислена, делением на 40 суммы по столбцу оставшегося времени, получится - сколько осталось недель работы, включая полностью всё. 9) Поместите в план время отладки! Отладка самая трудная вещь для оценки. Вспомните последний проект, в котором вы принимали участие. Есть шанс, что отладка займёт от 100 до 200 % времени, которое потребует написание кода в первой редакции. Так что нужен строковый элемент в плане. И, вероятно, это будет самый большой строковый элемент. Вот как это работает. Скажем, разработчик работает над wawa. Нач Оцн была 16 часов, но на данный момент затрачено 20 часов и, похоже, потребуется ещё дополнительно 10 часов работы. Так что разработчик вводит 30 под Тек Оцн и 20 под Прошло. Неточности вероятно будут. (At the end of the milestone, all these "slips" have probably added up to quite a bit). Теоретически, чтобы компенсировать неточности и обеспечить своевременный выход продукта, мы должны исключить какие-нибудь свойства. Хорошо если первое свойство, которое мы сможем исключить, будет большое-пребольшое свойство называемое Буфер, под которое выделено много-премного часов. В принципе, разработчики отлаживают код, в процессе написания. Программист не должен ни когда работать над новым кодом, если он может за место этого исправлять ошибки. Количество ошибок всегда должно оставаться на столько малым, на сколько это возможно, по двум причинам: 1) Проще устранить ошибки в тот же день, в который вы написали код. Это может оказаться очень трудным и долгим - исправлять ошибки месяцем позже, когда вы уже забудете, как в точности работает код. 2) Исправление ошибок - подобно научным исследованиям. Невозможно предугадать, когда вы совершите открытие и найдёте ошибку. Если имеются только одна или две не обработанных ошибки в любое заданное время, то будет просто оценить время выхода программы, потому что в вашем будущем не будет слишком много не поддающейся оценке науки. С другой стороны, если имеются сотни или тысячи ожидающих обработки ошибок, невозможно предсказать, когда все они будут исправлены. Если разработчики всегда устраняют ошибки, по ходу своего продвижения вперёд, что за прикол в наличии строкового элемента для отладки? - Хорошо, даже если вы будете устранять каждую ошибку, по мере своего продвижения, в конце каждого этапа неизбежно будет куча работы над ошибками, когда тестеры (свои и бета) найдут по настоящему трудные ошибки. 10) Добавьте в план время на интеграцию. Если у вас больше одного программиста, неизбежно, возникнут вещи, которые они будут делать противоречиво, и эти противоречия должны быть разрешены. Они могут одновременно разрабатывать диалоговые окна для подобных задач, - это излишняя непоследовательность. Кто-то должен будет пройти через все меню, акселераторы клавиатуры, кнопки на панелях и т.д., приводя в порядок все новые элементы меню, которые народ вольно - невольно добавлял. Будут появляться ошибки компиляции, которые вылезают, как только два человека загрузят код в систему контроля версий. Это должно быть исправлено, и для этого нужен строковый элемент в плане. 11) Добавьте буфер в план. Вещи склонны ускользать. (Things tend to run over). Есть два важных вида буфера, которые вам могут понадобиться. Во-первых, буфер для учёта задач, занявших больше времени, чем было первоначально оценено. Во-вторых: буфер для учёта задач, о которых вы не знали, что вам придётся их делать, обычно потому, что начальство решило, что разработка wawa СУПЕР ВАЖНА и не может быть отложена до следующего выпуска. Возможно, вы удивитесь, узнав, что праздники, отпуска, отладка, интеграция, и буферное время вносят больший вклад, [в общую длительность проекта] чем фактические задачи. Если это вас удивляет, значит, вы не участвовали в длительных проектах, не так ли? Опасно игнорировать это. 12) Никогда, не позволяйте менеджерам ни при каких обстоятельствах, указывать программистам, уменьшать оценку времени. Много начинающих программных менеджеров думают, что они могут "мотивировать" своих программистов, работать быстрее, давая им симпатичные, "плотненькие" (нереально короткие) планы. Я думаю, что этот вид мотивации - без мозгов (brain-dead). Когда я отстаю от плана, я чувствую себя обреченным, попадаю в депрессию, становлюсь неактивным. Когда я работаю с опережением плана, я весел и производителен. План - не место, для психологических игр. Если ваш менеджер заставляет вас уменьшить оценку времени, есть что делать: Создайте новый столбец в плане, с именем Оценка Рика (предположим вас зовут Рик). Поместите туда свою оценку. Позвольте вашему менеджеру делать всё что угодно с колонкой Нач Оцн. Игнорируйте его оценку. Когда проект выполнен, посмотрите, кто был ближе к действительности. Я обнаружил, что стоит только пригрозить поступать так, как произойдут чудеса, особенно, когда ваш менеджер увидит, что он добился только того что попал на конкурс под названием "как медленно вы можете работать"! Почему непутёвые менеджеры пытаются заставить программистов снижать оценки времени? Когда проект начинается, технические менеджеры уходят, встречаются с деловыми людьми, и появляются со списком свойств, который, как они думают, займёт около 3-х месяцев, но в действительности он займёт 9. Когда вы думаете о написании кода без учёта всех шагов, которые предстоит сделать, всегда кажется, что потребуется n времени, хотя реально, скорее всего, потребуется 3n. Когда вы составляете реальный план, вы складываете все задачи и понимаете, что проект оказывается намного более длинный чем казалось сначала. Действительность погружается [куда-то] (Reality sinks in). Непутёвые менеджеры пытаются ответить на это, прикидывая, как заставить людей, работать быстрее. Это не очень реально. Возможно вы способны нанять больше людей, но им нужно ещё выйти на заданную скорость, возможно они и станут работать на 50% эффективнее в течение нескольких месяцев (при этом понижая эффективность тех кто должен выполнять роль их наставников). Во всяком случае, на этом рынке, добавление хороших программистов может позволить уложиться в 6 месяцев. Возможно, вы способны добиться от людей на 10% большего выхода исходных текстов, временно, той ценой, что вы заставите их сгореть на 100% за год. Не большой прирост, притом, что это напоминает поедание зерна предназначенного для посева. Возможно вы способны добиться от людей на 20% большего выхода исходных текстов, прося каждого работать супер тяжело, независимо от того, насколько он устал. Ажиотаж, время отладки удвоится. Идиотский шаг который блестяще отзовется на [вашем] кармическом пути. Но вы никогда не добьётесь 3n из n, ни при каких обстоятельствах, а если вы думаете, что добьётесь, пожалуйста пришлите мне по е-мэйл график биржевых котировок акций вашей компании, чтобы я мог сыграть на понижение (email me the stock ticker of your company so I can short it). 13) План подобен деревянным кубикам. Если у вас есть набор деревянных кубиков, и вы не можете уложить их в коробку, то у вас два варианта, или взять большую коробку, или удалите несколько кубиков. Если вы считали что сможете обеспечить выход в свет через 6 месяцев, но по плану получается 12, то вы оказываетесь перед необходимостью или задержать выход, или отобрать некоторые свойства которые придётся удалить. Однако вы не способны уменьшить кубики, и если вам кажется, что вы способны, значит вы просто лишаете себя полезной возможности реально смотреть в будущее, обманываете себя относительно того что вы там видите. А вы знаете, это крутой побочный эффект - то, что вы будете вынуждены удалять свойства. Почему это хорошо? Предположим, что у вас есть два свойства: одно, которое является действительно полезным и сделает ваш продукт действительно крутым (например: таблицы в Netscape 2.0), и другое, которое является действительно простым, одним из таких которые программисты любят реализовывать (например: BLINK tag), но оно не служит никаким полезным или маркетинговым целям. Если вы не составили план, то программисты в первую очередь будут делать лёгкие/прикольные свойства. Затем они исчерпают время, и у вас не будете никакого выбора, кроме как распрощаться со своими планами сделать некое полезное/важное свойство. Если вы начнёте составлять план, ещё до того как приступите к работе, вы поймете, что нужно удалить кое-что, таким образом, вы удалите лёгкое/прикольное свойство, и будете делать как раз полезное/важное свойство. Заставляя себя выбрать свойства от которых придётся отказаться, вы как бы включаете быструю перемотку вперёд, в создании более мощного, лучшего продукта с лучшим составом хороших свойств, который быстрее будет выпущен. Помню я работал над Excel 5. Наш исходный список свойств был огромен и уходил далеко за пределы плана. Ё моё! - вот что мы себе говорили. Все эти свойства - супер важные! Ну как нам жить без мастера редактирования макросов? Получилось так, что у нас не было выбора, и мы поудаляли, как нам казалось, самый костяк плана. Каждый чувствовал себя несчастным из-за этого. Чтобы успокоить наши чувства, мы просто сказали себе, что мы не удалили свойства, а просто отложили их до Excel 6, так как они были менее важные.  Приложение: То что вы должны знать об Excel Одна из причин, по которой Excel –такое крутое средство работы с софтверными планами –та же самая по которой большинство Excel-программистов используют его для своих софтверных планов! (Не многие из них используют бизнес-сценарии "что если"... здесь они –программисты!) Общий доступ Используйте команду Сервис/Доступ к книге чтобы каждый мог в одно время с другими открывать и редактировать план. Так как вся ваша группа постоянно будет модифицировать план, то это действительно помогает. Автофильтр –крутой способ фильтровать план так, чтобы, например, видеть только назначенные вам свойства. В комбинации с сортировкой, он даёт возможность видеть только назначенные вам свойства в порядке важности, это уже реально ваш список "что сделать". Отлично!!! Сводные таблицы –крутой способ смотреть итоги. Например, можно сделать диаграмму, показывающую оставшиеся часы по каждому разработчику по каждому приоритету. Сводные таблицы подобны пирожному со взбитыми сливками. Вы обязаны узнать, как ими пользоваться потому что они делают Excel в миллион раз мощнее. Функция WORKDAY из пакета анализа Excel –крутой способ получать календарные даты из Безболезненного плана. В английском оригинале статья называется | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Джоель Спольски - основатель , небольшой компании по разработке программного обеспечения, расположенной в Нью-Йорке. Окончил Йельский Университет, работал программистом и управляющим в Microsoft, Viacom и Juno. |
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
