а теперь перейдем к устройству фреймворка Scrum. Для начала отметим, что Scrum – нормированный процесс, и он описан в Scrum Guide. Он описан очень аккуратно: в нем четко определены функции элементов, и рекомендуется их процедурное содержание. При этом предполагается, что возможна и даже необходима адаптация для конкретного проекта. Однако, надо понимать, что с некоторого момента адаптации становятся настолько большими, что вы уже не можете говорить «мы работаем по Scrum», а должны говорить «у нас собственный процесс на основе Scrum». Об этом часто забывают, и в результате Скрамом сейчас по факту называют самые различные вещи.
Однако, в своем рассказе не буду строго следовать Scrum Guide. Основная причина в том, что он по-прежнему в значительной мере наполнен спецификой IT-проектов, в то время как Scrum применяется гораздо шире. Да и в самом IT характер проектов значительно изменяется. Я не выверял текст по Scrum Guide.
Я тут хочу оговориться, что текст далее в значительной мере посвящен IT. Сделано это не только потому, что, я думаю, много читателей будет из IT и им это интересно, но и потому, что если вы будете переносить процесс в другие отрасли и другие виды деятельности, то следует понимать те изменения, которые в IT потребовались для успешной реализации – вам придется делать аналогичные адаптации или смириться с недостаточной эффективностью процесса, или отказаться от него. Это касается не только Scrum, но и комбинированных процессов. И несмотря на все эти оговорки, можно сказать, что применение Scrum за пределами IT является более эффективным, чем регулярный менеджмент, и это дает компаниям преимущество – что и объясняет интерес к применению.
Начнем с сокращенной схемы.
Итерации: создаем ценность в каждой, а не просто квантуем поток
Основное изменение, которое принес Scrum в проектную работу – это деление потока работ на итерации, который и представлен на схеме. Рекомендуемая продолжительность итерации 2—4 недели, при том, что на практике встречаются и недельные итерации, а вот большая продолжительность не является эффективной, происходит размывание фокуса. Предполагается, что у нас есть список задач, которые следует выполнить для достижения цели – Product Backlog, и задачи там упорядочены по важности и приоритетам. О том, каким образом наполняется этот список, мы поговорим дальше. Перед стартом итерации из этого списка выбираются задачи, которые планируется выполнить в Sprint Backlog. Но, что важно, мы не просто выбираем некоторое количество задач из начала списка. Дело в том, что в конце итерации должен получиться целостное приращение к продукту, несущее ценность потребителю и пригодное к использованию. Собственно, в этом состояла основная революция: при традиционном проектном подходе команда работала несколько месяцев и продукт в понятном для потребителя и пригодном для использования виде собирался только в самом конце, а о пригодности для потребителя промежуточных сборок никто не заботился, даже если применялись практики continuous integration и проверка работоспособности