Agile. Оценка и планирование проектов
Покупка
Основная коллекция
Тематика:
Управление проектами
Издательство:
Альпина Паблишер
Автор:
Кон Майк
Год издания: 2018
Кол-во страниц: 418
Возрастное ограничение: 0+
Дополнительно
Доступ онлайн
В корзину
О чем книга
Оценка и планирование критически важны для успеха любого проекта. Однако процесс планирования сложен, и наши планы часто оказываются далекими от реальности. На помощь приходит agile-подход. Благодаря agile вы научитесь создавать реалистичные планы, которые сможете корректировать по ходу работы, при этом выполняя проекты в срок и в рамках бюджета.
Майк Кон, гуру в области agile, дает инструменты, необходимые для оценки, планирования и управления agile-проектами любого масштаба. В книге нет теоретических рассуждений, она полна конкретных примеров, методов, графиков, рецептов, а главное - аргументированных рекомендаций.
Почему книга достойна прочтения:
- Стандартное планирование почти не работает: почти две трети проектов значительно превышают сметы, а срок выполнения среднего проекта превышает календарный график на 100%. Agile помогает этого избежать.
- Применяя agile-подход к планированию, вы принимаете более качественные решения и сокращаете свои риски.
- Agile-подход к планированию применяют и стартапы и компании-гиганты вроде Yahoo! и Siemens.
Тематика:
ББК:
УДК:
ГРНТИ:
Скопировать запись
Фрагмент текстового слоя документа размещен для индексирующих роботов.
Для полноценной работы с документом, пожалуйста, перейдите в
ридер.
Посвящается Лоре, без всяких сомнений
Mike Cohn AGILE ESTIMATING AND PLANNING
Майк Кон AGILE ОЦЕНКА И ПЛАНИРОВАНИЕ ПРОЕКТОВ Перевод с английского Москва 2018
УДК 658.5.011 ББК 65.291.217 К 64 ISBN 978-5-9614-6947-9 (рус.) ISBN 0-13-147941-5 (англ.) © Authorized translation from the English language edition, published by Pearson Education, Inc.; publishing as Prentice Hall. Copyright © 2006 by Pearson Education, Inc. All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc. © Издание на русском языке, перевод, оформление. ООО «Альпина Паблишер», 2018 год УДК 658.5.011 ББК 65.291.217 К 64 Кон М. Agile: оценка и планирование проектов / Майк Кон; Пер. с англ. — М. : Альпина Паб лишер, 2018. — 418 с. ISBN 978-5-9614-6947-9 Оценка и планирование критически важны для успеха любого проекта. Однако процесс планирования сложен, и наши планы часто оказываются далекими от реальности. На помощь приходит agile-подход, который применяют как стартапы, так и компании-гиганты вроде Yahoo! и Siemens. Благодаря agile вы научитесь создавать реалистичные планы, которые сможете корректировать по ходу работы, при этом выполняя проекты в срок и в рамках бюджета. Майк Кон, гуру в области agile, дает инструменты, необходимые для оценки, планирования и управления agile-проектами любого масштаба. В книге нет теоретических рассуждений, она полна конкретных примеров, методов, графиков, рецептов, а главное — аргументированных рекомендаций. Все права защищены. Никакая часть этой книги не может быть воспроизведена в какой бы то ни было форме и какими бы то ни было средствами, включая размещение в сети интернет и в корпоративных сетях, а также запись в память ЭВМ для частного или публичного использования, без письменного разрешения владельца авторских прав. По вопросу организации доступа к электронной библиотеке издательства обращайтесь по адресу mylib@alpina.ru. Переводчик Вячеслав Ионов
Содержание Об авторе . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Предисловие Роберта Мартина. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Предисловие Джима Хейсмита . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Предисловие Габриэла Бенефилда . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Благодарности . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 Введение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29 Часть I. Проблема и цель 33 Глава 1. Цель планирования. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35 Зачем это нужно. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Что делает план хорошим . . . . . . . . . . . . . . . . . . . . . . . . . .42 Что делает планирование гибким . . . . . . . . . . . . . . . . . . . .43 Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44 Вопросы для обсуждения . . . . . . . . . . . . . . . . . . . . . . . . . .45 Глава 2. Почему планирование дает неудовлетворительные результаты. . . . . . . . . . . . . . . . 47 Планирование ориентировано на деятельность, а не на функцию . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48 Многозадачность приводит к дальнейшим задержкам . . .52 Функции не разрабатываются в соответствии с их приоритетом . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55 Мы не учитываем неопределенность . . . . . . . . . . . . . . . . .55 Оценки превращаются в обязательства . . . . . . . . . . . . . . .56
Agile-подход к оценке и планированию Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Вопросы для обсуждения . . . . . . . . . . . . . . . . . . . . . . . . . .58 Глава 3. Agile-подход . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59 Agile-подход к проекту . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Agile-подход к планированию . . . . . . . . . . . . . . . . . . . . . . . 67 Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Вопросы для обсуждения . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Часть II. Оценка размера 75 Глава 4. Оценка размера в пунктах . . . . . . . . . . . . . . . . . . . . . . .77 Пункты — относительный показатель . . . . . . . . . . . . . . . . .78 Скорость . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80 Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84 Вопросы для обсуждения . . . . . . . . . . . . . . . . . . . . . . . . . .84 Глава 5. Оценка размера в идеальных днях . . . . . . . . . . . . . . . .85 Идеальное время и разработка программного обеспечения. . . . . . . . . . . . . . . . . . . . . . . . . 87 Идеальные дни как показатель размера. . . . . . . . . . . . . . .89 Одна оценка, а не множество . . . . . . . . . . . . . . . . . . . . . . .89 Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90 Вопросы для обсуждения . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Глава 6. Методы оценки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93 Оценки — продукт совместной работы. . . . . . . . . . . . . . . .96 Шкала оценки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Получение оценки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Покер планирования . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Почему покер планирования работает . . . . . . . . . . . . . . . 106 Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Вопросы для обсуждения . . . . . . . . . . . . . . . . . . . . . . . . . 107 Глава 7. Переоценка . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Знакомство с сайтом SwimStats . . . . . . . . . . . . . . . . . . . . 110 Когда переоценка не требуется. . . . . . . . . . . . . . . . . . . . . 110 Когда выполнять переоценку. . . . . . . . . . . . . . . . . . . . . . . 112 Переоценка частично реализованных историй . . . . . . . . 115 Цель переоценки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Вопросы для обсуждения . . . . . . . . . . . . . . . . . . . . . . . . . 117
Содержание Глава 8. Что выбрать — пункты или идеальные дни . . . . . . . . 119 Доводы в пользу пунктов . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Доводы в пользу идеальных дней . . . . . . . . . . . . . . . . . . . 124 Рекомендации . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Вопросы для обсуждения . . . . . . . . . . . . . . . . . . . . . . . . . 127 Часть III. Планирование на основе стоимости 129 Глава 9. Приоритизация тем . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Факторы приоритизации . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Объединение четырех факторов . . . . . . . . . . . . . . . . . . . . 140 Примеры . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Вопросы для обсуждения . . . . . . . . . . . . . . . . . . . . . . . . . 144 Глава 10. Приоритизация по финансовой отдаче . . . . . . . . . . . 145 Источники дохода. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Пример: WebPayroll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Финансовые показатели . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Сравнение отдачи. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Вопросы для обсуждения . . . . . . . . . . . . . . . . . . . . . . . . . 166 Глава 11. Приоритизация по желательности . . . . . . . . . . . . . . . 167 Модель удовлетворенности клиентов Кано . . . . . . . . . . . 168 Относительное взвешивание: еще один подход . . . . . . . 174 Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Вопросы для обсуждения . . . . . . . . . . . . . . . . . . . . . . . . . 178 Глава 12. Разбивка пользовательских историй . . . . . . . . . . . . . 179 Когда нужно разбивать пользовательскую историю. . . . . 180 Разбивка по границам данных. . . . . . . . . . . . . . . . . . . . . . 180 Разбивка по операционным границам . . . . . . . . . . . . . . . 183 Удаление сквозной функциональности . . . . . . . . . . . . . . . 185 Несоблюдение требований к быстродействию . . . . . . . . 186 Разбивка историй со смешанным приоритетом. . . . . . . . 187 Не разбивайте историю на задачи . . . . . . . . . . . . . . . . . . 188 Избегайте соблазна добавить взаимосвязанные изменения . . . . . . . . . . . . . . . . . . . . . . 188 Объединение историй . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Вопросы для обсуждения . . . . . . . . . . . . . . . . . . . . . . . . . 190
Agile-подход к оценке и планированию Часть IV. Составление календарных графиков 191 Глава 13. Основные аспекты планирования релиза . . . . . . . . . 193 План релиза . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Обновление плана релиза . . . . . . . . . . . . . . . . . . . . . . . . .200 Пример . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .204 Вопросы для обсуждения . . . . . . . . . . . . . . . . . . . . . . . . .206 Глава 14. Планирование итерации . . . . . . . . . . . . . . . . . . . . . . . .207 Задачи, не распределенные во время планирования итерации. . . . . . . . . . . . . . . . . . . 210 Чем различаются планирование итерации и планирование релиза . . . . . . . . . . . . . . . . . . . 211 Планирование итерации на основе скорости . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 Планирование итерации на основе обязательств . . . . . . . . . . . . . . . . . . . . . . . . . . .225 Мои рекомендации. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .230 Соотнесение оценок задач с пунктами . . . . . . . . . . . . . . . 231 Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .234 Вопросы для обсуждения . . . . . . . . . . . . . . . . . . . . . . . . .234 Глава 15. Выбор длины итерации . . . . . . . . . . . . . . . . . . . . . . . . .235 Факторы, влияющие на выбор длины итерации. . . . . . . .235 Принятие решения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .240 Два примера. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .242 Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .246 Вопросы для обсуждения . . . . . . . . . . . . . . . . . . . . . . . . . 247 Глава 16. Оценка скорости . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .249 Использование исторических значений . . . . . . . . . . . . . .250 Выполнение итерации . . . . . . . . . . . . . . . . . . . . . . . . . . . .252 Прогнозирование скорости . . . . . . . . . . . . . . . . . . . . . . . .254 Какой подход следует использовать. . . . . . . . . . . . . . . . .259 Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .260 Вопросы для обсуждения . . . . . . . . . . . . . . . . . . . . . . . . . 261 Глава 17. Буферизация планов для компенсации неопределенности . . . . . . . . . . . . .263 Функциональный буфер. . . . . . . . . . . . . . . . . . . . . . . . . . .265 Временной буфер. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .266
Содержание Отражение неопределенности в оценках . . . . . . . . . . . . .267 Комбинирование буферов . . . . . . . . . . . . . . . . . . . . . . . . .276 Временной буфер — это не раздувание сроков. . . . . . . .278 Ограничительные оговорки . . . . . . . . . . . . . . . . . . . . . . . .278 Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .279 Вопросы для обсуждения . . . . . . . . . . . . . . . . . . . . . . . . .280 Глава 18. Планирование проекта с участием нескольких команд. . . . . . . . . . . . . . . . . . . 281 Принятие общей базы для оценок . . . . . . . . . . . . . . . . . .282 Более быстрое добавление деталей в пользовательские истории . . . . . . . . . . . . . . . . . . . . . . .283 Опережающее планирование . . . . . . . . . . . . . . . . . . . . . .284 Включение в план поддерживающих буферов . . . . . . . . 287 Но ведь это уйма работы . . . . . . . . . . . . . . . . . . . . . . . . . .290 Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 Вопросы для обсуждения . . . . . . . . . . . . . . . . . . . . . . . . .292 Часть V. Отслеживание прогресса и информирование 293 Глава 19. Мониторинг плана релиза. . . . . . . . . . . . . . . . . . . . . . .295 Отслеживание процесса разработки релиза . . . . . . . . . .296 Диаграмма выгорания релиза. . . . . . . . . . . . . . . . . . . . . .299 Диаграмма парковки . . . . . . . . . . . . . . . . . . . . . . . . . . . . .306 Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .307 Вопросы для обсуждения . . . . . . . . . . . . . . . . . . . . . . . . .308 Глава 20. Мониторинг плана итерации . . . . . . . . . . . . . . . . . . . .309 Доска задач . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .309 Диаграммы выгорания итерации . . . . . . . . . . . . . . . . . . . 313 Отслеживание затраченных сил и времени . . . . . . . . . . . 314 Индивидуальная скорость . . . . . . . . . . . . . . . . . . . . . . . . . 315 Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 Вопросы для обсуждения . . . . . . . . . . . . . . . . . . . . . . . . . 316 Глава 21. Информирование о плане. . . . . . . . . . . . . . . . . . . . . . . 317 Информирование о плане . . . . . . . . . . . . . . . . . . . . . . . . . 319 Информирование о прогрессе . . . . . . . . . . . . . . . . . . . . . 321 Итоговый отчет в конце итерации . . . . . . . . . . . . . . . . . . .324 Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .327 Вопросы для обсуждения . . . . . . . . . . . . . . . . . . . . . . . . .328
Agile-подход к оценке и планированию Часть VI. Почему работает agile-подход к планированию 329 Глава 22. Почему работает agile-подход к планированию . . . 331 Частое изменение плана . . . . . . . . . . . . . . . . . . . . . . . . . .332 Оценки размера и сроков разделяются . . . . . . . . . . . . . .333 Планы составляются на разных уровнях. . . . . . . . . . . . . .334 Планы ориентируются на функции, а не на задачи . . . . .335 Небольшие истории поддерживают постоянство потока работы . . . . . . . . . . . . . . . . . . . . . . . .335 Незавершенная работа ликвидируется в каждой итерации . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .336 Отслеживание прогресса осуществляется на уровне команды. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 Неопределенность признается и учитывается при планировании . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 Правила применения agile-подхода к оценке и планированию . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .338 Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 Вопросы для обсуждения . . . . . . . . . . . . . . . . . . . . . . . . . 341 Часть VII. Анализ конкретного примера 343 Глава 23. Конкретный пример: Bomb Shelter Studios . . . . . . . .345 День 1 — утро понедельника. . . . . . . . . . . . . . . . . . . . . . .346 Оценка пользовательских историй . . . . . . . . . . . . . . . . . .356 Подготовка к исследованию продукта . . . . . . . . . . . . . . .369 Планирование итерации и релиза, раунд 1 . . . . . . . . . . . 373 Две недели спустя . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .394 Планирование второй итерации . . . . . . . . . . . . . . . . . . . .395 Две недели спустя . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .398 Пересмотр плана релиза . . . . . . . . . . . . . . . . . . . . . . . . . .399 Презентация пересмотренного плана у Фила . . . . . . . . .403 Восемнадцать недель спустя. . . . . . . . . . . . . . . . . . . . . . .407 Список литературы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .409 Предметный указатель . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Об авторе Майк Кон — основатель Mountain Goat Software, фирмы, занимающейся консалтингом в сфере управления процессами и проектами. Майк специализируется на помощи компаниям в применении agileподхода с целью повышения эффективности. Он также является автором книги «Пользовательские истории: Гибкая разработка программного обеспечения» и книг по языкам программирования Java и C++. За спиной у Майка более чем 20-летний опыт работы руководителем в организациях разного размера, от стартапа до компании из списка Fortune 40. Его статьи можно найти в таких изданиях, как Better Software, IEEE Computer, Cutter IT Journal, Software Test and Quality Engineering, Agile Times и C/C++ Users Journal. Он часто выступает на отраслевых конференциях, является соучредителем организации Agile Alliance и входит в ее совет директоров. Майк — сертифицированный Scrum-мастер и тренер, член Компьютерного общества IEEE и Ассоциации компьютерной техники. Для получения дополнительной информации обращайтесь на сайт www.mountaingoatsoftware.com или отправьте запрос по адресу mike@mountaingoatsoftware.com.
Предисловие Куда бы я ни попадал в agile-мире, везде слышал одни и те же вопросы: Как подходить к планированию, когда работает большая команда? Каким должен быть размер итерации? Как представлять руководству данные о прогрессе в разработке? Как приоритизировать истории? Как получить представление о проекте в целом? Настоящая книга дает ясные ответы не только на эти, но и на многие другие вопросы. Если вы руководитель проекта , исполнитель проекта, разработчик или директор, то найдете здесь инструменты, необходимые для оценки, планирования и управления agile-проектами практически любого масштаба. Я знаю Майка Кона уже пять лет. Мы познакомились вскоре после подписания Agile-манифеста. Майк привнес в организацию Agile Alliance заряд энтузиазма и энергии. Любой проект, за который бы он ни взялся, выполнялся полностью и на хорошем уровне. Его вклад был видимым и ценным. Майк очень быстро стал незаменимым членом этой молодой организации. К созданию данной книги он подошел так же профессионально, тщательно и энергично. Этого нельзя не заметить, это сквозит в каждой строчке.
Agile-подход к оценке и планированию Это видно по тому, что рекомендации в книге носят исключительно практический характер. Здесь нет теоретических абстракций. Автор не заставляет читателя витать в облаках, созерцая проблемы с высоты 10 000 метров. Майк приводит конкретные примеры, методы, инструменты, графики, рецепты, а главное — аргументированные рекомендации. Эта книга — практическое руководство по оценке и планированию. Она сдобрена описанием случаев из практики Майка, связанных с применением рассматриваемых методов и инструментов. Он рассказывает, когда они давали результат, а когда нет, говорит о том, где можно оступиться, а где все будет нормально. Вы найдете в книге не обещания, панацеи и гарантии, а в буквальном смысле кладезь добытого с большим трудом опыта. Гибкий подход к оценке и планированию затрагивают многие работы, однако таких, где этот подход является главной темой, единицы. Равных же этой книге по глубине и полезности вообще нет. В ней данная тема рассматривается настолько полно, настолько практично, что, на мой взгляд, ее можно считать фундаментальным трудом. Возможно, я преувеличиваю, но она меня зацепила. Зацепила тем, что в ней даны квалифицированные ответы на многие давно ожидающие решения вопросы. Она стала инструментом, который я могу предложить клиентам, когда они ставят сложные про блемы. Меня радует, что эта книга вышла в свет и вот-вот попадет к читателю. Мне очень приятно, что она вошла в курируемую мной серию. Думаю, это бестселлер. Роберт Мартин, редактор серии
Предисловие Читая книгу или рукопись в первый раз, я всегда задаю себе вопрос: «Что нового автор привносит в эту область?» В случае Майка у меня два ответа: его книга расширяет наше представление о том, «как» подходить к оценке и планированию, а также «почему» важны определенные методы. Agile-подход к планированию обманчив. Может показаться, что он довольно легок: создайте карточки историй , присвойте им приоритет, распределите их по итерациям, а затем добавьте детали — и получите план следующей итерации. Основы планирования можно объяснить команде за пару часов, и ей потребуется всего несколько часов, чтобы составить сносный план (для небольшого проекта). Книга Майка здорово помогает перейти от сносных планов к составлению очень хороших планов. В этом месте я предельно аккуратно подбираю слова. Я не говорю «превосходных планов», поскольку, как подчеркивает Майк в своей книге, выигрыш от превосходного плана по сравнению с (довольно) хорошим планом чаще всего оказывается не настолько значительным, чтобы тратить на него дополнительные силы. Поначалу мои мысли о книге Майка крутились вокруг концепции agile-подхода к планированию. Меня всегда удивляло, а порой расстраивало массовое непонимание сути agile-подхода к планированию. То и дело слышишь саркастические замечания о том, что «команды agile-проектов не занимаются планированием» или
Agile-подход к оценке и планированию «agile-команды не придерживаются ни определенных сроков, ни определенных требований». Даже Барри Боэм и Ричард Тернер не совсем правы в своей книге «Баланс гибкости и дисциплины: Руководство для сбитых с толку» (Balancing Agile and Discipline: A Guide for the Perplexed. Addison-Wesley, 2004), когда сравнивают традиционные методы планирования с agile-методами. Фактически Боэм и Тернер правильно понимают идею, но используют неверную терминологию. У них под термином «методы планирования» понимается «тщательно взвешенное сочетание прогноза и адаптивного приближения к прогнозу», а по отношению к термину «agile-методы» взвешивание является антонимом. Таким образом, противопоставление «традиционных методов планирования» и «agile-методов» несет совершенно неправильный посыл, что agile-команды не занимаются планированием. Нет ничего более далекого от реальной практики. Книга Майка дает правильную установку — планирование является неотъемлемой частью любого agile-проекта. В ней очень много говорится о том, почему планирование так важно, и о том, как сделать его эффективным. Во-первых, agile-команды планируют очень многое, но этот процесс более равномерно распределен по всему проекту. Во-вторых, agile-команды прямо учитывают тот критический фактор, который упускают из виду многие не использующие agile-подход команды, — неопределенность. Важно ли планирование? Несомненно, важно. Важна ли корректировка плана по мере накопления знаний и уменьшения неопределенности? Исключительно важна. Мне известно множество случаев, когда организации, которые на начальном этапе принимали нереальные обязательства, а потом не могли их выполнить, оказывались подходящими для заказчика, в то время как на тех, которые старались быть реалистичными (и понимали неопределенность), навешивали ярлык «неспособные соблюдать программу» или «некомандные игроки». Похоже, срыв поставки продукта считается приемлемым, а отказ принять обязательства (даже когда они очевидно нелепы) — нет. Agile-подход в мастерском представлении Майка сфокусирован на поставке ценного для пользователя продукта, а не на составлении ничем не оправданных и невыполнимых планов и принятии обязательств. Agile-разработчики, по существу, говорят: «Мы предоставим вам план на основе того, что нам известно в настоящий момент;
Доступ онлайн
В корзину