Вы работаете в команде, которая хочет начать применять методики гибкого планирования? Вы работаете в режиме итераций, но не ощущаете от этого никакой пользы? В этой статье автор делится своим опытом, полученным при консультациях и обучении продуктовых команд IBM, и отвечает на вопрос: «Как начать разработку с использованием гибкого планирования?». Он рассказывает об основных идеях и приемах гибкого планирования и делится своими соображениями о том, что на самом деле работает, а что нет. Замечание редактора: по запросу автора были обновлены рисунки 1 и 4 и сделаны некоторые другие исправления.

«Мы ведем гибкую разработку, ведь мы работаем итерациями». Такое часто можно услышать от команд, заявляющих, что они применяют гибкие методологии. Но работать итерациями – это далеко не все, что нужно, чтобы быть по-настоящему гибким.

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

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

Коротко о гибкой (Agile) разработке ПО

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

На схожих фундаментальных концепциях основаны следующие современные способы анализа и операционного управления:

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

Данная статья поможет вам преодолеть эти сложности и перейти от просто итеративной разработки к действительно гибкой разработке. В статье затрагиваются следующие темы:

* Предложения по облегчению перехода команды к применению гибкого планирования.
* Советы по организации итераций. Насколько длинными они должны быть? Должна ли команда работать итеративно только во время работы над очередным релизом продукта? Чем следует заниматься команде в перерывах работы над релизами?
* Понимание роли владельца продукта (product owner) и рекомендации по созданию пользовательских историй. Что такое пользовательские истории (user story)? Кто должен их создавать? В чем разница между эпопеей (epic) и пользовательской историей? Какой объем работы должна заключать в себе пользовательская история? Кто такой владелец продукта? Какова роль владельца продукта в рабочем процессе?
* Практические советы по планированию и управлению резервом работ (backlog - объемом запланированной на выполнение работы) на уровне продукта, релиза и итерации. Каждому уровню планирования соответствует свой резерв работ. Что должны содержать эти разные резервы работ? Какой уровень точности оценок необходим для каждого уровня планирования?
* Приемы измерения и интерпретации производительности команды. Какие прогнозы вы можете делать на основе данных о производительности команды?

Читать статью полностью (IBM developerWorks)