Читать книгу "Agile: Оценка и планирование проектов - Майк Кон"

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, чуть было не привели к разорению небольшую частную компанию по разработке игр, соучредителем которой он являлся.

Из малоперспективной начинающей компании за три года Bomb Shelter Studios превратилась в признанного разработчика интеллектуальных и стратегических игр. В дополнение к только что законченной Deep Black & White у Bomb Shelter были программы для игры в шахматы, триктрак, реверси, бридж, шашки, манкалу и др. После создания игры права на ее дистрибуцию продавались тому или иному издателю, который занимался производством и распространением, позволяя Bomb Shelter полностью сконцентрироваться на разработке новых игр.

Пока Фрэнк был на конференции, его аналитик и небольшая команда в Санта-Барбаре обдумывали новую игру Havannah, разработку которой они были практически готовы начать. Из-за проблем с Deep Black & White — не только из-за шестимесячной задержки, но и из-за слишком большого количества ошибок и обнаруженного в последний момент неудобства использования — им нужно было срочно найти другой подход к планированию и реализации проектов. Саша, ведущий разработчик архитектуры в компании, проработала ряд выдвинутых командой идей. Она предложила в следующем проекте использовать то, что называют «agile-процесс». Фрэнк не совсем понимал, что это означает, однако у него не было сомнений в том, что им нужно подходить к делу по-другому. Шестимесячное опоздание с выпуском следующей игры было бы концом. Все члены команды горели идеей попробовать agile-процесс и знали, чтó поставлено на кон.

День 1 — утро понедельника

— Всем привет, — сказал Фрэнк, входя в конференц-зал. До девяти оставалась еще целая минута, однако почти вся команда была в сборе и ожидала его появления. Это был хороший знак. Несмотря на то, что команда измоталась в процессе последнего рывка с Deep Black & White, она выглядела так, словно была готова взяться за разработку Havannah.