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

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

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

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

Я видел проекты, где разработчики трудились и ночами, и в выходные дни, лишь бы успеть написать код вовремя. Чтобы успеть к дедлайну, слишком часто выбрасываются необходимые действия, такие, как юнит-тестирование, а когда дедлайны совсем уж поджимают, менеджеры добавляют в команду новых людей, не понимая, что это приведет лишь к (временному) снижению продуктивности, поскольку новичкам нужно будет сперва освоиться с командой и ее стилем работы (этот принцип красноречиво сформулирован в законе Брукса). Хуже того, тестирование часто вообще стопорится, поскольку фазы тестирования сокращаются от пары месяцев до пары недель - лишь бы уложиться в дедлайн. В самом запущенном случае, какой мне доводилось видеть, компания поставила раскладушки, чтобы разработчикам и тестерам не приходилось далеко ездить и они могли отдыхать буквально без отрыва от производства, покуда проект не сдан. Разработчики и тестировщики трудились по 14 часов в сутки, ели и спали прямо на рабочем месте. Столько усилий ради устойчивого темпа на каскадном проекте.

Оценка спринта

Когда я впервые прочитал фундаментальную работу Кента Бэка об экстремальном программировании, его принцип 40-часовой рабочей недели поначалу меня удивил. Хотя этот принцип часто неверно трактуется, что все должны работать по 40 часов в неделю, есть много компаний, у которых нет и 40 часов - они используют 36 или даже 32 часа. На самом деле Бэк имел в виду, что ни для кого нет необходимости работать больше этого. Вот это в наши дни и называется устойчивым темпов проектов Agile. Это такой темп, когда вы можете работать долго, в то время как постоянная работа по вечерам и выходным попросту изнашивает вас.

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

Каждый спринт имеет определенные начало и конец, подходящие, чтобы задать устойчивый темп. В начале спринта члены команды определяют, сколько усилий потребуют следующие элементы бэклога, обычно представленные пользовательскими историями, и планируют лишь столько работы, сколько смогут выполнить. Если оценка и планирование выполнены хорошо, команда сможет реализовать то, о чем шла речь, в следующий 2- или 4-недельный спринт.

Таким образом, команда обязуется сделать именно этот объем работы за именно этот спринт. Как команде оценить элементы бэклога надлежащим образом? Обычно эти элементы разбиваются на меньшие части (именуемые задачами), которые члены команды смогут выполнить. Затем команда оценивает объем работы в часах, необходимый для каждой задачи, суммирует всё и сопоставляет с доступными часами последующего спринта. Таким образом, команда берется выполнить задачи и, в свою очередь, пользовательские истории. Кажется, что это процедура ясная и ее легко внедрить, да (продолжение)?

Оригинал: http://www.infoq.com/articles/beat-red-sprint-anti-agile-pattern

Об авторе: Сандер Хоогендоорн - автор бестселлера «Это Agile», ценимый отец, программист, системный архитектор, оратор и писатель. В качестве служителя основам технологии и лидера в глобальном осмыслении Agile

Перевод: Александра Родсет

Сертифицированные курсы

Андрей Плетенев. Онлайн курс Agile. SCRUM. Курс включает более 20 уроков с практическими заданиями, которые индивидуально проверяются и комментируются тренером.

Еще интересные статьи на эту тему:

• Масштабируем Scrum (но не так, как вы подумали)
• Анти-паттерн "красного спринта": от спринтов к итерациям
• Анти-паттерн "красного спринта": крах маленьких проектов
• Кен Швабер: истоки и будущее Скрама
• Персональный Скрам