Софт за 30 дней. Как Scrum делает невозможное возможным

Затраты на 30-дневный спринт могут варьироваться от 50 до 150 тысяч долларов в зависимости от размера Scrum-команды, заработной платы ее членов и других факторов. Каковы же преимущества метода?

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

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

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

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

Управление работой: диаграммы сгорания задач

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

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

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

Когда требования трансформируются в инкременты функционала. проявляется тенденция. Например, в начале первого спринта команда разработки оценила размер требований в 140 единиц работы. Она представила 20 единиц работы в спринте № 1, 40 единиц – в спринте № 2 и 40 единиц – в спринте № 3. Это может быть прослежено при помощи диаграмм сгорания задач, измеряющих требования в единицах работы, которую еще предстоит сделать. Оставшаяся работа вычисляется в конце каждого спринта. Она равна единицам работы, прогнозируемой в начале спринта, за вычетом единиц законченной работы, которая была переведена в инкремент к концу спринта. Как выглядит диаграмма сгорания задач для примерного проекта, показано на рис. 6.1.

Рис. 6.1. Пример диаграммы сгорания задач

Это дает представление о прогрессе, достигнутом в направлении, когда вся работа будет закончена.

Чтобы прогнозировать будущее, можно использовать средние значения прошедших спринтов. В первых трех средняя единица законченных требований была 33,3 со стандартным отклонением 11,5. Прогнозная линия строится, как показано на рис. 6.2.

Рис. 6.2. Пример прогноза

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

Новые требования появляются, когда проект продвигается вперед. В ходе тестов выясняются новые потребности клиентов. Когда инкременты изучаются, появляются новые возможности. К примеру, со 140 единиц требований в начале первого спринта, если 20, 40 и еще 40 единиц новых требований возникнут и будут добавлены в бэклог продукта в начале каждого из трех спринтов, диаграмма выгорания задач будет плоской, давая неправильное впечатление, что никакой работы не сделано (рис. 6.3).

Рис. 6.3. Реальная и предполагаемая диграммы сгорания задач

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

Чтобы сохранить тренд снижения диаграммы сгорания, вычисляется новая конечная базовая линия: [(начальная базовая линия + дополнительные единицы работы над новыми требованиями) – (законченные единицы работы над требованиями) = новая конечная базовая линия]. Эта новая конечная базовая линия показана на рис. 6.4. Она помогает нам спрогнозировать, что проект, скорее всего, будет закончен гораздо позднее, чем ранее предположенный конец четвертого спринта.