Agile: оценка и планирование проектов - [94]

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

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

10. Стройте оценки и планы на фактах. Когда возможно, стройте оценки и планы на реальной основе. Конечно, бывает, что в некоторых организациях приходится оценивать показатели вроде скорости, опираясь на очень узкую базу. В главе 16 «Оценка скорости» на этот случай представлены подходящие методики. Вместе с тем, когда возможно, оценки и планы должны строиться на реальных, наблюдаемых величинах. Это относится также и к оценке того, сколько функций реализовано. Несложно увидеть, что функция выполнена на 0 % (в момент, когда с нею только начинают работать), и довольно легко определить, когда она выполнена на 100 % (пройдены все тесты для всех условий удовлетворенности владельца продукта). Однако в промежутке между этими состояниями очень трудно сказать, на сколько реализована функция — на 50 % или на 60 %. Как результат, придерживайтесь того, что вам известно: 0 % и 100 %.

11. Оставляйте небольшой резерв. Особенно при планировании итерации не пытайтесь задействовать 100 % времени каждого члена команды. Точно так же, как на шоссе возникает пробка при его загрузке на 100 %, команда разработчиков начинает работать медленнее, когда время каждого члена команды полностью заполнено.

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

Резюме

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

Вопросы для обсуждения

1. Есть ли другие причины, которыми, на ваш взгляд, объясняется успех agile-подхода к оценке и планированию?

2. Какие из 12 правил применимы к вашему текущему процессу оценки и планирования? Будет ли полезно следовать другим правилам?

Часть VII Анализ конкретного примера

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

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

• Аллан — программист;

• Делани — аналитик;

• Карлос — agile-тренер;

• Лора — финансовый директор;

• Прасад — тестировщик;

• Роуз — художник;

• Саша — программист;

• Фил — генеральный директор;

• Фрэнк — менеджер по продукту.

Глава 23 Конкретный пример: Bomb Shelter Studios

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

Как менеджер по продукту в Bomb Shelter Studios, он знал, что их последняя игровая программа Deep Black & White демонстрировала хорошие результаты. Она позволяла играть в игру под названием го, которая была чрезвычайно популярна в Японии, Китае и Корее, но вызывала лишь умеренный интерес в Европе, Северной Америке и остальном мире. Программисты из его команды использовали решения на основе искусственного интеллекта, которые позволили Deep Black & White дойти в игре до уровня сложности, известного как пятый дан. Это, конечно, далеко от девятого дана — уровня лучших профессиональных игроков, однако значительно лучше, чем у конкурентов компании Bomb Shelter.

Фрэнк был полон энтузиазма в отношении выпуска и продажи Deep Black & White в Азии через одного издателя, с которым удалось договориться о дистрибуции во время конференции. Доход от продаж на этих рынках был бы очень кстати для Bomb Shelter. Фрэнк знал: дополнительные шесть месяцев, которые потребовались для завершения Deep Black & White, чуть было не привели к разорению небольшую частную компанию по разработке игр, соучредителем которой он являлся.