Разделение полномочий между технарями и бизнесменами

 

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

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

 

Бизнес

 

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

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

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

В результате, если бизнес получает слишком большие полномочия, проект требует слишком много усилий и генерирует слишком много риска, при этом он обеспечивает слишком незначительную отдачу.

 

Разработчики

 

Можно подумать, что если большие полномочия предоставляются разработчикам, жизнь становится лучше. Но на самом деле это не так. В действительности результат получается такой же.

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

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

 

Что делать?

 

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

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

Для начала небольшое отклонение от темы. Если кто-нибудь спросит у меня, какой автомобиль я хочу: Феррари или минивэн, я уверен, что выберу Феррари. Но если этот кто-то спросит у меня: Хочешь ли ты „Феррари" за 200 000 франков или минивэн за 40 000? – я начну формировать взвешенное решение. Если добавить к этому еще пару требований, например, мне необходимо брать с собой в дорогу пять детей или я должен быть способен развить скорость 200 километров в час, картина еще более прояснится. Существуют случаи, в которых каждое из решений по-своему оправданно, однако вы, скорее всего, не сможете сформировать хорошее решение исходя только лишь из глянцевых фотографий.

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

Следуя этой модели, бизнесмены должны определить:

• Объем работ или время выпуска версий продукта;

• Относительные приоритеты предполагаемых возможностей системы;

• Конкретный объем работ, связанных с предполагаемыми возможностями системы.

Для того чтобы помочь бизнесменам сформировать эти решения, разработчики должны сообщить:

• Оценки времени, необходимого для реализации различных возможностей системы.

• Предположительные последствия использования различных технических альтернатив.

• Процесс разработки, который соответствует их индивидуальности, их бизнес-окружению и культуре компании. Не существует списка пунктов типа: Вот так мы пишем программное обеспечение..., который бы подходил для абсолютно любой ситуации. Все это потому, что ситуация постоянно меняется.

• С использования какого набора методик они начнут свою работу и при помощи какого процесса они будут пересматривать эффекты использования этих методик и экспериментировать с изменениями. Это напоминает Американскую конституцию, которая устанавливает базовую философию, базовый набор правил (билль о правах и первые 10 поправок), а также правила изменения правил (добавления новых поправок).

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

 

Выбор технологии

 

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

Если заказчик говорит мне: Мы хотим использовать вот эту реляционную базу данных и вот эту среду Java IDE, – я должен рассказать ему о последствиях подобного решения. Если я подозреваю, что объектно-ориентированная база данных и C++ лучшим образом подходят для данного проекта, я выполню оценку проекта с двух точек зрения. После этого бизнесмены получат возможность сформировать взвешенное бизнес-решение.

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

 

Что если это сложно?

 

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

Однако в некоторых случаях подобный способ не срабатывает. В некоторых ситуациях наименьшая ценная часть разработки с точки зрения бизнеса выглядит большой и рискованной с точки зрения программиста. Когда такое происходит, вы не должны допускать каких-либо сомнений. Вы обязаны действовать осторожно. Допускается сделать лишь незначительное количество ошибок. Вы можете потребовать большее количество внешних ресурсов, однако может случиться так, что вы получите эти ресурсы только тогда, когда времени будет в обрез. Поэтому с самого начала вы должны сделать все, что в ваших силах, для того, чтобы сократить объем работ. Вы должны сделать все, что в ваших силах для того, чтобы снизить риск. Когда все это будет сделано, вы можете приступать к работе.

Об этом можно сказать и по-другому: разделение полномочий между бизнесом и разработчиком – это не оправдание отказа от выполнения грязной работы. Совсем наоборот. Это способ отделения той работы, которая очевидно является сложной, от той работы, про которую вы просто еще не придумали, как сделать ее простой. В большинстве случаев работа оказывается проще, чем вам кажется с самого начала. Если это не так, вы обязаны сделать работу в любом случае, так как именно за это вам и платят деньги.

 

Глава 15.

Стратегия планирования

 

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

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

• Собрать команду вместе;

• Определить объем работ и приоритеты;

• Оценить затраты и график работ;

• Добиться появления у каждого заинтересованного лица ощущения того, что система действительно может быть реализована;

• Определить исходные данные для обратной связи.

Давайте взглянем на принципы, которые влияют на планирование. Некоторые из них являются базовыми принципами, о которых шла речь в главе 8. Другие относятся конкретно к планированию.

• Планируйте только то, что вам нужно для реализации очередного этапа – на любом уровне детализации осуществляйте планирование только очередного этапа работ – то есть следующей версии, завершения следующей итерации. Это не означает, что вы не должны выполнять долгосрочное планирование. Вы можете это делать, только не с высокой степенью детализации. Вы можете спланировать текущую версию достаточно скрупулезно, и при этом вы можете обрисовать план пяти следующих версий набором простых тезисов. При этом вам не придется тратить значительных усилий на то, чтобы спланировать все шесть версий с высокой степенью детализации.

• Принимаемая ответственность – ответственность может быть только принята, но не может быть назначена. Это означает, что в рамках ХР не может быть такой вещи, как планирование сверху вниз. Менеджер не может прийти к команде и сказать: Вот то, что мы должны сделать и это должно быть сделано за такое-то и такое-то время. Менеджер проекта должен предложить команде взять ответственность за выполнение работы. После этого он должен внимательно выслушать ответ.

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

• Игнорируйте взаимосвязи между частями проекта – планируйте так, как если бы части разработки можно было бы менять между собой по вашему собственному желанию. Это простое правило избавит вас от проблем при условии, что вы будете в первую очередь реализовывать наиболее высокоприоритетные бизнес-требования. Сколько стоит кофе? 25 центов за чашку, но вторая чашка бесплатно. Тогда дайте мне вторую чашку. Подобные ситуации не должны происходить.

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

 

Игра в планирование

 

Планирование в ХР намеренно абстрагирует процесс планирования для двух участников – бизнес (Business) и разработчики (Development). Это способствует устранению некоторого эмоционального напряжения, которое часто возникает в процессе обсуждения планов. Вместо «Джо, ты придурок! Ты же обещал мне сделать это еще к минувшей пятнице!» – игра в планирование (Planning Game) сообщает: Разработчики обнаружили нечто. Им нужна помощь со стороны бизнеса для того, чтобы среагировать на открытие лучшим способом. Нельзя устранить эмоциональное напряжение при помощи простого набора правил, да мы и не собираемся этого делать. Правила существуют для того, чтобы напомнить каждому, как он должен действовать, также на правила можно сослаться в случае, если дела идут не так, как хотелось бы.

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

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

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

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

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

Однако для начала вы должны научиться играть в соответствии с правилами. Вот они.

 

Цель

 

Цель игры – максимизировать ценность программного обеспечения, разработкой которого занимается команда. Исходя из ценности программы вы можете получить затраты, связанные с ее разработкой, а также уровень риска, которому вы подвергаетесь в процессе разработки.

 

Стратегия

 

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

И так далее.

 

Куски

 

Куски (pieces) в игре в планирование – это карточки историй (story cards). Пример одной из них показан на рис. 6.

 

Рис. 6. Карточка с историей (story card)

 

Игроки

 

В игру в планирование играют два игрока – бизнес (Business) и разра ботчики (Development). Разработчики – это люди, которые отвечают за реализацию системы. Бизнес – это люди, которые принимают решения о том, что должна делать система.

Иногда сразу ясно, кто именно должен играть на стороне бизнеса. Если компания – биржевой брокер платит деньги за разработку специализированного программного обеспечения, значит, эти люди играют на стороне бизнеса. Именно они должны определить, что необходимо сделать в первую очередь. Но если вы занимаетесь разработкой программного продукта, который предназначен для массового рынка? Кто тогда играет роль бизнеса? Бизнес должен принимать решения относительно объема работ, приоритетов и содержимого версий продукта. Все эти решения, как правило, делаются сотрудниками отдела маркетинга. Если это достаточно умные люди, они будут принимать решения исходя из мнения:

• реальных пользователей продукта;

• заинтересованных в продукте групп;

• людей, занимающихся продажами.

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

 

Ходы

 

Игра состоит из трех фаз:

• исследование (exploration) – в этой фазе необходимо определить, что нового должна делать система;

• подтверждение (commitment) – в этой фазе необходимо решить, какое подмножество всех возможных требований необходимо удовлетворить в следующую очередь;

• управление (steer) – в этой фазе необходимо управлять разработкой по мере того, как реальность вносит свои коррективы в план.

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

 

Фаза исследования

 

Фаза исследования предназначена для того, чтобы предоставить обеим сторонам возможность уяснить, что должна делать вся система. Фаза исследования включает в себя три хода.

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

• Оценка истории – разработчики делают оценку времени, которое потребуется для реализации истории. Если разработчики не могут оценить историю, они просят бизнес предоставить дополнительные разъяснения либо разделить историю. Чтобы оценить историю, можно спросить самого себя: Какое время потребовалось бы мне для того, чтобы реализовать историю, если эта история была бы всем, что мне необходимо реализовать, и при этом меня никто не отвлекал бы и мне не надо было бы ходить на совещания? В рамках ХР мы обозначаем данный показатель термином идеальное время разработки (Ideal Engineering Time). Как будет показано позже (в разделе Определение скорости), прежде чем приступить к составле нию графика работ, вы определяете коэффициент между идеальным временем и календарным.

• Разделение истории – если разработчики не могут оценить всю историю или если бизнес приходит к выводу, что некоторая часть истории является более важной, чем остальная история, бизнес может разделить историю на две или более историй.

 

Фаза подтверждения

 

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

• Сортировка в соответствии с ценностью – бизнес разделяет истории на три категории: (1) истории, без которых система не сможет функционировать, (2) истории, которые являются менее важными, но обеспечивают значительную полезность для бизнеса, (3) истории, которые было бы неплохо реализовать в рамках программного продукта.

• Сортировка в соответствии с риском – разработчики разделяют истории на три категории: (1) истории, которые можно оценить с высокой степенью точности, (2) истории, которые можно оценить с приемлемой точностью, (3) истории, которые невозможно оценить.

• Определение скорости – разработчики сообщают бизнесу, насколько быстро команда сможет программировать, оценка скорости выполняется отношением идеального времени разработки к календарному месяцу.

• Определение объема работ – бизнес выбирает набор карт для очередной версии. Для этого он либо устанавливает дату завершения работы над версией и выбирает карты в соответствии с их оценкой и скоростью работы над проектом, либо выбирает карты в соответствии с оценкой, а затем определяет дату завершения работы.

 

Фаза управления

 

Фаза управления предназначена для обновления плана на основе новых данных, которые появляются у разработчиков и у бизнеса. Фаза управления включает в себя четыре хода.

• Итерация – в начале каждой итерации (одна итерация длится в течение от одной до трех недель) бизнес выбирает несколько наиболее ценных для него историй, которые будут реализованы в рамках данной итерации. В результате реализации историй самой первой итерации должна получиться работающая от начала до конца система, пусть даже в самом зачаточном состоянии.

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

• Новая история – если в середине работы над очередной версией бизнес приходит к выводу, что в версию необходимо добавить новую историю, он может написать эту историю. Разработчики оценивают историю, после чего бизнес убирает из оставшегося плана истории с эквивалентной суммарной оценкой и добавляет в план новую историю.

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

 

Итерационное планирование

 

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

Игра в итерационное планирование (Iteration Planning Game) очень напоминает игру в планирование (Planning Game), в которой карты используются в качестве кусков (pieces). На этот раз в качестве кусков используются не карты историй (story cards), а карты задач (task cards). Игроками являются отдельные программисты. Шкала времени короче – вся игра укладывается в одну итерацию (от одной до четырех недель). Фазы и ходы схожи с фазами и ходами игры в планирование.

 

Рис. 7. Карточка задачи (task card)

Фаза исследования

• Написание задачи – выбор историй для итерации и преобразование их в задачи. Как правило, задача – это нечто меньшее по масштабу, чем история, так как нельзя реализовать одну историю целиком всего за пару дней. Иногда одна задача служит для реализации нескольких историй. Иногда задача не связана напрямую с какой-либо историей – например, переход на использование новой версии системного программного обеспечения. На рис. 7 показан пример реальной карточки задачи (task card).

• Разделение задачи/комбинация задач – если вы не можете оценить задачу в несколько дней, разделите ее на более мелкие задачи. Если выполнение нескольких задач потребует всего несколько часов, вы можете скомбинировать их в одну большую задачу.

 

Фаза подтверждения

 

• Принятие задачи – программист принимает на себя ответственность за выполнение задачи.

• Оценка задачи – ответственный программист оценивает количество идеальных дней разработки, необходимых для реализации каждой из задач. Часто эта оценка зависит от того, сможет ли оказать помощь другой программист, который в большей степени знаком с кодом, требующим модификации. Задачи, для выполнения которых требуется более нескольких дней, необходимо разделить (вы должны самостоятельно определить для себя порог надежности, для этого следует сравнить задачи, которые вы успели выполнить к сроку, с задачами, которые заняли у вас больше времени, чем вы предполагали). Можно подумать, что, делая оценку задач, необходимо явно учесть в ней фактор парного программирования. На самом деле вы должны игнорировать этот фактор. Время, которое вы тратите на помощь другим программистам, на разговоры с заказчиком и на совещания, учитывается при помощи общего фактора нагрузки.

• Определение фактора нагрузки – каждый программист выбирает свой собственный фактор нагрузки для итерации – процент времени, которое на самом деле тратится на разработку. Это вполне конкретное значение равно отношению идеальных программных дней к общему числу календарных дней. Если в течение последних трех итераций вы выполнили задачи, оцененные соответственно в 6,8 и 7,5 идеальных дней, это значит, что примерно такой же показатель следует использовать и для очередной следующей итерации. Для новых членов команды, равно как и для инструктора ХР, количество идеальных дней программирования в течение одной итерации может быть совсем небольшим – 2 или 3 дня в течение трехнедельной итерации. Для всех остальных членов команды это значение не должно быть больше, чем 7 или 8 дней. Если для какого-то программиста это значение больше, это означает, что он слишком мало времени тратит на помощь своим соратникам.

• Балансировка – каждый программист складывает оценки для своих задач и умножает на фактор нагрузки. Программисты, которые оказываются перегруженными, отказываются от части своих задач. Если перегруженной оказывается вся команда, необходимо найти способ сбалансировать ситуацию (см. подраздел Регенерация далее по тексту).

 

Фаза управления

 

• Реализация задачи – программист берет карточку задачи, находит партнера, пишет тестовые случаи для задачи, добивается их срабатывания, затем интегрирует новый код в систему, и когда весь универсальный набор тестов срабатывает, новый код делается доступным для остальных программистов.

• Отслеживание прогресса – каждые два или три дня один из членов команды спрашивает каждого из программистов, как много времени потрачено на решение каждой из задач и сколько дней еще осталось потратить.

• Регенерация – программисты, которые оказываются перегруженными, просят помощи, для этого они: (1) уменьшают объем работ для некоторых из задач, (2) просят заказчика уменьшить объем работ для некоторых из историй, (3) отказываются от решения менее важных задач, (4) получают помощь со стороны соратников в большем объеме или лучшего качества, и наконец, как самый последний вариант, (5) просят заказчика отложить реализацию некоторых историй до следующей итерации.

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

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

В некотором роде это выглядит как ложь, так как вы утаиваете некоторую часть процесса разработки от заказчика. Однако на самом деле это не так. Вы ничего не утаиваете преднамеренно. Если заказчик желает весь день сидеть рядом с вами и наблюдать, как осуществляется переработка кода системы, пожалуйста: пусть сидит, хотя возможно, у него есть более важные дела. Различие между планированием в рамках итерации и между итерациями – это расширение принципа разделения решений между бизнесом и разработчиками. На определенном уровне детализации существуют изменения, которые не должны беспокоить бизнес, – программисты отлично знают, как лучше осуществлять микроуправление своим рабочим временем, бизнесмен вряд ли сделает это лучше.

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

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

Давайте вернемся к ограничениям, связанным с процессом планирования итерации, и рассмотрим, как описанная ранее стратегия удовлетворяет этим ограничениям.

• Вы не желаете тратить слишком много времени на планирование, так как реальность никогда не соответствует плану с точностью 100%. Половина дня из пятнадцати – это не такая уж серьезная потеря. Конечно же, если вы можете сделать это время еще меньше, это будет лучше, однако половина дня – это действительно не так уж и много.

• Вы желаете обладать быстрой и надежной обратной связью относительно того, как идут дела, благодаря чему спустя треть от намеченного времени работы вы можете определиться, существуют ли у проекта проблемы. Ответы на вопросы, которые задает ревизор (tracker) позволяют вам получить неплохое представление о том, отстаете ли вы от графика или нет. Как правило, оставшегося времени хватает на то, чтобы должным образом прореагировать на проблемы локально, то есть не обращаясь к заказчику с просьбой об изменениях.

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

• Вы желаете ограничить объем разработки теми частями проекта, которые действительно нужны. Это всегда звучит странно, когда вы говорите, что на протяжении трех недель вы можете работать только в течение 7,5 дней (15 дней разделить на измеренный фактор нагрузки, равный 2). Однако по мере того, как вы будете учиться формировать точные оценки, вы обнаружите, что это – абсолютная правда. Ощущение, что вы не работаете с максимально возможной интенсивностью, стимулирует у вас желание взять на себя выполнение большего количества задач. Однако при этом вы знаете, что вам надо поддерживать существующие стандарты и приемлемый уровень качества (и у вас есть партнер, который смотрит на тот же самый экран и следит за тем, чтобы вы работали качественно). Таким образом, вы получаете тенденцию работать просто и все также с гордостью могли бы сказать, что вы завершили работу.

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

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

 

Планирование за неделю

 

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