Agile и Критическая цепь

Автор: Роб Ньюболд (Rob Newbold)

Введение

В настоящее время гибкие (Agile) подходы к разработке программного обеспечения (ПО) дают ряд важных преимуществ для компаний-разработчиков ПО. Agile фокусируется на частых итерациях (коротких циклах релизов), что сокращает время разработки. Кроме того, Agile сокращает расстояние между разработчиками, которые создают код (вместе с ошибками), и клиентами, которым нужно работающее приложение для решения реальных проблем. [1] Быстрое взаимодействие (например, размещение в одном офисе) позволяет быстрее реагировать на изменение ситуации. Могут выпускаться промежуточные релизы, чтобы быстрее добавить важные функции и исправить критические ошибки. [2]

Некоторые считают, что Agile принципиально расходится с планированием Критической цепи, потому что они используют принципиально разные подходы к планированию. В Agile акцент делается на гибкость и быструю реакцию. Все вокруг изменяется. И вы выбираете приоритетные функции и планируете итерации, с учетом того, что планы могут в любой момент измениться из-за возникновения непредвиденных ситуаций, изменения бизнес потребностей, требований заказчика и технологии. В Критической цепи создаются долгосрочные планы деятельности, которые, как правило, распределяют ресурсы.

Бем и Тернер [3] находят резкое различие между плановым управлением и гибкими методами. Они подразумевают полномасштабный конфликт: вы планируете (упорядочены), или вы гибки? Авторы представляют идеи для создания баланса между гибкостью и дисциплиной, которые хотя и выглядят привлекательно, вызывают подозрения о компромиссе. Но я полагаю, что в реальности нет места выбору «или-или». На самом деле нет никаких конфликтов между планированием Критической цепи и Agile, это мифы. Я хочу развенчать пару мифов и предложить подход для использования планирования Критической цепи в мире Agile.

Мифы

Миф 1: Критическая цепь несовместима с фундаментальными принципами Agile

Реальность: Я хотел бы отослать вас к Манифесту (Agile Manifesto). Лично я вижу в нем всего пару пунктов, которые могут вызвать трения:

№2: Мы приветствуем изменения требований даже на поздних стадиях разработки. Agile процессы используют изменения для повышения конкурентного преимущества заказчика.

В Критической цепи мы стараемся определить все обязательства заблаговременно. Тем не менее, вы всегда можете изменить задачи и требования. График является инструментом, а не смирительной рубашкой. Если ваши долгосрочные обязательства нужно изменить, измените их. (Но я также рекомендую вам четко определить, что вы подразумеваете под «обязательствами»).

№7: Работающая программа является лучшим показателем прогресса.

Agile уделят больше внимания требованиям клиентов, а не заполнению документации и выполнению процесса. С этой точки зрения я не вижу конфликта. С другой стороны, реальный показатель прогресса – Критическая цепь – это удовлетворение самых важных потребностей бизнеса разработчиков, которое, как правило, переводится в удовлетворение потребностей клиентов. Будьте осторожны, этот принцип не означает: «чем более работоспособно программное обеспечение, тем больше прогресс».

Миф 2: Критическая цепь означает, что вы должны планировать каждую итерацию в деталях и далеко на будущее [4]

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

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

Может оказаться полезно перейти на другую сторону и посмотреть на принципы Критической цепи по отношению к Agile. Но правда заключается в том, что я не увижу каких-либо конфликтов между Agile и шестью принципами, изложенными в моей книге Billion Dollar Solution: Secrets Of Prochain Project Management (Ответственность. Движущая сила. Приоритеты. Статус. Планирование. Неопределенность).

Когда и как использовать Критическую цепь вместе с Agile

Давайте перейдем к конкретике и поговорим о том, когда и как стоит использовать Критическую цепь для разработки программного обеспечения. Должен признать, что довольно трудно дать подробный рецепт, потому что есть множество вариантов Agile и множество типов проектов по разработке ПО. [5]

Для начала, если вы не имеете (или не хотите иметь) хорошо развитой гибкой методологии, я бы порекомендовал Критическую цепь по причинам, рассмотренным в книге. Если вы уже используете Agile, Критическая цепь будет ценной для проектов по разработке ПО, если вам нужны:

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

Что касается «как», думайте о графике Критической цепи как об общей картине, которая помогает предсказать поставки, прогнозировать использование ресурсов, и управлять межпроектными взаимодействиями. Думайте об Agile, как о детальной картинке, которая помогает убедиться, что работа управляется хорошо и гибко.

Чтобы использовать планирование Критической цепи в мире Agile, адаптируйте следующие шаги:

1. Установите общие цели релиза в зависимости от потребностей бизнеса и требований реального заказчика. Вам, возможно, потребуется запланировать несколько релизов с течением времени.
2. Рассмотрите два типа приоритетов, как вы рассматриваете функции: приоритеты, основанные на бизнес-потребностях, и приоритеты, основанные на рисках.
3. Создайте график Критической цепи для (по меньшей мере) критически важных функций на высоком [общем] уровне, с адекватным буфером и примерными потребностями в ресурсах. В общем случае, запланируйте функции с высоким риском заранее, чтобы иметь больше времени для управления рисками. Новая или рискованная разработка потребует больших буферов. [6] Используйте сфокусированную (не раздутую) продолжительность для задач и учитывайте поддержку и создание документации в вашей общей картине ресурсов.
4. Планируйте ближайшую работу более подробно, отдаленную – не углубляясь в детали. Детали могут быть добавлены в график, когда придет время, этот подход иногда называют «методом набегающей волны». Для многих проектов нет необходимости объединять планы итераций с графиком Критической цепи. Это нормально, пока они примерно совпадают, и оба являются достаточно достоверными. Просто убедитесь, что оба типа планов подчиняются приоритетам вашего бизнеса.
5. Добавляйте низкоприоритетные функции в релиз, только если вы уверены, что у вас по-прежнему есть время и ресурсы, необходимые для последующих важных задач, таких как тестирование, исправление ошибок, создание руководства пользователя и т.д. Это тот же принцип Agile – отказываться от функций, для реализации которых недостаточно времени. Время на тестирование, которое так часто вжимают между окончанием разработки и датой релиза, не должно использоваться в качестве буфера.
6. Сравните суммарную мощность ресурсов с требованиями и планируйте релизы в соответствии с глобальной доступностью ресурсов.

Ключевые моменты

• Agile и Критическая цепь не конфликтуют между собой.
• Необязательно включать детальное планирование итераций в график Критической цепи.
• Тестирование не является буфером.
• Если вы собираетесь использовать Agile, это поможет вам оставаться гибким и в подходе к планированию.

Примечания

[1] Eliyahu M. Goldratt and Robert E. Fox, The Race (North River Press, Croton-on-Hudson, 1986), David J. Anderson, Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results (Upper Saddle River, NJ: Prentice Hall, 2004), chap. 23.
[2] http://www.rocksintogold.com/.
[3] B. Boehm and R. Turner, Balancing Agility anil Discipline: A Guide for the Perplexed
(Addison-Wesley: Boston, MA, 2003).
[4] http://forums.construx.eom/forums/t/775.aspx.
[5] Matt Gelbwaks. “Segway and an Agile Critical Chain,” Cutter IT Journal, March 2003, 24-28
[6] Rob Newbold, The Billion Dollar Solution, chapter 1, 4 of Anderson’s book.

 

Книга в подарок

Опубликована наша книга «Прорыв. Единственный путь развития бизнеса». Это бизнес-роман о производственном предприятии, столкнувшимся с «потолком» в своем развитии. Для прорыва в развитии руководству и персоналу приходится преодолеть собственные, выстраданные на опыте, но устаревшие убеждения. Читателю предлагается пройти через этот прорыв вместе с героями. Вы увидите трудности такой трансформации, осознаете природу сопротивления изменениям и реальный путь к таким изменениям.
Подпишитесь на наш Telegram-канал и получите книгу в подарок!

Получить подарок

---

Лучшие статьи каждую среду в нашей рассылке. Присоединяйтесь к TOCpeople!

Подписаться

Нажимая на кнопку «Подписаться», я принимаю условия Политики конфиденциальности.