February 8, 2020

Agile. Оценка и планирование проектов


ОГЛАВЛЕНИЕ

Об авторе

Предисловие

Предисловие

Предисловие

Благодарности

Введение

Часть I. Проблема и цель

Глава 1. Цель планирования

Зачем это нужно

Что делает план хорошим

Что делает планирование гибким

Резюме

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

Глава 2. Почему планирование дает неудовлетворительные результаты

Планирование ориентировано на деятельность, а не на функцию

Многозадачность приводит к дальнейшим задержкам

Функции не разрабатываются в соответствии с их приоритетом

Мы не учитываем неопределенность

Оценки превращаются в обязательства

Резюме

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

Глава 3. Agile-подход

Agile-подход к проекту

Agile-подход к планированию

Резюме

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

Часть II. Оценка размера

Глава 4. Оценка размера в пунктах

Пункты – относительный показатель

Скорость

Резюме

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

Глава 5. Оценка размера в идеальных днях

Идеальное время и разработка программного обеспечения

Идеальные дни как показатель размера

Одна оценка, а не множество

Резюме

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

Глава 6. Методы оценки

Оценки – продукт совместной работы

Шкала оценки

Получение оценки

Покер планирования

Почему покер планирования работает

Резюме

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

Глава 7. Переоценка

Знакомство с сайтом SwimStats

Когда переоценка не требуется

Когда выполнять переоценку

Переоценка частично реализованных историй

Цель переоценки

Резюме

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

Глава 8. Что выбрать – пункты или идеальные дни

Доводы в пользу пунктов

Доводы в пользу идеальных дней

Рекомендации

Резюме

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

Часть III. Планирование на основе стоимости

Глава 9. Приоритизация тем

Факторы приоритизации

Объединение четырех факторов

Примеры

Резюме

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

Глава 10. Приоритизация по финансовой отдаче

Источники дохода

Пример: WebPayroll

Финансовые показатели

Сравнение отдачи

Резюме

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

Глава 11. Приоритизация по желательности

Модель удовлетворенности клиентов Кано

Относительное взвешивание: еще один подход

Резюме

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

Глава 12. Разбивка пользовательских историй

Когда нужно разбивать пользовательскую историю

Разбивка по границам данных

Разбивка по операционным границам

Удаление сквозной функциональности

Несоблюдение требований к быстродействию

Разбивка историй со смешанным приоритетом

Не разбивайте историю на задачи

Избегайте соблазна добавить взаимосвязанные изменения

Объединение историй

Резюме

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

Часть IV. Составление календарных графиков

Глава 13. Основные аспекты планирования релиза

План релиза

Обновление плана релиза

Пример

Резюме

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

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

Задачи, не распределенные во время планирования итерации

Чем различаются планирование итерации и планирование релиза

Планирование итерации на основе скорости

Планирование итерации на основе обязательств

Мои рекомендации

Соотнесение оценок задач с пунктами

Резюме

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

Глава 15. Выбор длины итерации

Факторы, влияющие на выбор длины итерации

Принятие решения

Два примера

Резюме

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

Глава 16. Оценка скорости

Использование исторических значений

Выполнение итерации

Прогнозирование скорости

Какой подход следует использовать

Резюме

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

Глава 17. Буферизация планов для компенсации неопределенности

Функциональный буфер

Временной буфер

Отражение неопределенности в оценках

Комбинирование буферов

Временной буфер – это не раздувание сроков

Ограничительные оговорки

Резюме

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

Глава 18. Планирование проекта с участием нескольких команд

Принятие общей базы для оценок

Более быстрое добавление деталей в пользовательские истории

Опережающее планирование

Включение в план поддерживающих буферов

Но ведь это уйма работы

Резюме

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

Часть V. Отслеживание прогресса и информирование

Глава 19. Мониторинг плана релиза

Отслеживание процесса разработки релиза

Диаграмма выгорания релиза

Диаграмма парковки

Резюме

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

Глава 20. Мониторинг плана итерации

Доска задач

Диаграммы выгорания итерации

Отслеживание затраченных сил и времени

Индивидуальная скорость

Резюме

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

Глава 21. Информирование о плане

Информирование о плане

Информирование о прогрессе

Итоговый отчет в конце итерации

Резюме

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

Часть VI. Почему работает agile-подход к планированию

Глава 22. Почему работает agile-подход к планированию

Частое изменение плана

Оценки размера и сроков разделяются

Планы составляются на разных уровнях

Планы ориентируются на функции, а не на задачи

Небольшие истории поддерживают постоянство потока работы

Незавершенная работа ликвидируется в каждой итерации

Отслеживание прогресса осуществляется на уровне команды

Неопределенность признается и учитывается при планировании

Правила применения agile-подхода к оценке и планированию

Резюме

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

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

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

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

Оценка пользовательских историй

Подготовка к исследованию продукта

Планирование итерации и релиза, раунд 1

Две недели спустя

Планирование второй итерации

Две недели спустя

Пересмотр плана релиза

Презентация пересмотренного плана у Фила

Восемнадцать недель спустя

Список литературы

ОТРЫВОК ИЗ КНИГИ

Об авторе

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

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

Это видно по тому, что рекомендации в книге носят исключительно практический характер. Здесь нет теоретических абстракций. Автор не заставляет читателя витать в облаках, созерцая проблемы с высоты 10 000 метров. Майк приводит конкретные примеры, методы, инструменты, графики, рецепты, а главное — аргументированные рекомендации. Эта книга — практическое руководство по оценке и планированию.

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

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

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

Роберт Мартин, редактор серии

Предисловие

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

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-разработчики, по существу, говорят: «Мы предоставим вам план на основе того, что нам известно в настоящий момент; мы будем адаптировать этот план так, чтобы реализовать вашу наиболее важную цель; мы будем адаптировать проект и наши планы по мере продвижения вперед и получения новой информации; мы ожидаем, что вы понимаете, о чем просите нас. Иными словами, гибкость, допускающая адаптирование к меняющимся условиям, и жесткое соблюдение первоначальных планов являются взаимоисключающими целями. В настоящей книге разбираются все эти утверждения.

Возвращаясь к критически важному вопросу управления неопределенностью, Майк превосходно показывает, как agile-подход к процессу разработки снижает одновременно и неопределенность целей (чтó мы реально хотим создать), и неопределенность средств их достижения (как мы будем создавать это). Многие сторонники традиционного планирования не понимают ключевого момента: планирование не устраняет неопределенность. Планы строятся на основе того, что мы знаем в данный момент. Неопределенность — это способ представления того, что нам неизвестно относительно целей и средств их реализации. Для большинства неопределенностей (отсутствия знания) единственным путем их снижения и приобретения знания является действие — выполнение каких-либо работ, создание чего-либо, моделирование чего-либо — и получение обратной связи. Подход многих руководителей проектов можно представить как «планирование, планирование, планирование — выполнение». Agile-подход — это «планирование–выполнение–адаптация», «планирование–выполнение–адаптация». Чем выше неопределенности проекта, тем важнее применение agile-подхода для успеха.

Я бы хотел проиллюстрировать «как» и «почему» из книги Майка на примере глав 4 и 5, где детально показано, как оценивать пользовательские истории в пунктах или идеальных днях, а также приведены все за и против для каждого из этих подходов. Я практиковал оба подхода при работе с клиентами, но слова Майка помогли кристаллизоваться моим представлениям об оценке историй в пунктах и позволили понять, что пункты являются частью эволюции — эволюции в направлении простоты. Организации, занимающиеся разработкой программного обеспечения, давно ищут ответ на вопрос «насколько велик данный элемент программного обеспечения?». Строитель способен дать довольно обоснованную оценку, имея данные о площади здания. Оценки разных строителей могут варьировать, но размер фиксирован (хотя отделочные работы, требования к материалам и т.п. также влияют на оценку) и остается постоянным. Разработчики программного обеспечения давно хотят иметь подобный показатель.

В сфере разработки программного обеспечения для измерения размера продукта поначалу использовали количество строк программы (этот показатель до сих пор не вышел из употребления). В текущем планировании, однако, количество строк программы находит ограниченное применение по целому ряду причин, включая трудозатраты на их подсчет. Затем на сцену вышли функциональные точки (и несколько аналогичных идей). Функциональные точки устраняли некоторые проблемы показателя количества строк, но по-прежнему требовали значительных трудозатрат для подсчета (нужно было оценивать входные данные, выходные данные, файлы и т.п.). Впрочем, на пути широкого использования функциональных точек встали не трудозатраты, а их сложность. По моему мнению, именно увеличение сложности подсчета — беглый просмотр веб-сайта International Function Point User Group (IFPUG) дает хорошее представление об уровне этой сложности — привело к сокращению использования этого показателя.

Так или иначе, потребность в оценке «размера» софтверного проекта никуда не исчезла. Проблема с обоими историческими показателями имеет две стороны — их сложно определять и они основаны на каскадном подходе к разработке. Нам же требуется показатель размера, который просто определить и можно применять без необходимости проходить все требования и фазы проектирования.

Два критически важных отличия пунктов от количества строк программы и функциональных точек заключаются в том, что они проще в расчете и могут определяться на значительно более раннем этапе. Почему они проще? Да потому, что характеризуют относительный размер, а не абсолютный. Почему их можно определять на более раннем этапе? Да потому, что они относятся в большей мере к относительному размеру, чем к абсолютному. Как подчеркивает Майк, оценка с использованием пунктов — это обсуждение историй за круглым столом (обмен знаниями) и предположительная оценка относительного размера истории. Оценка относительного размера, в отличие от оценки абсолютного, осуществляется на удивление быстро. К тому же после нескольких итераций оценки размера и поставки продукта точность предположительных оценок, даваемых командой, значительно возрастает. Описание Майком «как» и «почему» при сравнении оценки в пунктах и идеальных днях позволяет глубоко понять эту критически важную тему.

Еще одним примером тщательности изложения материалов Майком служат главы 9–11, посвященные приоритизации историй. Майк не ограничивается советом браться в первую очередь за истории с наивысшей стоимостью, а раскрывает ключевые аспекты стоимости: финансовые выгоды, затраты, инновации/знание и риск. Он дает четкие разъяснения по каждому из этих аспектов (включая общие представления о чистой приведенной стоимости, внутренней ставке доходности и других инструментах финансового анализа), а затем приводит ряд схем (с разной степенью упрощения) принятия решений по весам на основе рассмотренных аспектов стоимости.

Нередко новички в области agile-разработки полагают, что если применить определенную методологию 12, 19 или 8 раз, то это и будет Agile, Extreme, Cristal Clear или еще что-нибудь подобное. Однако на самом деле вы применяете методологию Agile, Extreme и т.п. только тогда, когда знаете достаточно, чтобы адаптировать ее к своей конкретной ситуации. Суть agile-разработки — непрерывное обучение и адаптация. Что Майк отлично делает в этой книге, так это знакомит нас с идеями и практикой, которые помогают вывести наши agile-оценку и agile-планирование на следующий уровень развития. Майк детально разъясняет, «как» подойти к делу, например провести оценку в пунктах и идеальных днях, и «почему» нужно подходить именно так, представляя плюсы и минусы показателей «пункты» и «идеальные дни». Хотя он обычно дает рекомендации (сам он предпочитает пункты), в книге Майк детально разъясняет, «как» подойти к делу, например провести оценку в пунктах и идеальных днях, и «почему» нужно подходить именно так, представляя плюсы и минусы показателей «пункты» и «идеальные дни». Хотя он обычно дает рекомендации (сам он предпочитает пункты), в книге достаточно информации, чтобы мы уверенно могли адаптировать методику к своей ситуации.

Именно в этом и заключается вклад Майка в данную область — сначала он помогает нам получать новые знания и опыт через оценку и планирование («как»), а затем принимать решения об использовании нового знания для адаптирования оценок и планов к новым, уникальным или просто конкретным ситуациям («почему»). Из полудесятка книг, которые я постоянно рекомендую своим клиентам, две принадлежат Майку. «Agile-подход к оценке и планированию» входит в мой список обязательных для изучения материалов для тех, кто хочет понять последние веяния в сфере agile-управления проектами.

Джим Хайсмит,

директор по agile-практике в компании Cutter Consortium,

Флагстафф, Аризона, август 2005 г.

Конец ознакомительного фрагмента...

GERMES — Бизнес-библиотека в Telegram

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