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

Эта статья поднимает множество проблем. Пожалуйста помоги Улучши это или обсудите эти вопросы на страница обсуждения. (Узнайте, как и когда удалить эти сообщения-шаблоны) Эта статья содержит формулировку, которая субъективно продвигает тему без передачи реальной информации. Удалите или замените такую ​​формулировку и вместо того, чтобы заявлять о важности темы, используйте факты и атрибуцию, чтобы продемонстрировать эту важность. (Январь 2020) (Узнайте, как и когда удалить этот шаблон сообщения) В ведущий раздел этой статьи может потребоваться переписать. Использовать руководство по макету свинца чтобы раздел соответствовал нормам Википедии и содержал все важные детали. (Май 2020 г.) (Узнайте, как и когда удалить этот шаблон сообщения) Эта статья может быть написано из точка зрения фаната, а не нейтральная точка зрения. Пожалуйста приберись соответствовать высший стандарт качества, и сделать его нейтральным по тону. (Май 2020 г.) (Узнайте, как и когда удалить этот шаблон сообщения) Эта статья нужны дополнительные цитаты для проверка. Пожалуйста помоги улучшить эту статью к добавление цитат в надежные источники. Материал, не полученный от источника, может быть оспорен и удален. Найдите источники: Разработка программного обеспечения "Scrum"  – Новости  · газеты  · книги  · ученый  · JSTOR (Май 2020 г.) (Узнайте, как и когда удалить этот шаблон сообщения) Некоторые из этой статьи перечисленные источники может и не быть надежный. Пожалуйста, помогите этой статье поиском более надежных источников. Ненадежные цитаты могут быть оспорены или удалены. (Май 2020 г.) (Узнайте, как и когда удалить этот шаблон сообщения) (Узнайте, как и когда удалить этот шаблон сообщения)

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

Имя

Срок разработки программного обеспечения схватка впервые был использован в статье 1986 г., озаглавленной «Игра в разработку новых продуктов». Термин заимствован из регби, где схватка это формация игроков. Период, термин схватка был выбран авторами статьи, потому что он подчеркивает командную работу.^[3]

Scrum иногда пишется заглавными буквами, так как SCRUM.^[4] Хотя само слово не является акроним, его стиль с большой буквы, вероятно, происходит из ранней статьи Кена Швабера.^[5] это заглавные буквы SCRUM в его названии.^[6][7]

В то время как товарный знак на срок Scrum само по себе было разрешено истекать, он считается принадлежащим более широкому сообществу, а не отдельному лицу,^[8] так что ведущий капитал для Scrum сохраняется в этой статье.

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

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

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

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

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

История

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

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

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

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

Кен и Джефф работали вместе, чтобы объединить свои идеи в единую структуру - Scrum. Они тестировали Scrum и постоянно улучшали его, в результате чего в 1995 году они написали свой вклад в Agile Manifesto.^[16] в 2001 году, а также во всем мире распространение и использование Scrum с 2002 года.

В 1995 году Сазерленд и Швабер совместно представили документ с описанием структуры Scrum на семинаре по проектированию и внедрению бизнес-объектов, который проходил в рамках Объектно-ориентированное программирование, системы, языки и приложения '95 (OOPSLA '95) в Остине, штат Техас.^[17] В последующие годы Швабер и Сазерленд вместе объединили этот материал - со своим опытом и развивающейся хорошей практикой - для разработки того, что стало известно как Scrum.^[18]

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

В 2002 году Швабер с другими основал Scrum Alliance^[20] и настроить Сертифицированный Scrum серия аккредитации. Швабер покинул Scrum Alliance в конце 2009 года и основал Scrum.org.^[21] который наблюдает за параллельным Профессиональный Скрам серия аккредитации.^[22]

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

Роли

Эта секция возможно содержит оригинальные исследования. Пожалуйста Улучши это к проверка заявленные претензии и добавление встроенные цитаты. Заявления, содержащие только оригинальные исследования, следует удалить. (Апрель 2019) (Узнайте, как и когда удалить этот шаблон сообщения)

В структуре Scrum есть три роли.^[23] Они идеально расположены рядом, чтобы обеспечить оптимальное общение между членами команды. Хотя у многих организаций есть другие роли, связанные с определением и доставкой продукта, Scrum определяет только эти три.^[18]

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

Владелец продукта, представляющий заинтересованные стороны и голос заказчика (или может представлять желания комитета^[24]), несет ответственность за достижение хороших бизнес-результатов.^[25] Следовательно, product owner несет ответственность за отставание продукта и за максимизацию ценности, которую предоставляет команда.^[24] Владелец продукта определяет продукт в терминах, ориентированных на клиента (обычно пользовательские истории ), добавляет их в Резерв продукта, и расставляет приоритеты они основаны на важности и зависимостях.^[26] В scrum-команде должен быть только один product owner (хотя product owner может поддерживать более одной команды).^[27] Эту роль не следует совмещать с ролью мастера схватки. Владелец продукта должен сосредоточиться на деловой стороне разработки продукта и тратить большую часть своего времени на взаимодействие с заинтересованными сторонами и командой. Владелец продукта не должен диктовать, как команда достигает технического решения, а скорее стремится к консенсусу среди членов команды.^{[28][29][30][нужен лучший источник ]} Эта роль очень важна и требует глубокого понимания обеих сторон: бизнеса и инженеров (разработчиков) в команде scrum. Поэтому хороший владелец продукта должен уметь сообщить, что нужно бизнесу, спросить, зачем им это нужно (потому что могут быть более эффективные способы достижения этого), и передать сообщение всем заинтересованным сторонам, включая разработчиков, используя технический язык, если это необходимо. Владелец продукта использует эмпирические инструменты Scrum для управления очень сложной работой, контролируя при этом риски и достигая ценности.

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

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

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

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

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

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

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

В то время как члены команды упоминаются как Разработчики^[18], термин относится к любому, кто играет роль в разработке и поддержке системы или продукта, и может включать исследователей, архитекторов, дизайнеров, специалистов по данным, статистиков, аналитиков, инженеров, программистов и тестировщиков, среди прочих.^[23] Однако из-за путаницы, которая может возникнуть, когда некоторые люди не считают, что термин «разработчик» применим к ним, их часто называют просто Члены команды.

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

Скрам мастер

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

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

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

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

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

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

Спринт

Фреймворк Scrum

Процесс Scrum

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

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

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

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

В начале спринта команда scrum проводит мероприятие по планированию спринта.^[39] к:

• Взаимно обсудить и согласовать объем работ, которые предполагается выполнить во время этого спринта.
• Выберите элементы бэклога продукта, которые можно выполнить за один спринт
• Подготовьте бэклог спринта, который включает работу, необходимую для завершения выбранных элементов бэклога продукта.
• Согласен цель спринта, краткое описание того, что они прогнозируют выполнить в конце спринта.
• Максимальная продолжительность планирования спринта составляет восемь часов для четырехнедельного спринта. ^[18]
  • Команда определяет цель спринта на основе приоритетов, установленных владельцем продукта.
  • Затем команда выбирает элементы бэклога продукта, которые, по их мнению, должны быть выполнены в спринте.
  • Наконец, разработчики определяют подробную работу (задачи), необходимую для завершения этих элементов невыполненной работы по продукту; приводит к новому отставанию в спринте
    • По мере проработки детальной работы некоторые элементы невыполненной работы продукта могут быть разделены или возвращены в невыполненную работу продукта, если команда больше не верит, что они могут выполнить требуемую работу за один спринт.

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

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

Каждый день во время спринта команда проводит ежедневную схватку (или вставать ) с конкретными рекомендациями:^[40][6]

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

Любое препятствие (например, камень преткновения, риск, проблема, отложенная зависимость, предположение оказалось необоснованным)^[41] Выявленные в ежедневной схватке должны быть зафиксированы мастером схватки и отображены на доске схватки команды или на доске общих рисков с согласованным лицом, назначенным для работы над решением (за пределами ежедневной схватки). В то время как валюта рабочего статуса - это ответственность всей команды, мастер схватки часто обновляет диаграмму выгорания спринта.^[42] Если команда не видит ценности в этих мероприятиях, ответственность за выяснение причин лежит на мастере схватки.^[43] Это часть ответственности по обучению команды и заинтересованных сторон принципам Scrum.^[36]

Во время ежедневного скрама не должно происходить никаких подробных обсуждений. По окончании встречи отдельные участники могут собраться вместе, чтобы подробно обсудить проблемы; такую ​​встречу иногда называют «сеансом обсуждения» или «афтепати».^[42]

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

В конце спринта команда проводит два мероприятия: обзор спринта и ретроспективу спринта.

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

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

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

• Незавершенная работа не может быть продемонстрирована.
• Рекомендуемая продолжительность двухнедельного спринта - два часа (пропорционально другим продолжительности спринта).^[18]

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

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

• размышляет о прошедшем спринте
• определяет и соглашается постоянное совершенствование процесса действия

Рекомендации по ретроспективе спринта:^{[нужна цитата ]}

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

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

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

Хотя изначально это не было основной практикой Scrum, уточнение бэклога было добавлено в Scrum Guide и принято как способ управления качеством элементов бэклога продукта, поступающих в спринт, с рекомендуемыми инвестициями в размере до 10% от возможностей спринта команды.^[18][44]

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

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

При необходимости product owner может отменить спринт.^[18] Владелец продукта может сделать это при участии команды, мастера схватки или руководства. Например, руководство может пожелать, чтобы владелец продукта отменил спринт, если внешние обстоятельства сводят на нет ценность цели спринта. Если спринт завершается ненормально, следующим шагом является планирование нового спринта, при котором рассматривается причина прекращения.

Артефакты

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

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

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

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

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

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

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

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

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

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

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

Управление

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

Владелец продукта расставляет приоритеты по элементам бэклога продукта, исходя из того, какие из них необходимы в первую очередь. Затем команда выбирает, какие предметы они могут выполнить в предстоящем спринте. На доске схватки команда перемещает элементы из бэклога продукта в бэклог спринта, который представляет собой список элементов, которые они будут создавать. Концептуально для команды идеально выбирать только то, что, по ее мнению, они могут выполнить, из верхней части списка, но на практике нередко можно увидеть, что команды могут брать из списка элементы с более низким приоритетом вместе с лучшими. выбранные. Обычно это происходит потому, что в спринте остается время, чтобы выполнить больше работы. Пункты в верхней части бэклога, пункты, над которыми нужно работать в первую очередь, должны быть разбиты на истории, которые подходят команде для работы. Чем дальше идет очередь, тем менее изысканными должны быть элементы. Как говорят Швабер и Бидл: «Чем ниже приоритет, тем меньше деталей, пока вы не сможете различить элемент невыполненной работы».^[6]

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

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

Доска задач схватки

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

Элементы невыполненной работы продукта могут быть разбиты разработчиками на задачи.^[49] Задачи в бэклоге спринта никогда не назначаются (и не передаются) членам команды кем-то другим; члены команды скорее подписываются (или вытягивают) задачи по мере необходимости в соответствии с приоритетом невыполненных работ, а также своими собственными навыками и возможностями. Это способствует самоорганизации разработчиков.

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

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

Приращение

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

Расширения

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

График сгорания спринта

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

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

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

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

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

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

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

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

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

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

Определение слова done (DoD)

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

Скорость

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

Шип

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

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

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

Ограничения

Достичь преимуществ Scrum может быть труднее, когда:^[54][55]

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

Инструменты для реализации

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

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

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

Ценности Scrum

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

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

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

Адаптации

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

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

Scrumban

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

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

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

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

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

Вместо того, чтобы просто следить за ходом выполнения, схватка схваток должна быть сосредоточена на том, как команды коллективно работают над устранением, смягчением или принятием любых выявленных рисков, препятствий, зависимостей и предположений (RIDA). Scrum of scrums отслеживает эти RIDA с помощью собственного бэклога, такого как доска рисков (иногда известная как Доска ROAM после инициалов разрешенных, принадлежащих, принятых и смягченных),^[64] что обычно приводит к большей координации и сотрудничеству между командами.^[63]

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

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

В качестве Джефф Сазерленд прокомментировал,^[63]

Поскольку я изначально определил 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 для одной команды и выяснения, как достичь той же цели, оставаясь в рамках ограничений стандартного Scrum правила."^[66]

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

Критика

Сообщается, что церемониальные встречи Scrum причиняют боль продуктивность и трата времени, которое можно было бы лучше потратить на реальные продуктивные задачи.^[69][70]

Практики Scrum, если они не реализованы правильно в духе Agile манифест, имеют тенденцию становиться формой микроменеджмент.^[71]

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

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

• Гибкое тестирование
• Дисциплинированная гибкая доставка
• Высокопроизводительные команды
• Бережливая разработка программного обеспечения
• Управление проектом
• Скрамедж
• Единый процесс

Рекомендации

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

• Ваканити, Даниэль (февраль 2018 г.). «Руководство по канбану для Scrum-команд» (PDF). scrum.org. Получено 12 марта, 2018.
• Сазерленд, Джефф; Швабер, Кен (2013). «Руководства по Scrum». ScrumGuides.org. Получено 26 июля, 2017.
• Верхейен, Гюнтер (2013). Скрам - Карманный гид (Умный спутник в путешествиях) ISBN  978-9087537203.
• Мюнх, Юрген; Армбраст, Уве; Сото, Мартин; Ковальчик, Мартин (2012). Определение и управление программным процессом. ISBN  978-3-642-24291-5.
• Демер, Пит; Бенефилд, Габриель; Ларман, Крейг; Водде, Бас (2009). «Скрам Праймер». Получено 1 июня, 2009.
• Janoff, N.S .; Восход, Л. (2000). «Процесс разработки программного обеспечения Scrum для небольших команд» (PDF). Получено 26 февраля, 2015.

внешняя ссылка

• Библиотека Scrum Agile Alliance
• Описание процесса Scrum Проектом Eclipse Process Framework (EPF)