Эта книга харизматических лидеров экстремального программирования — о том, как планировать проекты разработки программного обеспечения по технологии XP. В основном она предназначена руководителям — тем, кто должен составлять план работ, а потом следить, чтобы он соответствовал действительности. Она будет полезна и программистам с заказчиками, поскольку это две основные роли в процессе планирования и разработки ПО.
Содержание
Предисловие
Введение
От переводчиков
От издателя перевода
Благодарности
Глава 1. Для чего существует планирование?
Почему мы должны планировать?
Каким должно быть планирование?
Ловушка планирования
Глава 2. Страхи
Неучтенные страхи — основной источник провала любого проекта
«Билль о правах» заказчика
«Билль о правах» программиста
Глава 3. Программирование как вождение автомобиля
Глава 4. Равновесие политических сил
Заказчик
В поисках заказчика
В помощь заказчику
Глава 5. Два введения в методологию
Сверху вниз
Снизу вверх
Глава 6. Слишком много дел
Глава 7. Четыре переменные
Стоимость
Качество
Время и объем работ
В магазин за… функциональностью
Глава 8. Вчерашняя погода
Притча
Как это выглядит
Глава 9. Объем проекта
Большой План
Так что нас беспокоит?
Притча на тему
Глава 10. Планирование версий
Кто должен планировать выпуск версий?
Будет ли план стабильным?
На какой срок планировать?
Как планировать разработку инфраструктуры?
Как оформлять план выпуска версий?
Сколько задач планировать на следующую версию?
Главы, посвященные планированию версий
Глава 11. Пожелания заказчика
Наиболее важные моменты
Оценка трудозатрат: чем вам может помочь заказчик
Приоритет пожеланий
Полный контроль
Дробление пожеланий
Украшательства
Процесс записи пожеланий заказчика
Когда все пожелания заказчика окажутся на бумаге?
Хранение карточек с пожеланиями заказчика
Примеры пожеланий заказчика
Глава 12. Оценка трудозатрат
Объем задачи
Сколько можно успеть сделать за одну итерацию
Идеальное время
Уточнение первоначальных оценок
Глава 13. Порядок реализации пожеланий заказчика
Ценность пожелания с точки зрения заказчика
Технический риск
Так что же выбрать?
Примерный план выпуска версий системы
Глава 14. События, влияющие на планирование версий системы
Смена приоритетов в пожеланиях заказчика
Добавление нового пожелания
Переработка плана
Глава 15. Первый план
Разработка первого плана
Выбор продолжительности итерации
С чего начать?
Глава 16. Варианты планирования версий
Частые выпуски версий системы
Редкие выпуски версий системы
Небольшие пожелания
Пространственное мышление
Глава 17. Планирование итерации
Никогда не сдвигайте сроки!
Глава 18. Собрание по планированию итерации
Перечень пожеланий заказчика
Перечень задач в данной итерации
Технические задачи
Определение скорости работы программиста
Распределение задач и оценка трудозатрат
Грязная работа
Слишком много работы
Слишком мало работы
Пример плана итерации
Глава 19. Контроль над ходом итерации
Проверка хода итерации
Пример тесного сотрудничества
Всем поровну
Катастрофическое отставание
Если у программиста остается свободное время
Когда итерацию можно считать законченной?
Когда реализацию пожелания можно считать законченной?
Пример контроля над ходом итерации
Глава 20. «Стоячие» собрания
Глава 21. Иллюстрации
Примеры
Продуктивность
Эта сложная интеграция
Выбор нужных графиков
Глава 22. Жучки
Что делать, если в поставленной системе обнаружен дефект?
Команда поддержки
Борьба с критичными для системы дефектами
Глава 23. Изменения в команде
Новые сотрудники
Увольнение
Дробление команды
Профессиональный рост
Глава 24. Инструментарий
Глава 25. Договор с заказчиком
Разработка заказного ПО
Внутренние проекты
«Коробочный» продукт
Глава 26. Красные флажки
Неправильные оценки объемов работ
Заказчики не хотят принимать решения
Ошибки в системе
Концы с концами не сходятся
Не получаются ежедневные сборки системы
Заказчик не доводит проект до конца
Глава 27. Ваша собственная методология
Список терминов
Алфавитный указатель
ОТРЫВОК
Для чего существует планирование?
Ах, милый, ты не одинок:
И нас обманывает рок.
Роберт Бернс, «Полевой мыши, гнездо
которой разорено моим плугом»
Мы планируем, чтобы всегда заниматься только наиболее важными на текущий момент задачами. Мы планируем, чтобы согласовывать свою деятельность с деятельностью других людей и успевать вовремя реагировать на неожиданные события.
Однажды, когда Кенту было лет десять, он в компании таких же мальчуганов впервые в жизни отправился удить форель. Целый день прошел в бесплодных попытках поймать рыбу. И вот, уставшие и голодные, ребята решили повернуть к дому. Через полчаса блужданий по густому лесу они поняли, что заблудились. Кент запаниковал — у него участилось дыхание, по коже побежал озноб. И тут кто-то предложил план: они будут идти в гору до тех пор, пока не дойдут до дороги, которая, как было известно, пролегает где-то наверху. В ту же секунду паника прекратилась.
Тогда-то Кент понял, как важно иметь план. Без плана он мог бы натворить глупостей, или просто впасть в полубессознательное состояние. Теперь же он снова был спокоен.
Планирование разработки ПО имеет тот же эффект. Типичный пример: сроки поджимают, но во время планирования выясняется, что уложиться в них еще можно. В этом случае вы приступите к первой задаче с намерением сделать все как можно быстрее, однако качеством работы не поступитесь. В конце концов, у вас есть время, чтобы сделать все хорошо. Если человек работает с такой установкой, ему, скорее всего, удастся выполнить все запланированные задачи. Паника приведет лишь к изнеможению, ошибками и проблемам с общением.
Впрочем, иногда планирование приводит к всевозможным проблемам. Оно может стать причиной колоссальной потери времени. Ради него людей будут целыми днями отрывать от работы (в то время как они предпочли бы заниматься чем-то более существенным). План может превратиться в палку, которая начинает гулять по спинам сотрудников. Однако хуже всего то, что с помощью плана можно долго скрывать серьезные проблемы — так долго, что, в конце концов, уже ничего нельзя будет исправить.
Почему мы должны планировать?
Тот, кто не хочет планировать, должен научиться предсказывать будущее. Однако бизнес и программное обеспечение меняются настолько быстро, что все изменения предвидеть просто невозможно. Даже если бы мы могли сказать, что именно нам понадобится через три года, все равно без планирования не обойтись — слишком много всего другого нам понадобится за это время.
Чем яснее вы понимаете, что нужно что-то делать, тем важнее знать — зачем? Если вы работаете над серьезным проектом в области разработки ПО, без планирования вам не обойтись. Прежде чем начать планирование проекта, определите, зачем оно. Ведь если вы не понимаете, зачем оно, то как узнаете, что успешно его завершили?
Итак, мы планируем, чтобы:
-удостовериться, что всегда занимаемся наиболее важными на текущий момент делами;
-согласовывать свои действия с деятельностью других людей;
-понимать, что делать в ходе выполнения предыдущих двух пунктов при возникновении нештатных ситуаций.
Первая причина самая очевидная. Нет тяжелее разочарования, чем вдруг осознать, что ты усердно трудился над неперспективной частью системы, от которой решено отказаться уже в следующей версии. Время, потраченное на что-то одно, это время, не потраченное на что-то другое, и если второе важнее, чем первое, ваш проект может окончиться полным провалом.
Допустим, сейчас два часа дня, и мы находимся в Бостоне. Нам нужно поехать в Акадию, однако в то же время хочется успеть к парикмахеру, а потом во Фрипорт, за туристическим снаряжением. Когда мы последний раз ездили в Акадию, мы ехали туда пять часов без остановок. Итак, у нас есть несколько вариантов на выбор. Если мы прямо сейчас отправимся в Акадию, то успеем к семи часам. Если остановимся по дороге пообедать, ну, пусть на часок, то окажемся в Акадии в восемь. Если пойдем в парикмахерскую, потратим еще час, то есть прибудем в девять. Чтобы заехать во Фрипорт по
надобится еще час времени. Если мы хотим прибыть на место сытыми, привезти необходимое снаряжение и при этом не припоздниться, то вполне можно пожертвовать внешностью и не идти к парикмахеру. Как видите, с помощью планирования можно понять, какие у нас есть возможности.
Согласованность действий — вот причина, по которой все вокруг хотят, чтобы мы планировали свои поступки. Наши жены звонят нам и сообщают, что хотели бы поужинать с нами в Бар Харборе. Поскольку сейчас два часа дня, мы понимаем, что надо выезжать прямо сейчас, заскочить за снаряжением во Фрипорт и быть на месте к восьми. Во время разработки ПО подобные согласования случаются сплошь и рядом: рекламные объявления о создаваемом программном продукте, составление финансовой отчетности, обещания руководства и т. д. В этих случаях только планирование может дать
ответ на вопрос, насколько разумны и осуществимы такие предположения.
Впрочем, любой план хорош лишь настолько, насколько справедливы подсчеты, на которых он строился. К тому же, реальные события всегда могут внести коррективы в любые предварительные оценки. Если по пути мы попадем в пробку, то никакое планирование не поможет нам успеть на свидание вовремя. Реальный мир имеет прескверную особенность разрушать планы, как справедливо отметил м-р Бернс в эпиграфе к этой главе.
Однако планирование сослужит нам добрую службу даже в неожиданно изменившихся обстоятельствах, так как благодаря ему мы можем правильно оценить последствия этих самых обстоятельств. Мы выехали в два, но попали в пробку. Теперь раньше пяти до Портланда не доберешься. Мы знаем, что обычно едем туда часа полтора, поэтому тут же вырабатываем новый план: нужно позвонить и попросить отложить ужин на полчаса и не заезжать при этом во Фрипорт. Планирование позволяет корректировать свою деятельность и согласовывать ее с другими. Обратите внимание — начинать ко
рректировать существующий план нужно сразу, как только выяснятся последствия неожиданных событий. Нашим женам лучше узнать о том, что мы задерживаемся, в пять, а не в восемь, не говоря уже о том, что было бы настоящим свинством заехать во Фрипорт и только потом сообразить, что мы сильно опаздываем на ужин с женами. (Честно говоря, нам не хочется даже думать о возможных последствиях такого проступка, потому что по сравнению с ними провал любого проекта покажется сущей мелочью.)
Каким должно быть планирование?
Планировать можно на разных уровнях. Вы планируете, чем будете заниматься сегодня. Команда разработчиков планирует, чем она будет заниматься в ближайшие две недели. Отделы управления и развития пишут план на следующий год. Директорат разрабатывает план работ для всей компании целиком. Если вы едете из Бостона в Акадию, то, конечно, не станете планировать каждый поворот. Скорее всего, вы просто выберете один из возможных маршрутов. Никто не ожидает, что вы приедете на место минута в минуту, однако есть некий лимит опоздания, превысив который, нужно позвони
ть и извиниться.
Впрочем, чтобы согласовывать свои действия, абсолютно необходимо четко представлять себе, насколько далеко вы продвинулись в выполнении собственных планов. В нашем примере с поездкой в Акадию все обстоит предельно просто: нужно отслеживать пройденное расстояние, учитывая при этом тип трассы. В этом случае всегда можно приблизительно спланировать время прибытия в основные точки пути. Если вы приехали в Портланд гораздо позднее, чем собирались, нетрудно догадаться, что и в Бар Харбор вы опоздаете. Жаль, что применить этот принцип в разработке ПО не так-т
о просто. Неуловимая природа программных продуктов и тут ставит палки в колеса: никогда нельзя с уверенностью сказать, сколько процентов работы уже выполнено — семьдесят или тридцать. Это все равно, что не знать, сколько миль ты уже проехал: тридцать или триста. Если система координат отсутствует, то невольно начнешь ощущать себя не в своей тарелке. Более того, такая ситуация совсем не понравится человеку, который ждет тебя к ужину, а ты не можешь даже сказать ему, какую часть пути проехал, и когда будешь на месте.
В деле разработки ПО любое планирование должно быть максимально наглядным, чтобы каждый участник проекта ясно видел, сколько он уже сделал. Это означает, что понадобится некая строгая система контрольных точек поставки продукта, которые нельзя обойти или отменить. Именно такие точки и будут служить системой координат для оценки хода работ. При этом они должны быть, во-первых, предельно ясными и понятными, а во-вторых, вызывать доверие у всех участников проекта, в том числе у клиентов.
С помощью планирования можно вычислить наиболее вероятный ход событий и оценить последствия каких-либо неожиданных изменений. Для работы над проектом вам понадобятся планы различного масштаба и уровня абстракции. При этом все они должны быть очень простыми (как с точки зрения создания плана, так и с точки зрения внесения изменений). От больших и сложных планов мало проку, потому что на их создание и поддержку уходит слишком много сил и средств. Опять же, если планирование служит для согласования деятельности различных людей, то план должен быть понятен
каждому, кого он затрагивает. И это еще один довод в пользу простых планов.
Кроме того, план должен честно отражать положение дел и включать в себя всю информацию, которая у вас есть на сегодняшний день. Такой план не позволит никому обманывать других вымышленными отчетами и дутыми цифрами.
Ловушка планирования
Если вы прочитали предыдущий абзац, то вам уже понятно, каким образом план становится ловушкой. Да, существует еще одна причина, по которой люди занимаются планированием: им нужно продемонстрировать, что они полностью контролируют ход событий.
Однако «контролировать ход событий» — это оксюморон, взаимоисключающее сочетание слов. Этого не бывает. Никто не может контролировать ход событий, можно лишь пытаться контролировать свою реакцию на них. Однако даже в этом случае степень контроля будет ограниченной. Реальные события меняют наши планы. Если вы попали в пробку, то волей-неволей придется поступиться либо ужином, либо Фрипортом. Вы не можете продолжать действовать по изначальному плану, как будто ничего не случилось. Это было бы просто глупо.
Тем не менее в жизни так поступают довольно часто. Если реальные события не укладываются в рамки плана, то человек, который составлял этот план, начинает опасаться, что во всех грехах обвинят именно его. Страх заставляет его скрывать истинное положение вещей и утверждать, будто все идет по плану. При этом в душе он, конечно, сознает, что лжет, но продолжает выдавать желаемое за действительное. Если план достаточно сложен, проблемы можно скрывать довольно долго. Самое главное — это уверить весь окружающий мир, что все идет так, как было задумано.
Постепенно план все больше расходится с реальностью и превращается в полную иллюзию. Хуже того, человек, который осуществляет планирование, тратит массу сил и энергии на то, чтобы заставить окружающих поверить в эту иллюзию. Мало-помалу у разработчиков исчезает всякое желание работать: в конце концов, если план не имеет никакого отношения к реальности, зачем пытаться его выполнять?
Может быть, конечно, все уладится как-то само собой. Это редко, но случается. Возможно, в проекте возникнут проблемы похуже этой. Однако чаще всего пропасть между иллюзорным планом и реальным состоянием дел вырастает настолько, что это уже не удается скрывать. Все идет наперекосяк. Клиент в ярости, потому что он строил на этой иллюзии свои собственные планы и давал обещания, которые теперь не может сдержать. Программисты в ярости, потому что старались делать все как можно лучше, и вот теперь на них начинают орать, потому что они не смогли совершить невозможн
ое и не превратили иллюзию в реальность.
В жизни происходят всевозможные события. Планы меняются. Если все идет точно по плану, это тревожный признак. Самое худшее, что может случиться с проектом, это отрыв плана от реальности. Не попадите в эту ловушку. Не выдавайте желаемое за действительное и подготовьтесь к тому, что ваш план будет постоянно меняться.
Экстремальное программирование: планирование. Библиотека программиста. / К. Бек, М. Фаулер - СПб: Питер, 2003. - 144 с.
|