Обзор Скрама

За Пределами Традиционной Разработки

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

Альтернатива - кросс-функциональные команды с итеративной разработкой - также существуют уже несколько десятилетий, но не так широко распространены, как традиционная модель.

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

Обзор

Скрам - фреймворк разработки, в котором кросс-функциональные команды разрабатывают продукты или проекты в итеративно-инкрементальном стиле. Он структурирует процесс разработки в циклы, называемые Спринтам. Эти итерации не могут быть длиннее четырёх недель (обычно две недели), и идут одна за одной без остановки. Спринты ограничены по времени - они заканчиваются в определённые даты, независимо от того, была ли закончена работа или нет, и никогда не продлеваются. Обычно Скрам-команды выбирают длину Спринта один раз, а затем придерживаются её до того, как внедрят улучшения и смогут её сократить. В начале каждого спринта кросс-функциональная Команда (около 7 человек) выбирает элементы (требования пользователей) из приоритизированного списка. Команда договаривается об общей цели, в которую они верят и могут поставить в конце Спринта, что-то материальное и что будет действительно ”готово”. Во время Спринта новые элементы не могут быть добавлены; Скрам принимает изменения только в следующий Спринт, но текущий короткий Спринт предназначен для достижения небольшой, четкой и относительно стабильной цели. Каждый день Команда собирается ненадолго, чтобы провести инспекцию прогресса и адаптировать следующие шаги, необходимые для завершения оставшейся работы. В конце Спринта Команда проводит его обзор вместе с заинтересованными лицами, демонстрирует то, что готово. Люди получают обратную связь, которая может быть учтена в следующем Спринте. Скрам подчёркивает, что работающий продукт должен быть по-настоящему “готов“ в конце Спринта; в случае с разработкой программного обеспечения это означает, что система интегрирована, полностью протестирована, содержит документацию для конечных пользователей и потенциально готова к поставке. Ключевые роли, артефакты и события приведены на Иллюстрации 1.

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

Перевод статьи осуществлён Кротовым Артёмом и Романом Лапаевым.