« "Каждой методологии - свое время", Алистэр Коуберн | | Обзор литературы за 2002-2003 год »

Главы из перевода "Planning Extreme Programming", Кент Бек и Мартин Фаулер

Глава 1. Для чего существует планирование?

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

Глава 2. Страх

Разработка программного обеспечения - дело рискованное. Люди, которые этим занимаются, постоянно боятся, что что-то пойдет не так, как надо. Если вы хотите, чтобы команда работала эффективно, обязательно принимайте во внимание такие страхи.

Глава 3. Создание программного обеспечения как вождение автомобиля

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

Глава 4. Равновесие политических сил

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

Глава 5. Введение в методологию (два варианта)

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

Глава 6. Слишком много дел

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

Глава 7. Четыре переменные

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

Глава 8. Вчерашняя погода

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

Глава 9. Объем проекта

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

Глава 10. Как планировать выпуск версий системы

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

Глава 11. Чего изволит заказчик?

В ХР единицей функциональности системы принято считать пожелание пользователя относительно ее работы. Чтобы продемонстрировать заказчику, как продвигается работа над проектом, мы регулярно поставляем ему интегрированный и протестированный программный код, в котором постепенно реализуются все его пожелания относительно функционирования системы. Эти пожелания должны быть понятны как программистам, так и самим заказчикам. Кроме того, программисты должны иметь возможность протестировать каждую задачу, которую ставит перед ними заказчик. Каждое пожелание должно представлять для клиента некоторую ценность и при этом быть небольшого размера, чтобы разработчики успевали реализовать за одну итерацию по 5-6 таких пожеланий.

Глава 12. Оценка трудозатрат

Чтобы оценить объем трудозатрат по какой-либо задаче, вспомните, сколько усилий уходило у вас на решение подобных задач в прошлом. Оценки трудозатрат по новой задаче будут приблизительно такими же.

Глава 13. Порядок реализации пожеланий заказчика

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

Глава 14. События, которые влияют на планирование версий системы

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

Глава 15. Первый план

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

Глава 16. Варианты планирования

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

Глава 17. Планирование итерации

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

Глава 18. Собрание по планированию итерации

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

Глава 19. Контроль над ходом работ

Пару раз в неделю "наблюдатель" контролирует ход работ в текущей итерации.

Глава 20. Краткие собрания

Раз в день собирайте всех на краткое собрание, чтобы все знали, как у кого идут или не идут дела.

Глава 21. Наглядные иллюстрации

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

Глава 22. Работа над ошибками

Исправление дефектов в программе нужно планировать одновременно с планированием итерации. Тогда клиент сам сможет выбрать, что ему важнее - правильная работа системы или дополнительная функциональность.

Глава 23. Изменения в команде

Как произошедшие в команде изменения повлияют на существующий план работ?

Глава 24. Инструментарий

Карандаш, бумага, доска - вот и все инструменты, которые понадобятся вам для планирования ХР процесса. Для успешной работы гораздо важнее непосредственное общение, а не какие-то хитроумные приспособления.

Глава 25. Договор с заказчиком

Если вы собираетесь разрабатывать свой проект согласно методологии ХР, традиционные представления о бизнес-отношениях придется немного пересмотреть.

Глава 26. Красные флаги

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

Глава 27. Ваша собственная методология

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

© Copyright Addison-Wesley, 2001, все права защищены
© Copyright maxkir.com, перевод, 2002
© Copyright Издательский дом "Питер", 2002, все права защищены

kirsa November 20, 2002 9:01 PM