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

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

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

Имя [ редактировать ]

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

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

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

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

Ключевые идеи [ править ]

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

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

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

История [ править ]

Хиротака Такеучи и Икудзиро Нонака ввели термин « схватка» в контексте разработки продукта в своей статье в Harvard Business Review 1986 года «Игра в разработку новых продуктов». ^[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, на семинаре по проектированию и реализации бизнес-объектов, который проходил в рамках Object-Oriented Programming, Systems, Languages ​​& Applications '95 (OOPSLA '95) в Остине, штат Техас. ^[17] В течение следующих лет Швабер и Сазерленд вместе объединили этот материал - со своим опытом и развивающейся передовой практикой - для разработки того, что стало известно как Scrum. ^[18]

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

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

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

Команда Scrum [ править ]

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

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

Владелец продукта [ править ]

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

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

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

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

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

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

Разработчики [ править ]

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

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

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

Скрам-мастер [ править ]

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

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

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

• Содействие командным мероприятиям для обеспечения регулярного прогресса

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

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

Рабочий процесс [ править ]

Спринт [ править ]

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

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

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

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

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

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

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

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

Ежедневная схватка [ править ]

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

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

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

• может быть проведен Скрам-мастером
• может выявить препятствия на пути прогресса (например, камень преткновения, риск, проблема, отложенная зависимость, предположение, которое оказалось необоснованным) ^[40]
• не содержит обсуждений
• НЕ является «отчетом о состоянии» или средством обновления диаграмм прогресса

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

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

Обзор спринта [ править ]

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

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

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

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

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

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

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

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

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

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

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

Уточнение бэклога [ править ]

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

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

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

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

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

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

Отмена спринта [ править ]

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

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

Артефакты [ править ]

Журнал отставания по продукту [ править ]

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

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

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

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

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

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

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

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

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

Управление [ править ]

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

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

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

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

Бэклог спринта [ править ]

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

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

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

Увеличение [ править ]

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

Расширения [ править ]

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

Диаграмма выгорания [ править ]

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

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

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

График выгорания выпуска [ править ]

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

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

Определение готового (DoR) [ править ]

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

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

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

Скорость [ править ]

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

Спайк [ править ]

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

Трассирующая пуля [ править ]

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

Ограничения [ править ]

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

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

Инструменты для реализации [ править ]

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

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

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

Ценности Scrum [ править ]

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

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

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

Адаптации [ править ]

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

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

Scrumban [ править ]

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

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

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

Схватка схваток [ править ]

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

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

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

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

Как прокомментировал Джефф Сазерленд , ^[60]

Поскольку я изначально определил 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. правила." ^[63]

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

Критика [ править ]

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

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

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

См. Также [ править ]

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

Ссылки [ править ]

Дальнейшее чтение [ править ]

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

Внешние ссылки [ править ]

Викискладе есть медиафайлы, связанные с Скрамом (разработка) .

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