В сфере разработки ПО термин итерация используется для обозначения периода времени, в течение которого выполняются действия, которые будут повторяться в следующих итерациях. Этот термин часто соотносят с процессом.
Итеративный процесс позволяет проанализировать, что было сделано – с целью дальнейшего улучшения или завершения работы. Он основывается на идее, что трудно (если не невозможно) преуспеть в чем-то с первого раза. Обратная связь, собранная по результатам одной итерации, помогает вносить улучшения в следующую. Итерации прекращаются, когда достигнутый результат оценивается как удовлетворительный.
Пока я писал эту книгу, я также использовал итеративный подход: отправил первый черновик первому рецензенту. Благодаря обратной связи, я выпустил новую, улучшенную версию книги, которую отправил следующему рецензенту, и так далее.
Scrum объединяет оба подхода с концепцией спринта:
✓ в конце спринта появляется инкремент продукта;
✓ обратная связь на этот инкремент позволяет скорректировать цель следующего спринта.
Другими словами, спринт – это итерация, в результате которой появляется новый контент (инкрементальный подход) и улучшается контент, добавленный в предыдущий инкремент (итеративный подход).
Пока я писал эту книгу, я использовал итеративный и инкрементальный подход: не рассылал черновик всей книги своим читателям, но делал это глава за главой. На протяжении какого-то времени я работал над первой версией одной главы одновременно с пересмотром другой главы после получения на нее обратной связи от одного или нескольких читателей.
Ученые знают, как бороться с неопределенностью в сложных задачах при помощи подхода: сначала предлагается гипотеза, затем она проверяется, и после наблюдения за результатом решается, принять ее или отклонить.
По сравнению с простым итеративным подходом, когда запрашивается обратная связь, а затем принимается или отклоняется в соответствии с субъективным суждением, в научном методе все основывается на практической проверке. Если мы используем этот подход для разработки какой-либо функции продукта, наблюдение после эксперимента позволяет либо убедиться в ее ценности и продолжать над ней работать, либо понять, что она не эффективна.
Lean Startup популяризировал эту концепцию тестирования гипотез и коротких спринтов для получения информации о новом продукте. Мы все постоянно слышим термин MVP (Минимальный жизнеспособный продукт, Minimum Viable Product), который, на мой взгляд, плохо отражает его суть. Ведь речь идет не о продукте, пусть даже с минимальным количеством функций, но о результате, который позволяет проверить предположения, и, следовательно, узнать новую информацию.
Если гипотеза не подтверждается, команда переключается на другую функцию продукта.
Достижение MVP соответствует окончанию стадии иследования и началу стадии эксплуатации.
С точки зрения жизненного цикла продукта, Lean Startup используется на стадии исследования, а Scrum – на стадии эксплуатации.
Рисунок 2.4 – Две стадии разработки продукта
Концепция Lean Startup предполагает малозатратный по ресурсам этап проверки гипотезы несколькими конечными пользователями.
Представим, что эта книга была опубликована в Интернете, глава за главой. Я мог бы предположить, что эта глава интересна, ориентируясь на три покупки в течение недели после публикации ее плана. К концу недели я мог бы проверить свою гипотезу, прежде чем приступить к редактированию главы (а так как моя книга опубликована классическим путем, через издательство, я буду опираться на реакцию избранных рецензентов).
На стадии использования также можно использовать данный прием, проверяя на практике гипотезу о части продукта (см. главу о бэклоге).
2.3 Спринт
Помимо итеративного и инкрементального процесса, какие еще можно выделить характеристики Scrum-спринта?
✓ Короткие итерации: продолжительность спринта варьируется от недели до месяца.
✓ Строгая последовательность: спринты не перемешиваются между собой.
✓ Четкий ритм: спринты имеют одинаковую продолжительность.
Рисунок 2.5 – Разница между инкрементальным и Agilе-подходом
Продолжительность спринтов всегда одинакова, что помогает команде держать ритм.
Внимание: надо держать ритм! Это позволяет избежать перегрузки. Необходимо помнить, что команда не сможет перерабатывать очень долго. Заставлять ее выходить за пределы своих возможностей означает снижать качество ее работы и подрывать здоровье ее участников: увеличивается количество ошибок, уменьшается мотивация, инженерные практики пренебрегаются.