Scrum (разработка программного обеспечения) - Scrum (software development)

Разработка программного обеспечения
Активность ядер
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
Инструменты
Стандарты и свод знаний
Глоссарии
Контуры

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

Имя

Термин « схватка» при разработке программного обеспечения впервые был использован в 1986 году в статье Хиротаки Такеучи и Икудзиро Нонака под названием «Новая игра в разработку новых продуктов» . Статья была опубликована в выпуске Harvard Business Review за январь 1986 года . Термин заимствован из регби , где схватка - это построение игроков. Термин схватка был выбран авторами статьи, потому что он подчеркивает командную работу.

Иногда Scrum пишется заглавными буквами, как SCRUM . Хотя само слово не является аббревиатурой , его стиль написан с большой буквы, скорее всего, из ранней статьи Кена Швабера , в названии которой использовалась заглавная буква SCRUM .

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

Многие термины, используемые в Scrum, обычно пишутся с заглавных букв (например, Scrum Master , Daily Scrum ). Однако, чтобы сохранить энциклопедический тон, в этой статье используется обычный регистр предложений для этих терминов (например, scrum master , daily scrum ) - если только они не являются признанными знаками (такими как Certified Scrum Master и Professional Scrum Master ).

Ключевые идеи

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

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

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

История

Хиротака Такеучи и Икудзиро Нонака ввели термин « схватка» в контексте разработки продукта в своей статье в Harvard Business Review 1986 года «Игра в разработку новых продуктов». Такеучи и Нонака позже утверждали в «Компании создания знаний», что это форма «создания организационных знаний, [...] особенно хороших для непрерывного, постепенного и спирального внедрения инноваций».

Авторы описали новый подход к разработке коммерческих продуктов, который повысит скорость и гибкость, на основе тематических исследований производственных компаний в автомобильной, копировальной и полиграфической отраслях . Они назвали это целостным подходом, или подходом регби , поскольку весь процесс выполняется одной кросс-функциональной командой на нескольких перекрывающихся этапах, в которых команда «пытается пройти расстояние как единое целое, передавая мяч вперед и назад». (В регби , схватка используется для перезапуска игры, как форварды каждой команды блокировки с опущенными головами и пытаются завладеть мячом.)

Фреймворк Scrum был основан на исследовании Швабера с Бабатунде Огуннайке из исследовательской станции DuPont и Университета Делавэра. Огуннаике сообщил, что попытки разработать сложные продукты, такие как программное обеспечение, не основанные на эмпиризме, обречены на более высокие риски и вероятность неудач по мере изменения исходных условий и предположений. Эмпиризм, использующий частые проверки и адаптацию, гибкость и прозрачность, является наиболее подходящим подходом.

В начале 1990-х Кен Швабер использовал то, что впоследствии стало Scrum в его компании Advanced Development Methods; в то время как Джефф Сазерленд , Джон Скумниоталес и Джефф Маккенна разработали аналогичный подход в Easel Corporation, используя одно слово scrum.

Сазерленд и Швабер работали вместе, чтобы объединить свои идеи в единую структуру - Scrum. Они тестировали Scrum и постоянно улучшали его, что привело к их статье 1995 года, вкладам в Agile Manifesto в 2001 году и всемирному распространению и использованию Scrum с 2002 года.

В 1995 году Сазерленд и Швабер совместно представили доклад, описывающий структуру Scrum, на семинаре по проектированию и реализации бизнес-объектов, который проходил в рамках Object-Oriented Programming, Systems, Languages ​​& Applications '95 (OOPSLA '95) в Остине, штат Техас. В последующие годы Швабер и Сазерленд вместе объединили этот материал - со своим опытом и развивающейся передовой практикой - для разработки того, что стало известно как Scrum.

В 2001 году Швабер вместе с Майком Бидлом описал метод в книге « Гибкая разработка программного обеспечения с помощью Scrum» . Подход Scrum к планированию и управлению разработкой продукта предполагает доведение полномочий по принятию решений до уровня эксплуатационных свойств и определенности.

В 2002 году Швабер вместе с другими основал Scrum Alliance и организовал серию аккредитации Certified Scrum . Швабер покинул Scrum Alliance в конце 2009 года и основал Scrum.org, который курирует параллельную серию аккредитации Professional Scrum .

С 2009 года Швабер и Сазерленд опубликовали и обновили общедоступный документ под названием The Scrum Guide . Он пересматривался 6 раз, текущая версия - ноябрь 2020 года.

Скрам команда

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

Владелец продукта

Владелец продукта, представляющий заинтересованные стороны продукта и голос клиента (или может представлять пожелания комитета), несет ответственность за достижение хороших бизнес-результатов. Следовательно, владелец продукта несет ответственность за отставание продукта и за максимизацию ценности, которую предоставляет команда. Владелец продукта определяет продукт с точки зрения ориентированных на клиента результатов (обычно - но не ограничиваясь - пользовательскими историями ), добавляет их в список невыполненных работ по продукту и расставляет приоритеты на основе важности и зависимостей. В scrum-команде должен быть только один product owner (хотя product owner может поддерживать более одной команды), и настоятельно не рекомендуется совмещать эту роль с ролью scrum master. Владелец продукта должен сосредоточиться на деловой стороне разработки продукта и тратить большую часть времени на поддержание связи с заинтересованными сторонами и командой. Владелец продукта не диктует, как команда достигает технического решения, но стремится к консенсусу среди членов команды. Эта роль имеет решающее значение и требует глубокого понимания обеих сторон: бизнеса и инженеров (разработчиков) в scrum-команде. Следовательно, хороший владелец продукта должен быть в состоянии сообщить, что нужно бизнесу, спросить, зачем им это нужно (потому что могут быть более эффективные способы достижения этого), и передать сообщение всем заинтересованным сторонам, включая разработчиков, используя технический язык, по мере необходимости. Владелец продукта использует эмпирические инструменты Scrum для управления очень сложной работой, контролируя риски и достигая ценности.

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

В качестве лица команды для заинтересованных сторон, владелец продукта выполняет следующие задачи по коммуникации с заинтересованными сторонами:

  • Определите и объявите выпуски.
  • Сообщите о доставке и статусе продукта.
  • Делитесь прогрессом во время управленческих встреч.
  • Делитесь важными RIDA (рисками, препятствиями, зависимостями и предположениями) с заинтересованными сторонами.
  • Обсудите приоритеты, объем, финансирование и график.
  • Убедитесь, что список невыполненных заказов виден, прозрачен и понятен.

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

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

Разработчики

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

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

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

Скрам мастер

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

Основные обязанности мастера схватки включают (но не ограничиваются ими):

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

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

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

Рабочий процесс

Спринт

Фреймворк Scrum
Не путать с Хакатоном § Кодовые спринты .
Процесс Scrum

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

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

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

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

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

В начале спринта команда Scrum проводит мероприятие по планированию спринта, чтобы:

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

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

Ежедневная схватка

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

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

Все разработчики приходят подготовленными. Ежедневная схватка:

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

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

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

Обзор спринта

По окончании спринта команда:

  • представляет выполненную работу заинтересованным сторонам (она же демо )
  • сотрудничает с заинтересованными сторонами по таким темам, как:
    • приглашение отзывов о готовом приращении продукта
    • обсуждение влияния незавершенной работы (запланированной или нет)
    • получение предложений по предстоящей работе (руководство о том, над чем работать дальше)

Владельцы продукта должны рассматривать это событие как ценную возможность изучить и уточнить отставание по продукту с заинтересованными сторонами.

Рекомендации для обзоров спринтов:

  • Незавершенная работа не должна демонстрироваться; несмотря на то, что заинтересованным сторонам следует представить информацию об увеличении количества продуктов, которые они будут получать, но при необходимости они могут также запросить просмотр выполняемой работы. Однако команда должна быть готова только показать, что было сделано.
  • Рекомендуемая продолжительность двухнедельного спринта - два часа (пропорционально другим продолжительности спринта).

Ретроспектива спринта

На ретроспективе спринта команда:

Рекомендации по ретроспективе спринта:

  • В ретроспективе спринта следует рассмотреть три предлагаемых области:
    • Что прошло хорошо во время спринта?
    • Что пошло не так?
    • Что мы могли бы сделать по-другому в следующем спринте?
  • Рекомендуемая продолжительность двухнедельного спринта составляет полтора часа (пропорционально продолжительности другого спринта).

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

Уточнение бэклога

Хотя изначально это не было основной практикой Scrum, уточнение бэклога (ранее называвшееся чисткой ) было добавлено в Scrum Guide и принято как способ управления качеством элементов бэклога продукта, поступающих в спринт. Это постоянный процесс проверки и исправления / обновления / переупорядочения элементов невыполненной документации по продукту в свете новой информации.

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

  • Более крупные предметы можно разбить на несколько более мелких.
  • Критерии приемки могут быть уточнены.
  • Зависимости могут быть выявлены и исследованы
  • Элемент может потребовать дальнейшего обнаружения и анализа.
  • Возможно, изменились приоритеты; ожидаемая доходность теперь будет отличаться

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

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

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

Отмена спринта

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

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

Артефакты

Резерв продукта

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

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

Бэклог продукта содержит оценку ценности бизнеса владельцем продукта и может включать оценку усилий или сложности команды, часто, но не всегда, выраженную в баллах истории с использованием округленной шкалы Фибоначчи . Эти оценки помогают product owner-у оценить сроки и могут повлиять на упорядочивание элементов невыполненных работ по продукту; например, для двух функций с одинаковой бизнес-ценностью владелец продукта может запланировать более раннее выполнение работы с меньшими усилиями по разработке (потому что рентабельность инвестиций выше) или с более высокими усилиями разработки (потому что это более сложно или рискованно. , и они хотят избавиться от этого риска раньше).

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

Сюжетные точки определяют усилия в рамках временного интервала, поэтому они не меняются со временем. Например, за один час человек может ходить, бегать или карабкаться вверх, но затрачиваемые усилия явно отличаются. Прогрессирование разрыва между членами последовательности Фибоначчи побуждает команду давать тщательно продуманные оценки. Оценка 1, 2 или 3 подразумевает аналогичные усилия (1 - тривиальный), но если команда оценивает 8 или 13 (или выше), влияние как на выполнение, так и на бюджет может быть значительным. Ценность использования Story Points заключается в том, что команда может повторно использовать их, сравнивая аналогичную работу из предыдущих спринтов, но следует понимать, что оценки относятся к этой команде. Например, оценка 5 для одной команды может быть 2 для другой, состоящей из более опытных разработчиков с более высокими возможностями.

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

Бэклог продукта:

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

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

Управление

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

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

Элементы с высоким приоритетом (в верхней части невыполненной работы) должны быть разбиты на более подробную информацию, над которой разработчики могут работать. Чем дальше по списку, тем менее подробными будут элементы. Как говорят Швабер и Бидл: «Чем ниже приоритет, тем меньше деталей, пока вы не сможете различить элемент невыполненной работы».

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

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

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

Работа над бэклогом спринта никогда не передается (и не передается) разработчикам; члены команды тянут работу по мере необходимости в соответствии с приоритетом невыполненных работ, а также своими собственными навыками и возможностями. Это способствует самоорганизации разработчиков.

Бэклог спринта является собственностью разработчиков, и все включенные оценки предоставлены разработчиками. Хотя это и не входит в Scrum, некоторые команды используют сопроводительную доску для визуализации состояния работы в текущем спринте: ToDo, Doing, Done.

Инкремент

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

Расширения

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

График выгорания

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

Диаграмма выгорания, часто используемая в Scrum (но не часть Scrum), представляет собой общедоступную диаграмму, показывающую оставшуюся работу. Обновляется каждый день, он предоставляет быстрые визуализации для справки. Горизонтальная ось диаграммы выгорания показывает оставшиеся дни, а вертикальная ось показывает объем работы, оставшейся за каждый день.

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

Его не следует путать с диаграммой освоенной стоимости .

График выгорания выпуска

Примерная диаграмма выгорания для релиза, показывающая объем выполненного каждого спринта (MVP = минимально жизнеспособный продукт)

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

Диаграмма выгорания выпуска позволяет легко увидеть, сколько работы было выполнено, сколько работы было добавлено или удалено (если горизонтальная линия осциллографа перемещается) и сколько работы осталось сделать.

Определение слова ready (DoR)

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

Определение «готово» (DoD)

В экзит-критерии для определения , является ли работа по пункту Спринт неудовлетворенного завершена, например: Министерство Обороны требует , чтобы все тесты регрессии быть успешным. Определение «готово» может варьироваться от одной команды к другой, но должно быть единообразным внутри одной команды.

Скорость

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

Этот показатель вызвал споры в сообществе Scrum:

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

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

Шип

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

Трассирующая пуля

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

Ограничения

Достичь преимуществ Scrum может быть труднее, если:

  • Команды, члены которых географически рассредоточены или работают неполный рабочий день : в Scrum разработчики должны поддерживать тесное и постоянное взаимодействие, в идеале большую часть времени работая вместе в одном пространстве. Хотя недавние усовершенствования в технологии снизили влияние этих препятствий (например, возможность сотрудничать на цифровой доске), манифест Agile утверждает, что лучшее общение - лицом к лицу.
  • Команды, члены которых обладают очень специализированными навыками : в Scrum разработчики должны иметь Т-образные навыки , позволяющие им работать над задачами, выходящими за рамки их специализации. Этому может способствовать хорошее руководство Scrum. Хотя члены команды с очень специфическими навыками могут и действительно вносят свой вклад, их следует поощрять к тому, чтобы они больше узнавали о других дисциплинах и сотрудничали с ними.
  • Продукты с множеством внешних зависимостей : в Scrum разделение разработки продукта на короткие спринты требует тщательного планирования; внешние зависимости, такие как приемочное тестирование пользователей или координация с другими командами, могут привести к задержкам и сбоям отдельных спринтов.
  • Продукты, которые являются зрелыми или унаследованными, или с регулируемым контролем качества : в Scrum, приращения продукта должны быть полностью разработаны и протестированы в одном спринте; продукты, которые требуют большого количества регрессионных испытаний или испытаний на безопасность (например, медицинские устройства или средства управления транспортными средствами) для каждого выпуска, менее подходят для коротких спринтов, чем для более длительных водопадных выпусков.

Доступные инструменты

Основная статья: Сравнение программного обеспечения Scrum

Как и другие гибкие подходы, эффективное внедрение Scrum может поддерживаться (но не зависеть от него) с помощью широкого набора доступных инструментов.

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

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

Ценности Scrum

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

Эти три столпа требуют доверия и открытости в команде, которые обеспечивают следующие пять ценностей Scrum:

  1. Приверженность: члены команды индивидуально привержены достижению целей своей команды на каждом спринте .
  2. Смелость: члены команды знают, что у них хватит смелости преодолевать конфликты и проблемы вместе, чтобы они могли поступать правильно.
  3. Фокус: члены команды сосредотачиваются исключительно на целях своей команды и отставании в спринте; не должно выполняться никакой другой работы, кроме их невыполненной работы.
  4. Открытость: члены команды и их заинтересованные стороны соглашаются быть прозрачными в своей работе и любых проблемах, с которыми они сталкиваются.
  5. Уважение: члены команды уважают друг друга за то, что они технически способны и работают с добрыми намерениями.

Адаптации

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

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

Scrumban

Основная статья: Scrumban

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

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

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

Схватка схваток

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

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

Это должно быть похоже на ежедневную схватку, когда каждый представитель отвечает на следующие четыре вопроса:

  • Какие риски, препятствия, зависимости или предположения решила ваша команда с момента нашей последней встречи?
  • Какие риски, препятствия, зависимости или предположения решит ваша команда, прежде чем мы снова встретимся?
  • Есть ли какие-либо новые риски, препятствия, зависимости или предположения, которые замедляют вашу команду или мешают ей?
  • Вы собираетесь ввести новый риск, препятствие, зависимость или предположение, которое будет мешать другой команде?

Как прокомментировал Джефф Сазерленд :

Поскольку я изначально определил Scrum of Scrums (Кен Швабер работал со мной в IDX), я могу определенно сказать, что Scrum of Scrums не является «мета Scrum». Scrum of Scrums в том виде, в каком я его использовал, отвечает за доставку рабочего программного обеспечения всех команд к Определению Готово в конце спринта или за выпуски во время спринта. PatientKeeper доставлялся в производство четыре раза за спринт. Ancestry.com доставляет в производство 220 раз за двухнедельный спринт. Hubspot доставляет живое программное обеспечение 100–300 раз в день. Scrum of Scrums Master несет ответственность за выполнение этой работы. Итак, Scrum of Scrums - это оперативный механизм доставки.

Масштабный Scrum

Крупномасштабный Scrum (LeSS) - это среда разработки продукта, которая расширяет Scrum с помощью правил масштабирования и рекомендаций без потери исходных целей Scrum.

Структура состоит из двух уровней: первый уровень LeSS рассчитан на восемь команд; второй уровень, известный как «LeSS Huge», вводит дополнительные элементы масштабирования для разработки с участием до сотен разработчиков. «Масштабирование Scrum начинается с понимания и способности принять стандартный реальный скрам для одной команды. Масштабный Scrum требует изучения цели элементов Scrum для одной команды и выяснения того, как достичь той же цели, оставаясь в рамках ограничений стандартного Scrum. правила."

Бас Водде и Крейг Ларман разработали структуру LeSS на основе своего опыта работы с крупномасштабной разработкой продуктов, особенно в телекоммуникационной и финансовой отраслях. Он развился, взяв Scrum и попробовав множество различных экспериментов, чтобы выяснить, что работает. В 2013 году эксперименты были закреплены в рамках правил LeSS. Цель LeSS - «очистить от накипи» сложность организации, избавиться от ненужных сложных организационных решений и решить их более простыми способами. Меньше ролей, меньше управления, меньше организационных структур.

Критика

Скрам неоднократно подвергался критике, в основном из-за того, что те, кто плохо применяли концепции, но ожидали тех же результатов, или неправильно понимали культурные изменения, которых требует Скрам:

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

Распространенные дисфункциональные подходы к Scrum теперь признаны антипаттернами, включая Dark Scrum и Scream.

Смотрите также

использованная литература

дальнейшее чтение

внешние ссылки