Все о SCRUM. Изучение, разработка, интеграция
Шрифт:
Ученые знают, как бороться с неопределенностью в сложных задачах при помощи подхода: сначала предлагается гипотеза, затем она проверяется, и после наблюдения за результатом решается, принять ее или отклонить.
По сравнению с простым итеративным подходом, когда запрашивается обратная связь, а затем принимается или отклоняется в соответствии с субъективным суждением, в научном методе все основывается на практической проверке. Если мы используем этот подход для разработки какой-либо функции продукта, наблюдение после эксперимента позволяет либо убедиться в ее ценности и продолжать над ней работать,
Lean Startup популяризировал эту концепцию тестирования гипотез и коротких спринтов для получения информации о новом продукте. Мы все постоянно слышим термин MVP (Минимальный жизнеспособный продукт, Minimum Viable Product), который, на мой взгляд, плохо отражает его суть. Ведь речь идет не о продукте, пусть даже с минимальным количеством функций, но о результате, который позволяет проверить предположения, и, следовательно, узнать новую информацию.
Если гипотеза не подтверждается, команда переключается на другую функцию продукта.
Достижение MVP соответствует окончанию стадии иследования и началу стадии эксплуатации.
С точки зрения жизненного цикла продукта, Lean Startup используется на стадии исследования, а Scrum – на стадии эксплуатации.
Рисунок 2.4 – Две стадии разработки продукта
Концепция Lean Startup предполагает малозатратный по ресурсам этап проверки гипотезы несколькими конечными пользователями.
Представим, что эта книга была опубликована в Интернете, глава за главой. Я мог бы предположить, что эта глава интересна, ориентируясь на три покупки в течение недели после публикации ее плана. К концу недели я мог бы проверить свою гипотезу, прежде чем приступить к редактированию главы (а так как моя книга опубликована классическим путем, через издательство, я буду опираться на реакцию избранных рецензентов).
На стадии использования также можно использовать данный прием, проверяя на практике гипотезу о части продукта (см. главу о бэклоге).
2.3 Спринт
Помимо итеративного и инкрементального процесса, какие еще можно выделить характеристики Scrum-спринта?
Короткие итерации: продолжительность спринта варьируется от недели до месяца.
Строгая последовательность: спринты не перемешиваются между собой.
Четкий ритм: спринты имеют одинаковую продолжительность.
Рисунок 2.5 – Разница между инкрементальным и Agilе-подходом
Продолжительность спринтов всегда одинакова, что помогает команде держать ритм.
Внимание: надо держать ритм! Это позволяет избежать перегрузки. Необходимо помнить, что команда не сможет перерабатывать очень долго. Заставлять ее выходить за пределы своих возможностей означает снижать качество ее работы и подрывать здоровье ее участников: увеличивается количество ошибок, уменьшается мотивация, инженерные практики пренебрегаются.
Спринт
Почему так? Такой подход позволяет избежать почти законченного синдрома (минутку, я почти закончил!), из-за которого дата окончания спринта может быть неоднократно отодвинута.
Рисунок 2.6 – Отрезок времени
Помню, как еще до появления Scrum команды договаривались о дате контрольной точки. Когда они решали отложить обзор на два-три дня, по истечении этого срока оказывалось, что им нужно еще немножко времени на работу…
Концепция временных отрезков устраняет любые отсрочки: в запланированную дату команда проводит объективный обзор ее прогресса, а затем корректирует содержание следующих спринтов.
Рисунок 2.7 – Стая слепней помогает отрабатывать спринтерский бег на коротких дистанциях
Когда Scrum только появился, стандартной продолжительностью спринта был один месяц. Теперь видна тенденция сокращения спринтов до двух-трех недель. Если мы говорим о разработке ПО, то инженерные практики – непрерывная интеграция и развертывание – позволяют чаще выпускать новые версии продукта. Время, затраченное на развертывание версии, больше не является проблемой.
Продолжительность спринта кратна неделе: спринт не может длиться 13 или 17 дней. Так намного проще ориентироваться.
По части продолжительности. Здесь нет единого мнения, все зависит от контекста. Но она должна быть четко зафиксирована.
Результаты опроса, проведенного в мае 2015 на странице моего блога, показывают, что чуть меньше половины (44 %) команд проводят спринты продолжительностью в две недели, и почти для четверти (24 %) команд спринты составляют три недели.
Чтобы определить продолжительность спринта, существует несколько критериев, на которые нужно обратить внимание:
Производительность и результативность команды.
Готовность заинтересованных сторон давать обратную связь.
Простота в подготовке событий спринта – спринт предполагает дополнительную работу по организации событий.
Частота изменений – спринт представляет собой период стабильности. Когда начинается спринт, команда не должна отвлекаться на другие вещи, а состав команды не должен меняться. Любые изменения переходят на следующий спринт.
Определение продолжительности спринта является одной из задач начинающей команды (см. главу 13).
Цикл разработки – это последовательность стадий, каждая из которых отмечена определенными процессами. Для разработки программного обеспечения процессы обычно следующие: написание спецификации, архитектура (проектирование), написание кода, тестирование (интеграция и приемка). Для упрощения я буду использовать буквы С, A, К и T соответственно для обозначения этих действий на схемах.