Экстремальное программирование - Бек Кент - Страница 29

• Предыдущая
• 29/50
• Следующая

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Предыдущая
• 29/50
• Следующая