Как называется документ в котором команда фиксирует свои обязательства на один спринт

Обновлено: 09.05.2024

Создатели Scrum говорят, что это фреймворк для организации командной работы. Фреймворк предполагает комбинацию установок, действий и технологий, с которыми легче организовать рабочий процесс. Scrum опирается на Agile и является одной из его практических реализаций.

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

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

Scrum уточняет общий подход Agile: предлагает принципы поведения, набор ролей и описание мероприятий, которые помогут по-новому организовать разработку продукта.

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

Мы опишем процесс работы по Scrum, раскроем основные понятия и роли. Углубиться в тему помогут ссылки на более подробные статьи.

Что такое управление проектом Scrum

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

Состав scrum-команды

Чтобы команда была самоорганизованной (это важное свойство гибкой команды — она сама знает, как и что делать), состав особенно важен.

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

Вне команды находятся стейкхолдеры . Так называются заинтересованные стороны, например, заказчики проекта или директора компании.

Ценности, без которых ничего не получится

Для разработки по Scrum нужно соблюдать три принципа:

— прозрачность (доступная информация и однаковая интерпретация),

— инспекция (проверка своей работы),

— адаптация (быстрое внесение изменений, если что-то идёт не так).

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

  • преданность,
  • сосредоточенность,
  • открытость,
  • уважение,
  • мужество.

Много кто уже набил оскомину от разговоров про корпоративные ценности и агитацию от бизнес-тренеров. Но в скраме действительно не обойтись без них. Эти ценности дополняю манифест Agile. Следование им равно организации работы на ценностном уровне, собственно это и дает результат.

Под абстрактными словами подразумевается конкретное:

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

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

Открытость — это доступность информаци: каждый видит процесс и работу друг друга, имеет право голоса.

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

Уважение — пункт, который не требуется пояснять, но который регулярно нарушается. Все остальные принципы надстраиваются над ним.

Термины и практика

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

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

Спринт не единственное непонятное слово. Есть еще три: бэклог проекта, бэклог спринта и диаграмма сгорания. Вместе с инкрементом они называются артефакты .

Бэклог проекта — это:

Бэклог спринта — это:

В Scrum есть собственно работа над продуктом и еще четыре события, которые проводятся регулярно. Из-за этого их называют ритуалами.

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

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

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

Введение

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

Основа Scrum

  • Scrum Master
  • Product Owner
  • Team
Скрам Мастер (Scrum Master)

Скрам Мастер (Scrum Master) - самая важная роль в методологии. Скрам Мастер отвечает за успех Scrum в проекте. По сути, Скрам Мастер является интерфейсом между менеджментом и командой. Как правило, эту роль в проекте играет менеджер проекта или тимлид. Важно подчеркнуть, что Скрам Мастер не раздает задачи членам команды. В Agile команда является самоорганизующейся и самоуправлямой.

  • Создает атмосферу доверия,
  • Участвует в митингах в качестве фасилитатора
  • Устраняет препятствия
  • Делает проблемы и открытые вопросы видимыми
  • Отвечает за соблюдение практик и процесса в команде

Скрам Мастер ведет Daily Scrum Meeting и отслеживает прогресс команды при помощи Sprint Backlog, отмечая статус всех задач в спринте.

ScrumMaster может также помогать Product Owner создавать Backlog для команды

Product Owner

Product Owner - это человек, отвечающий за разработку продукта. Как правило, это product manager для продуктовой разработки, менеджер проекта для внутренней разработки и представитель заказчика для заказной разработки. Product Owner - это единая точка принятия окончательных решений для команды в проекте, именно поэтому это всегда один человек, а не группа или комитет.

  • Отвечает за формирование product vision
  • Управляет ROI
  • Управляет ожиданиями заказчиков и всех заинтересованных лиц
  • Координирует и приоритизирует Product backlog
  • Предоставляет понятные и тестируемые требования команде
  • Взаимодействует с командой и заказчиком
  • Отвечает за приемку кода в конце каждой итерации

Product Owner ставит задачи команде, но он не вправе ставить задачи конкретному члену проектной команды в течении спринта.

Команда (Team)

В методологии Scrum команда является самоорганизующейся и самоуправляемой. Команда берет на себя обязательства по выполнению объема работ на спринт перед Product Owner. Работа команды оценивается как работа единой группы. В Scrum вклад отдельных членов проектной команды не оценивается, так как это разваливает самоорганизацию команды.

  • Отвечает за оценку элементов баклога
  • Принимает решение по дизайну и имплементации
  • Разрабатывает софт и предоставляет его заказчику
  • Отслеживает собственный прогресс (вместе со Скрам Мастером).
  • Отвечает за результат перед Product Owner

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

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

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

Артефакты

Product Backlog

Product Backlog - это приоритезированный список имеющихся на данный момент бизнес-требований и технических требований к системе.

Product Backlog включает в себя use cases, defects, enhancements, technologies, stories, features, issues, и т.д.. Product backlog также включает задачи, важные для команды, например "провести тренинг", "добить всем памяти"

Product Backlog постоянно пересматривается и дополняется - в него включаются новые требования, удаляются ненужные, пересматриваются приоритеты. За Product Backlog отвечает Product Owner. Он также работает совместно с командой для того, чтобы получить приближенную оценку на выполнение элементов Product Backlog для того, чтобы более точно расставлять приоритеты в соответствии с необходимым временем на выполнение.

Sprint Backlog

Sprint Backlog содержит функциональность, выбранную Product Owner из Product Backlog. Все функции разбиты по задачам, каждая из которых оценивается командой. Каждый день команда оценивает объем работы, который нужно проделать для завершения задач.

Рис. 3. Пример Spint Backlog

Сумма оценок оставшейся работы может быть построена как график зависимости от времени. Такой график называется Sprint Burndown chart. Он демонстрирует прогресс команды по ходу спринта.

Спринт (Sprint)

В Scrum итерация называется Sprint. Ее длительность составляет 1 месяц (30 дней).

Результатом Sprint является готовый продукт (build), который можно передавать (deliver) заказчику (по крайней мере, система должна быть готова к показу заказчику).

Короткие спринты обеспечивают быстрый feedback проектной команде от заказчика. Заказчик получает возможность гибко управлять scope системы, оценивая результат спринта и предлагая улучшения к созданной функциональности. Такие улучшения попадают в Product Backlog, приоритезируются наравне с прочими требованиями и могут быть запланированы на следующий (или на один из следующих) спринтов.

Каждый спринт представляет собой маленький "водопад". В течение спринта делаются все работы по сбору требований, дизайну, кодированию и тестированию продукта.

Scope спринта должен быть фиксированным. Это позволяет команде давать обязательства на тот объем работ, который должен быть сделан в спринте. Это означает, что Sprint Backlog не может быть изменен никем, кроме команды.

Жизненный цикл спринта

Планирование спринта

В начале каждого спринта проводится планирование спринта. В планировании спринта участвуют заказчики, пользователи, менеджмент, Product Owner, Скрам Мастер и команда.

Планирование спринта состоит из двух последовательных митингов.

Планирование спринта, митинг первый

Участники: команда, Product Owner, Scrum Master, пользователи, менеджемент

Цель: Определить цель спринта (Sprint Goal) и Sprint Backlog -функциональность, которая будет разработана в течение следующего спринта для достижения цели спринта.

Артефакт: Sprint Backlog

Планирование спринта, митинг второй

Участники: Скрам Мастер, команда

Цель: определить, как именно будет разрабатываться определенная функциональность для того, чтобы достичь цели спринта. Для каждого элемента Sprint Backlog определяется список задач и оценивается их продолжительность.

Артефакт: в Sprint Backlog появляются задачи

Если в ходе спринта выясняется, что команда не может успеть сделать запланированное на спринт, то Скрам Мастер, Product Owner и команда встречаются и выясняют, как можно сократить scope работ и при этом достичь цели спринта.

Остановка спринта (Sprint Abnormal Termination)

Остановка спринта производится в исключительных ситуациях. Спринт может быть остановлен до того, как закончатся отведенные 30 дней. Спринт может остановить команда, если понимает, что не может достичь цели спринта в отведенное время. Спринт может остановить Product Owner, если необходимость в достижении цели спринта исчезла.

После остановки спринта проводится митинг с командой, где обсуждаются причины остановки спринта. После этого начинается новый спринт: производится его планирование и стартуются работы.

Daily Scrum Meeting

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

  • Что сделано вчера?
  • Что будет сделано сегодня?
  • С какими проблемами столкнулся?
  • Обсудить проблему с отрисовкой контрола
  • Петя и Вася
  • Сразу после скрама
Демо и ревью спринта

Рекомендованная длительность: 4 часа

Команда демонстрирует инкремент продукта, созданный за последний спринт. Product Owner, менеджмент, заказчики, пользователи, в свою очередь, его оценивают. Команда рассказывает о поставленных задачах, о том как они были решены, какие препятствия были у них на пути, какие были приняты решения, какие проблемы остались нерешенными. На основании ревью принимающая сторона может сделать выводы о том, как должна дальше развиваться система. Участники миитинга делают выводы о том, как шел процесс в команде и предлагает решения по его улучшению.

Скрам Мастер отвечает за организацию и проведение этого митинга. Команда помогает ему составить адженду и распланировать кто и в какой последовательности что представляет.

Подготовка к митингу не должна занимать у команды много времени (правило - не более двух часов). В частности, именно поэтому запрещается использовать презентации в Power Point. Подготовка к митингу не должна занимать у команды более 2-х часов.


Aджайл — это подход к разработке программ, описанный в Aджайл-манифесте. Этот документ раскрывает философию аджайла через четыре главные ценности:

  1. люди и взаимодействия важнее процессов и инструментов;
  2. работающая программа важнее исчерпывающей документации;
  3. сотрудничество с кастомером важнее согласования условий контракта;
  4. готовность к изменениям важнее следования первоначальному плану.

Aджайл-манифест служит скорее пособием о том, что такое аджайл и как его использовать, чем методологическим предписанием.

Ценности и принципы Aджайл-манифеста подразумевают адаптацию под каждую конкретную ситуацию. Поэтому аджайл находит воплощение в разных фреймворках.

Один из самых популярных среди них — скрам. Согласно опросу за 2015 год (2015 State of Scrum Survey Report) от ScrumAlliance, скрам широко применяется и будет применяться в разных бизнес-отраслях для успешной разработки различных проектов. Эта статья посвящена скрам-фреймворку, его истории, преимуществам применения скрама в компаниях, его ограничениям и тому, как применять скрам-структуру в вашей организации.

Что такое скрам


Любой разговор об успешном управлении проектами с помощью скрама стоит начинать с определения скрама.

Scrum Reference Card

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

Если же вы понимаете, что самостоятельное знакомство со скрамом заберет слишком много вашего времени, советуем посетить наш тренинг по скраму для начинающих Scrum Core 2.0. На нем вы за два дня получите исчерпывающие знания основ скрама, включая роли, события и артефакты, а также собственными глазами увидите, как его применяют в командах на практике.

Чем скрам-процесс не является


Скрам — не линейный метод разработки; это не каскадная модель. Каскадная модель (англ. waterfall) — линейная последовательность событий, когда продукт планируют, разрабатывают, тестируют и так далее. Ни один её этап нельзя начинать, пока не завершен предыдущий.

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

Зачем нужен скрам


У скрам-фреймворка аджайл-разработки четыре главных преимущества:

Краткая история


С тех пор главное пособие по скраму — Скрам Гайд — регулярно обновлялось. Самая свежая информация по нему содержится в Скрам Гайде 2020 года, а в этой статье мы коротко приводим основные ее разделы.

Как работает структура скрама

Процесс разработки по скраму

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

Роли в скраме

В скраме три роли, которые вместе образуют скрам-команду:

  • Владелец продукта — апологет продукта, который полностью понимает его ценность для бизнеса. Этот человек доносит потребности кастомера/стейкхолдера до разработчиков, но не отвечает за техническую сторону процесса. Владелец продукта также отвечает за пользовательские истории и определяет их приоритетность.
  • Разработчики выполняют все технические задачи по разработке. Они кроссфункциональны, их кроссфункциональность зависит от области работы. Тем не менее, разработчики всегда отвечают за создание бэклога спринта, обеспечение качества согласно определению готового, адаптацию плана согласно цели спринта и собственные экспертные области ответственности.
  • Скрам-мастер выступает фасилитатором работы скрам-команды. Скрам-мастер помогает владельцу продукта и разработчикам выполнять работу без препятствий и отвлекающих факторов. Вся коммуникация людей вне команды с разработчиками проходит через скрам-мастера. (Иногда скрам-команды взаимодействуют в формате скрама скрамов, то есть, собрания скрам-мастеров всех команд).

События в скраме


Есть пять типов скрам-событий:

  • Спринт (Sprint) — самое сердце скрама, где идеи приобретают ценность. Внутри спринта выполняется вся работа, необходимая для достижения цели продукта, в том числе планирование спринта, дейли скрамы, обзор и ретроспектива спринта.
  • Планирование спринта (Sprint Planning) — в нём участвуют все члены скрам-команды. На этом мероприятии презентуют продукт. Также каждый член команды может высказаться о том, что его интересует или беспокоит. В ходе встречи назначаются приоритеты и проводятся оценки сроков.
  • Ежедневный скрам (Daily Scrum) — скрам-события, которые проходят ежедневно во время спринтов. Они короткие (до 15 минут) и предназначены для того, чтобы спланировать дневное расписание разработчиков. Здесь можно обсудить рабочие сложности или прояснить пользовательские истории. Встреча обязательна для разработчиков в полном составе. Скрам-мастер может, но не должен на ней присутствовать.
  • Обзор спринта (Sprint Review) — демонстрация действующего продукта, разработанного во время спринта. Это мероприятие проходит в конце спринта и предназначено в первую очередь для того, чтобы в подробностях показать достигнутое стейкхолдерам.
  • Ретроспектива спринта (Sprint Retrospective) — это своего рода вскрытие, обсуждение того, как команда справилась во время спринта и как можно повысить качество её работы в будущем.

Дополнительно к этим типам мероприятий иногда во время спринта команды могут проводить уточнение бэклога (Backlog Refinement) — обсуждать элементы бэклога и готовиться к следующему спринту. В рамках этой встречи можно обсудить приоритетность элементов и разделить элементы бэклога на более мелкие составляющие.

Артефакты


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

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

Aртефакты спринта и их компоненты включают:

Правила скрам-фреймворка


Роли, события и артефакты — основные правила скрама, но есть и другие, которые также добавляют процессу эффективности:

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

Больше сведений по терминологии скрама вы сможете получить из глоссария.

Ограничения в скраме

  • Scrum часто приводит к сокращению объема работ из-за отсутствия общего дедлайна.
  • Высокие шансы на провал проекта, если люди не очень вовлечены или не готовы сотрудничать.
  • Применять структуру Scrum в больших командах сложно, но возможно. Для этого существуют фреймворки масштабирования: LeSS, SAFe, Nexus и другие.
  • Если какой-либо член команды уйдет в середине проекта, это может иметь сильное негативное влияние на проект.

Какая аджайл-методология подойдет именно вам?


Как и любое другое решение в бизнесе, выбор лучшей аджайл-методологии будет оптимальным, если вы сначала рассмотрите все возможные варианты. Например, вы можете обнаружить, что вам больше подходит eXtreme Programming (XP).

Методология XP похожа на скрам, но спринты короче, изменения бэклога во время спринта допустимы, а приоритеты XP определяет кастомер.

С другой стороны, вам может лучше подойти скрамбан (Scrumban). Скрамбан позволяет дополнять бэклог во время спринта и не требует оценки сроков во время планирования. Другими словами, методологии разнообразны, а это дает вам возможность выбрать оптимальный путь к счастью ваших кастомеров.

Переведено, адаптировано и дополнено командой BrainRain в соответствии с единственным официальным документом, который объясняет суть скрама — Скрам Гайдом (The Scrum Guide Reordered, 2020).

Ближайшее событие Professional Scrum with User Experience 21 – 22.01.2022

Уникальное событие Management 3.0 fundamentals 28 – 30.12.2021

Вас также может заинтересовать

Разработка нового продукта: новые правила игры (New new product development…

Что такое Agile и как его применить в бизнесе

Как возник скрам: история

Ближайшее событие Professional Scrum with User Experience 21 – 22.01.2022

Свежие публикации

Как вовремя сделать готовый инкремент: улучшаем сотрудничество в командах

Как вовремя сделать готовый инкремент: балансируем между поставками и срочностью

Scrum Guide 2020 Reordered

Подписывайтесь на нашу рассылку

Потому что от нее — сплошная польза и никакого спама. Вы будете получать ежемесячный дайджест с новыми статьями, ежеквартальное расписание событий BrainRain, приглашения на бесплатные вебинары и прочие полезности.

Please check your mail: you will now receive our greeting letter with a small gift in it 🎁

To avoid skipping BrainRain emails, move this email from the "Promotions" section to the "Inbox" section (if you’re using Gmail).

Схема приведена на рисунке. В прошлой статье мы обсудили изменения, которые потребовал переход к инкрементальной поставки ценности, и процедуру планирования, начинающую спринт. А в эта посвящена организации работы внутри спринта. Казалось бы, что об этом писать? Делаешь себе задачи и делаешь, и получаешь результат ☺ На самом деле, там тоже много интересных особенностей, обеспечивающих успех метода.

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

Передача через доску – предохранитель против возврата к классическому менеджменту. Прямому поручению нет места

Возникает вопрос: а какую задачу член команды должен взять с доски, когда он закончил предыдущую? Ответ: ту, взятие им которой наилучшим образом продвинет спринт к завершению. Это вопрос личного выбора, при котором он учитывает текущую ситуацию, представленную на доски, свои собственные компетенции и компетенции других членов команды. При этом, естественно могут быть приняты определенные правила, которые призваны облегчить выбор, сделать его быстрым. Например, правило выбирать самую важную задачу. Но правила могут быть и более сложными, например, в начале спринта приоритет может отдаваться задачам, которые на планировании оценили как наиболее рискованные по реализации, в том числе длительным, а в конце спринта, наоборот, небольшим задачам, чтобы уменьшить количество незавершенных задач. Могут быть правила, по которым при скоплении задач на поздних этапах исполнения часть членов команды переключались на них. То есть, если говорить об IT разработчики начинали заниматься тестированием, если тестировщики вдруг не успевают. Особую остроту это приобретает, если используются WIP- лимиты. Могут быть и другие правила.

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

Если срочные задачи появляются регулярно, то на такие задачи обычно выделяется резерв мощности команды при планировании спринта. Сгорание этого резерва можно отдельно рисовать на Burndown Chart снизу-вверх.

Управления срочными задачами также желательно вести через доску, а не прямыми поручениями. Задача может быть просто повешена на доску, если ее содержание ясно. Если требуются дополнительные пояснения, то хорошая практика – подождать до очередного Daily Scrum для информации всей команде.

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

Фиксация целей спринта и его объема - еще один предохранитель против возврата к классическому менеджменту в Sсrum. В первые спринты рекомендуется фиксировать скоуп жестко, не допуская изменений внутри. И, в любом случае, нужна политика, допускающая только действительно срочные изменений, которых не должно быть много, иначе фреймворк перестает быть эффективным. А зачем тогда им пользоваться?

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

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

Задача на 2-3 часа требует около получаса погружения, поэтому если исполнителя пару раз отвлекли, то время выполнения возросло в полтора раза

Хотя работа каждого члена команды идет автономно, необходима синхронизация движения. Для этого служит ежедневная встреча – Daily Scrum. В свое время он назывался StandUp meeting, потому что рекомендовалось проводить его стоя вокруг доски. Эта рекомендация по-прежнему актуальна, если команда сидит вместе, но в случае распределенной команды это невозможно. Отметим, сидеть в одном помещении, лучше – отдельном для команды также крайне важно. А проведение митинга стоя, а не сидя способствует, во-первых, тому, чтобы члены команды оторвались от своей текущей работы, а, во-вторых, не затягивали митинг. Это – статус, а не обсуждение работы.

Если на встрече выяснилось, что какая-либо задача требует отдельного обсуждения, то надо зафиксировать, и далее ответственный за задачу должен его отдельно организовать, например, сразу после митинга. Превращение Daily Scrum в обсуждение задач, а не статус – наиболее распространенная ошибка. Рекомендация продолжительности для Daily Scrum – 15 минут, и если команда систематически превышает его, то стоит подумать о причинах и способах сокращения. Что касается времени проведения, то его команда выбирает самостоятельно, с учетом индивидуального расписания работы ее членов. В те времена, когда все начинали работу одновременно, следуя корпоративным традициям хорошим вариантом было утро сразу после начала рабочего дня, но эти времена ушли в прошлое. Может быть выбрано время перед или после обеда, если команда обедает примерно в одно время. На Daily Scrum важно участие всех членов команды, и даже если по каким-то причинам они не могут быть лично, желательно дистанционное участие.

Процедура Daily Scrum следующая: люди говорят о том, что было сделано накануне с прошлой встречи, о том, чем предполагают заниматься, и о том, какие есть препятствия для движения вперед. Коротко. Как легко догадаться, при 15 минутах на команду из 7 человек каждому будет не более 2 минут. Поэтому препятствия – фиксируются и назначаются нужные обсуждения. В каком порядке говорят люди? Есть два подхода, наиболее простой – говорить по кругу. Другой порядок – на основе расположения задач на доске, начиная от крайне правой колонки, поскольку чем задача продвинулась дальше по этапам, тем важнее ее завершение.

Кроме статуса по текущим задачам Product Owner информирует команду о срочных задачах, включенных в спринт, и других важных изменениях. Но это не должно существенно увеличивать размер Daily Scrum, если требуется длительное обсуждение, то о его времени надо отдельно договориться.

Доска с задачами должна быть актуальна в любой момент для того, чтобы член команды мог выбрать очередную задачу. Но это относится к основной доске. Если команда использует электронную и физическую доску одновременно, или физическую доску и таск-трекер, то Daily Scrum является также точкой синхронизации досок, и по его итогам принято обновлять Burndown Chart. Процедура здесь произвольна, это вопрос самоорганизации команды, но забывать об этом не следует.

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

Мне кажется всё это применимо только к внутренним проектам организации. Для коммерческих задач должен существовать чёткий план со сроками и отчётными точками. И ответственность нужна персональная. Потому что заказчику важно понимать как продвигается проект.

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

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

Впрочем. спасибо за совет зайти на сайт. Думаю, такая антиреклама поспособствует его популярности среди серьезных людей.

А Agile для заказчика как раз обеспечивает то, что ему нужно - прозрачность продвижения проекта и реалистичный прогноз достижения результатов. И возможность своевременного принятия мер, если выясняется что проект требует гораздо больше средств и сил - это выясняется в первой четверти-трети проекта. а не перед завершением, как при классическом подходе. О том, как именно это обеспечивается, я еще буду говорить в говорить в своих статьях. А статистика показывает, что на старте успешность проектов Agile и регулярных была сопоставима, только Agile был много дешевле, а постепенно для Agile стали лучшие результаты. Собственно, без этого он бы никогда не завоевал мир, включая IT-отделы крупных корпораций - он сильно противоречит традиционной культуре.

А что Вы скажете на то, что большинство заказчиков хотят понимать бюджет ми этапность проекта ДО его начала? Для этого и делается предварительный этап по подготовке технического задания, где всё расписывается с максимальной детализацией, доступной на текущий момент.
Agile не даёт такой возможности. Часто встречаю его использование во внутренних процессах разных банков, но там денег дофига, им вполне можно поиграться с разными технологиями. Взять тот же Сбертех. Фантик красочный (типа грамотные программисты, новейшие технологии и т.п.). А на выходе пустота - продукта нет!
Поэтому для внутренних нужд при наличии финансирования это ещё может подойти. Особенно когда заказчиком является другой отдел :-)
Но в реальной жизни, когда в роли заказчика выступает сторонняя организация, это, увы, не работает!

Вообще в 2009-2012 годах на конференциях была достаточно популярна тема применения Agile в Fixprice-проектах. Основных идея две: (а) в оценку закладывается буфер и дальше идет слежение за его расходованием и (б) надо внимательно следить за соответствием ТЗ фактическому состоянию, вскрывать проблемы и дальше искать решения в обмене скоупа работ. И если со стороны Заказчика есть люди заинтересованные в реальном внедрении, а не в подписании актов, то процесс идет. А если их нет - то в проект лучше не ввязываться с самого начала.

Так что Agile работает сильно лучше, чем тщательное планирование. Иначе бы не стал стандартом отрасли.

Игра в покер в офисе, выброшенный функционал, брутальный редактор от админа для ЗАВУЧа, гигантские чертежи на стенах, исчезнувший менеджер проекта и норвежские арийцы, живая лента вместо десятков мессенджеров, интеграция с сервисом которого нет, а также маркеры, стикеры и голосование точками

Зачем так рисковать, если можно пойти совершенно другим путем?


Специфика SCRUM может отпугнуть, если никогда не работал с этим фреймворком, тем, что на старте еще не известна длина пути, который предстоит пройти, чтобы получить работающий проект и удовлетворяющий на 100%.
Заказчику трудно — он НЕ может подготовить стратегический план развития проекта с достоверными датами релизов. Неизвестность пугает, особенно когда нужно оплачивать этот путь уже сейчас.

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

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


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

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

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

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

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

SCRUM необходимо адаптировать к каждому конкретному проекту

Как заказчику и исполнителю начать работать по SCRUM?

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

В ходе трехдневного совместного тренинга мы, используя так называемый helicopter view, сформировали будущую систему крупными мазками и зафиксировали это на временной прямой в виде Project RoadMap.


Product owner - владелец продукта несет ответственность за достижение максимальной ценности продукта как результата работы, которую выполняет Команда Разработки. Еединственный человек, который отвечает за развитие продукта

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

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


Какие мы сделали выводы после этого этапа

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


Как это было. Для нас обязательно было получить 2 вещи: сформулированную цель спринта и утвержденный sprint backlog.

Наш product owner всегда начинал планирование спринта с описания того, что в первую очередь нужно сделать, — наиболее значимых историй. После этого команда производила оценку трудозатрат для всех user story, начиная с самой важной. В процессе у команды возникало много вопросов по поводу того, как это должно функционировать.

  • это позволяет бизнесу понять, какой функционал он может ожидать в конце спринта. Позволяет быть команде предсказуемой и быть "on the same page" с заказчиком
  • ценность реализованной наполовину истории нулевая, поэтому все запланированные в рамках одного спринта истории нужно решить.
  • любые изменения оценки в течение спринта игнорируются;

Цель спринта — то, ради чего спринт нужен. Самое главное, чтобы цель была обозначена в терминах бизнеса, а не технических. То есть языком, понятным даже людям вне команды, а Sprint backlog — это выборка историй из product backlog. Он представляет собой список историй, которые команда определила как наиболее важные на данном этапе и обязалась выполнить в течение спринта.


Какую реальную ценность дает: оцифрованная успеваемость реального класса, актуальные оценки, перспектива для автоматической подготовки месячной, семестровой, квартальной отчетности.

Какую ценность добавляет: информирование родителей о текущей успеваемости; комментарии преподавателя к домашнему заданию; минимальную, но реальную аналитику.

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



Для справки: чтобы зафиксировать окончательную (идеальную) версию, нам приходилось возвращаться к электронному журналу в течение нескольких спринтов.

Эта версия электронного журнала была получена после 12 спринта и ее уже можно было показывать родителям

Еще яркий пример итеративного SCRUM-подхода — конструктор расписания

А как делали расписание до этого?
Расписание составляли на склеенных листах ватмана А1 вручную: рисовали, выделяли цветными маркерами, склеивали. На это у завуча уходили недели и месяцы

Самая первая версия редактора: "Брутальный редактор для админа" - который составил расписание на 2018 год

  1. Каждый спринт должен иметь четко сформулированную цель.
  2. Упрощать функционал, а затем его развивать — это нормально. Чем так хорош SCRUM: нет единственно правильного пути в разработке продукта. Это не учебник с заданиями и правильными ответами в конце. Всегда можно рассматривать много альтернативных вариантов и выполнять их в разной последовательности. Если в конце спринта клиент получает законченную ценность, с которой он может работать, тестировать, вводить новые данные, и это продвигает вперед к глобальной финальной задаче, — это правильный путь.
  3. Основная философия SCRUM: не гнаться за красивым кодом на старте, а сконцентрироваться на том, чтобы дать заказчику рабочий инструмент. Поэтому можно мириться с ошибками в ходе работы, но нужно понимать: лучшее средство выявить эти ошибки — это перестать думать об идеальном коде на уровне архитектуры и дизайна, a сначала дать бизнесу работающий прототип.
  4. Важно по ходу обсуждения вносить изменения в user story, а все артефакты сохранять и прикреплять к карточкам.

Команда всегда адекватно оценит user story, если выполнены условия: подробно описано поведение реального пользователя, обозначены границы использования и допущения, перечислены критерии приемки. То есть команда понимает "что" нужно сделать и примерно предполагает "как".

Шкала оценки, или SCRUM-poker

В SCRUM оценка историй проходит не в часах или днях, а в story points. Это микс сложности, рисков и усилий, которые команда должна потратить, чтобы выполнить историю. Для каждой команды 1 story point — величина индивидуальная, эмпирическая, но каждый член команды чувствует ее.


Заметьте, последовательность значений на карточках — нелинейная. Вот, например, между 13 и 21 ничего нет. Почему так?


Во-первых, это нужно, чтобы избежать появления ложного чувства точности для больших оценок. Если история оценивается примерно в 17 story points, то нет смысла обсуждать, должна ли она быть 15, или 18, или 21. Все, что нам нужно знать, — историю сложно оценить. Поэтому мы назначаем ей оценку в 21. Ориентировочно.

Во-вторых, людям свойственно преувеличивать свои возможности, а шкала не позволяет сильно ошибаться с оценкой времени и ресурсов. Например, команда сошлась на мнении, что на одну из задач достаточно 6 story points. Но если нет уверенности, что хватит и 5, то лучше выбрать 8. Это позволяет устанавливать реальные сроки, в которые команда точно уложится. Плюс это помогает начать диалог между участниками, поделиться своим видением реализации story, озвучить риски и прийти к консенсусу.

  • Для аргументированной оценки каждый участник должен отлично понимать, в чем суть этой истории. Получая оценку от каждого члена команды, мы убеждаемся, что все в курсе, о чем идет речь. Это увеличивает вероятность взаимопомощи по ходу спринта. И главное: наиболее важные вопросы по этой истории всплывут как можно раньше.
  • Разностороннее видение проблемы приводит к сильному разбросу оценок. Такие разногласия лучше выявлять и обсуждать как можно раньше. После обсуждения разногласий — повторная оценка, голосование. Обычно пары циклов оценивания хватает, чтобы прояснить основные моменты и создать общее понимание.

Важно: Во время планирования мы обычно не знаем, кто будет выполнять ту или иную часть. Реализация user story требует участия специалистов для разных типов работ: архитектура, front-end, back-end, тестирование, подготовка реальных данных. Отдельно стоит такая группа работ, как проектирование и дизайн пользовательского интерфейса.

Яркий кейс: Живая лента

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

Читайте также: