Scrum
Scrum - это гибкий фреймворк, который помогает командам решать сложные задачи короткими итеративными циклами с помощью фиксированных ролей, событий и артефактов.
Scrum - это гибкий фреймворк для разработки и управления сложными продуктами, изначально сформировавшийся в разработке программного обеспечения и теперь используемый во многих отраслях. Он опирается на идею эмпирического управления процессом: вместо того чтобы заранее полностью спланировать задачу от начала до конца, команда работает короткими, фиксированными временными рамками, называемыми Sprint, обычно продолжительностью от одной до четырёх недель. Каждый Sprint завершается пригодным к использованию приращением работы, что создаёт пространство для обратной связи и позволяет команде корректировать следующие шаги. Это сочетание прозрачности, проверки и адаптации делает Scrum хорошо подходящим для работы, где требования неопределённы или могут измениться.
Scrum определяет три фиксированные роли. Владелец продукта отвечает за ценность продукта и ведёт бэклог продукта - список задач с расставленными приоритетами. Scrum-мастер следит за тем, чтобы команда работала в рамках фреймворка, устраняет препятствия и способствует сотрудничеству, не назначая задачи напрямую. Команда разработки самостоятельно планирует и выполняет работу. Четыре повторяющихся события задают структуру каждому Sprint: планирование Sprint в начале, daily scrum для быстрой синхронизации, обзор Sprint для демонстрации созданного и ретроспектива Sprint для улучшения совместной работы команды.
Scrum лучше всего работает для задач, где объём или решение изначально не полностью ясны, например в разработке продуктов или сложных проектах с множеством заинтересованных сторон. От Kanban его отличают фиксированные временные рамки и определённые роли, тогда как Kanban больше опирается на непрерывный поток без заданных итераций. По сравнению с классическим водопадным планированием его преимущество - регулярная проверка: ошибочные суждения выявляются рано, а не только в конце проекта. На практике Scrum часто терпит неудачу не из-за самого фреймворка, а из-за половинчатого исполнения, например когда ретроспективы пропускаются или бэклог не поддерживается в актуальном состоянии.
Практический пример
Машиностроительная компания среднего размера разрабатывает новое программное обеспечение для мониторинга своего производственного оборудования. Команда из пяти человек работает Sprint по две недели: в начале каждого Sprint она выбирает десять самых важных пунктов примерно из 40 открытых записей в бэклоге, синхронизируясь ежедневно на 15-минутном daily scrum. После десяти Sprint, то есть через пять месяцев, готова первая пригодная к использованию версия - вместо изначально запланированных девяти месяцев разработки без промежуточного результата. Ретроспективы показывают, что нечёткие требования стоили команде около 20 процентов её мощности за первые три Sprint, поэтому с этого момента владелец продукта начинает писать более чёткие описания в бэклоге.
Как помогает Leanshift
По сути, ретроспектива Sprint - это просто повторяющийся цикл Kaizen: команда делает паузу, честно смотрит на только что завершённую работу и сознательно улучшает то, как она работает, прежде чем двигаться дальше. Это соответствует взгляду Leanshift на то, что улучшение - не разовый проект, а регулярная привычка, встроенная в повседневную работу. Команды, которые так живут, улучшают не только продукт - они создают больше людей, умеющих улучшать самостоятельно.
Часто задаваемые вопросы
Полезен ли Scrum только для разработки программного обеспечения?
Нет. Scrum зародился в разработке ПО, но теперь используется в маркетинге, разработке продуктов, образовании и других областях - везде, где работа сложна, а требования могут меняться по ходу дела.
Чем Scrum отличается от Kanban?
Scrum работает в фиксированных временных рамках, называемых Sprint, с определёнными ролями и событиями, тогда как Kanban визуализирует непрерывный поток работы без заданных итераций и фокусируется на ограничении объёма одновременно выполняемой работы.
Действительно ли небольшой команде нужен отдельный scrum-мастер?
Не обязательно как отдельная роль на полную занятость. В небольших командах эту роль часто берёт на себя кто-то параллельно с основной работой; важно, чтобы фасилитация и сам фреймворк реально соблюдались.