Scrum

Scrum — это фреймворк для разработки сложных продуктов, определяемый небольшим набором ролей, событий и артефактов, работающих с фиксированным ритмом. Он определяет три области ответственности: владелец продукта, ответственный за максимизацию ценности работы, скрам-мастер, ответственный за эффективность процесса, и разработчики, которые создают инкремент. Его событиями являются сам спринт, планирование спринта, ежедневный скрам, обзор спринта и ретроспектива спринта.

Данная методология намеренно минималистична, она описывает то, что должно произойти, не предписывая, как именно. Это не методология, предоставляющая инженерные практики, методы оценки или форматы требований; эти вопросы остаются на усмотрение команды. Такой минимализм является преднамеренным, поскольку предпосылка методологии заключается в том, что команды, наиболее непосредственно участвующие в работе, должны определять свои собственные методы, но это также означает, что команда, внедряющая Scrum без дополнительных технических практик, имеет координационную структуру и не имеет инженерной дисциплины.

Каждое событие существует по какой-то причине, которая часто упускается из виду. Планирование определяет, что будет предпринято и почему. Ежедневный скрам предназначен для координации действий разработчиков и выявления препятствий, а не для составления отчета о состоянии дел для менеджера. Обзор предназначен для проверки прогресса с заинтересованными сторонами и корректировки направления, а не для демонстрации. Ретроспектива предназначена для улучшения работы команды. Когда эти мероприятия превращаются в ритуальные представления, забывая о своей первоначальной цели, они отнимают время и ничего не дают, что является наиболее распространенной жалобой на этот фреймворк.

Ответственность владельца продукта — это то, где чаще всего возникают проблемы при внедрении. Эта роль требует реальных полномочий для определения приоритетов и возможности постоянно принимать решения, а организации часто назначают человека, не обладающего ни тем, ни другим, которому приходится эскалировать каждое важное решение. Владелец продукта без полномочий превращает структуру в систему обработки очередей, в которой команда выполняет решения, принятые другими, теряя при этом гибкость, которая и послужила мотивацией для такого подхода.

Фиксированная продолжительность спринта служит определенной цели, которую стоит понять, прежде чем от нее отказываться. Постоянный ритм создает условия для планирования, анализа и адаптации, а также заставляет разбивать работу на части, которые можно выполнить и оценить. Команды, которые продлевают спринты, когда работа не вписывается в них, устраняют ограничение, которое приводило к декомпозиции, и, как правило, движутся в сторону более длительных циклов с менее частой обратной связью.

Ретроспектива одновременно является самым ценным событием и первым, от которого отказываются. Это механизм, с помощью которого команда улучшает свой собственный процесс, и без него команда бесконечно повторяет одни и те же препятствия. Ретроспективы, которые не приводят к изменению поведения, хуже, чем их отсутствие, потому что они показывают, что поднятие проблем ничего не дает, поэтому отслеживание того, действительно ли были выполнены выявленные действия, делает это событие значимым.

Данная методология гораздо лучше подходит для одних задач, чем для других. Она идеально подходит для разработки продуктов в условиях реальной неопределенности, стабильной команды и реального клиента, у которого можно учиться. Для незапланированной оперативной работы, технического обслуживания с непредсказуемым поступлением задач и ситуаций с высокой частотой прерываний она подходит значительно хуже, и в таких случаях командам часто лучше подходит подход, основанный на потоке, который не требует привязки к фиксированному пакету задач.

Поскольку эффективность зависит от авторитета, стабильности команды и организационной поддержки, а не от соблюдения установленного порядка, оценка должна анализировать результаты, а не соответствие требованиям. На практике подход к реализации устанавливается внутри организации. разработка продуктаРешения владельца продукта основаны на доказательствах, полученных из исследование продуктаи для малый или средний бизнес Зачастую целесообразно сократить накладные расходы, связанные с использованием данной структуры, в пользу более простой конфигурации, подходящей для небольшой команды.