Процессы разработки софта можно оценивать по различным критериям. Вероятность критических дефектов на продакшне, количество фич отгружаемых в единицу времени, предсказуемость сроков отгрузки и т.п. Причем каждая ситуация индивидуальна, поэтому разные компании организуют работу, оптимизируя разные критерии.
Мир ускоряется, всё очень быстро меняется, и поэтому сегодня многие бизнесы нуждаются в быстрой отгрузке софта. Оптимизируется при этом время от рождения идеи до отгрузки решения пользователям. Вы придумываете что-то, отгружаете, тестируете идею на живых пользователях, подстраиваете планы с учетом фидбэка, меняете систему дальше… И вы вероятно хотите итерировать как можно быстрее. Но позволяет ли это ваш процесс разработки?
На скорость отгрузки может влиять множество факторов. Самый очевидный – скорость, с которой разработчики педалят код. Один джуниор вероятно будет разрабатывать ту же фичу несколько дольше, чем три сеньора.
Но при прочих равных процесс разработки тоже сильно влияет на скорость отгрузки. Я хочу показать это на примере, описав несколько разных процессов. Чтобы нивелировать влияние скорости собственно девелоперской работы, я предполагаю, что команда супербыстрая, и когда она начинает работу над фичей (далее User Story – в терминах SCRUM методологии), проходит всего 0 дней до момента когда код уже готов и протестирован.
Другая неизменная деталь процесса: релизы фиксировано раз в неделю в один и тот же день, и за несколько дней до релиза код релиза замораживается – для проведения всех необходимых QA (quality assurance) мероприятий.
Далее много терминов из SCRUM. Напомню кратко, что у нас есть Product Owner, который предоставляет требования команде в виде атомарных User Story (истории), а команда эти требования воплощает в жизнь. Работа идет по итерациям, обычно одна или две недели длиной. В нашем случае итерация однонедельная, и релиз каждую итерацию.
Жизненный цикл истории включает ее создание product owner’ом, sizing (численная оценка сложности истории командой), planning (в нашем случае это будет фактически определение в каком релизе будет отгружена история), разработка, code review, тестирование, merge в integration branch, отгрузка на продакшн. Я привел упрощенное описание, достаточное для этого поста.
Итак, примеры различных процессов:
Process A:
Ненеля 1 Пятница – product owner создал user story.
Неделя 2 Понедельник – митинг, на котором команда обсуждает историю с product owner’ом.
Неделя 2 Среда – sizing meeting, история оценена командой и приоритизирована product owner’ом.
Неделя 3 Понедельник – planning meeting, история запланирована в итерацию, которая начнется в понедельник недели 4.
Неделя 4 Понедельник – работа над историей начата. Команда супербыстрая и успевает всё сделать в этот же день: разработка, code review, тестирование и merge в integration branch.
Неделя 4 Пятница – конец итерации, создан release branch. Код релиза заморожен.
Неделя 5 Понедельник – среда – прогоняются все regression тесты, включая ручные, проводится нагрузочное тестирование, тестирование нового кода на staging environment приближенному к продакшну и т.п.
Неделя 5 Четверг – релиз.
Несмотря на то, что команда супербыстрая, понадобилось 4 недели чтобы требование дошло от идеи до пользователя. Элементы процесса, которые не дают здесь отгрузить быстрее:
- расписание митингов: слишком большие промежутки между митингами discussion, sizing, planning;
- жестко планируемые итерации: история должна быть помещена в итерацию до ее начала, нельзя положить историю в итерацию когда она уже началась.
Process B:
Неделя 1 Пятница – product owner создал user story.
Неделя 2 Понедельник – sizing and planning meeting, история оценена командой, приоритизирована product owner’ом и запланирована в итерацию, которая начнется во вторник недели 2.
Неделя 2 Вторник – работа над историей начата. Команда супербыстрая и успевает всё сделать в этот же день.
Неделя 2 Пятница – конец итерации, создан release branch. Код релиза заморожен.
Неделя 3 Понедельник – прогоняются regression тесты.
Неделя 3 Четверг – релиз.
Процесс подготовки историй ускорен, все предварительные митинги сведены в один. Хотя процесс всё еще запрещает впихнуть историю в итерацию которая уже идет. Поэтому путь от идеи до релиза здесь займет в самом удачном случае две недели.
Process C:
Неделя 1 Четверг – product owner создал user story.
Неделя 1 Пятница – история оценена командой, приоритизирована product owner’ом. Если история имеет высокий приоритет – то команда сразу же откидывает в сторону все другие менее приоритетные дела и берется за работу. Команда, как вы помните, супербыстрая, и к концу дня протестированный код залит в integration branch.
Неделя 2 Четверг – релиз.
Здесь фактически был сломан один из принципов SCRUM – неизменность бэклога итерации. Но зато это позволило ускорить процесс настолько, чтобы в лучшем случае история могла быть отгружена всего через неделю после ее создания. В этой ситуации узким местом процесса становится уже непосредственно скорость работы команды, а также процесс QA релиза.
И такая разница в процессах может быть неочевидной для команды. Если не вглядываться внимательно, то внешне все процессы похожи: итерации и релизы одинаковой длины, одинаковый жизненный цикл историй. Команды похожего состава. Все работают. Но у одних получается сделать цикл тестирования бизнес-идей в 1 неделю, а у других – никак не меньше 4 недель.
Это фактор, который стоит учитывать. Хотя у более гибких процессов конечно есть и сайд-эффекты. Какие например сайд-эффекты процесса C вы видите?