Войти
Scrum - это гибкий фреймворк для разработки, поставка и поддержка сложных продуктов с первичным упором на с помощью программного обеспечения, хотя она использовалась в других областях, включая исследования, продажи, маркетинг и передовые технологии. Он предназначен для команд из десяти или менее, которые используются в рамках ограниченных по времени итераций, называемых спринтами, продолжительностью не более одного месяца, а чаще всего двух недель. Скрам-команда отслеживает прогресс на ежедневных 15-минутных встречах, которые называются ежедневными схватками. В конце спринта команда проводит обзор спринта, чтобы обеспечить проделанную работу, и ретроспективу спринта для постоянного улучшения.
Термин «схватка» при разработке программного обеспечения впервые был использован в 1986 году в статье под названием «Разработка нового нового продукта. Оптимизация игры ». Термин заимствован из регби, где схватка - это построение игроков. Термин «схватка» выбран авторами статьи, потому что он подчеркивает командную работу.
Скрам иногда пишется заглавными буквами, например, SCRUM. Хотя само слово не является аббревиатурой, его стиль с заглавной буквой, вероятно, заимствован из ранней статьи Кена Швабера, в названии которой использовалась заглавная буква SCRUM.
Хотя товарный знак на Самому термину Scrum было позволено утратить силу, он считается принадлежащим более широкому сообществу, а не отдельному человеку, поэтому в этой статье остается основной капитал Scrum.
Многие термины, используемые в Scrum, обычно пишутся с заглавных букв (например, Scrum Master, Daily Scrum). Чтобы сохранить энциклопедический тон, в этой статье используется обычный регистр предложений для этих терминов (например, scrum master, daily scrum), если они не признаны признанными знаками (например, Certified Scrum Master).
Scrum - это легкая, итеративная и инкрементальная структура для управления сложной работой. Эта структура ставит под сомнение допущения традиционного последовательного подхода к разработке продукта и позволяет командаморганизовываться, использовать физическое совместное размещение или тесное онлайн-сотрудничество всех членов команды, а также ежедневные личные встречи. общение лицом к лицу между членами команды и участвующими дисциплинами.
Ключевым принципом Scrum является двойное признание того, что клиенты изменяют свое мнение о том, что они хотят или в чем они (часто называемые изменчивостью требований), и что возникнутнутые непредсказуемые проблемы, для которых прогнозирующий или плановый подход не подходит. подходит.
Таким образом, Scrum может использовать основанный на фактах эмпирический подход - признавая, что проблема не полностью осознана или определена заранее, и вместо этого сосредотачиваясь на том, как максимизировать способность команды быстро выполнять, чтобы реагировать на развивающие требования и адаптироваться к развивающейся технологии и изменениям рыночных условий.
Хиротака Такеучи и Икудзиро Нонака ввели термин «схватка» в контексте разработки продукта в своем обзоре Harvard Business Review за 1986 год год статья «Новая игра в игру новых продуктов». Создание организационных знаний, [...] особенно хороших для непрерывного, безопасного и спирального внедрения инноваций ».
Авторы описали новый подход к разработке коммерческих продуктов, который повысил скорость и гибкость на основе тематических исследований производственных компаний в автомобильной, копировальной и полиграфической отраслях . Они назвали это целостным или регби подходом, как весь процесс выполняется одной межфункциональной командой на нескольких перекрывающихся этапах, на нескольких перекрывающихся этапах команда «пытается пройти дистанцию как единое целое., передавая мяч вперед и назад ». (В футболе регби для возобновления игры используется схватка, так как нападающие команды блокируются головой и пытаются овладеть мячом.)
Структура Scrum была основана на исследовании, проведенном Швабером совместно с Тунде Бабатунде из Исследовательской станции DuPont и Университета Делавэра. Тунде сообщил, что сложные сложные продукты, такие как программное обеспечение, не основанные на эмпиризме, обречены на более высокие риски и вероятность неудач по мере изменения начальных условий и предположений. Эмпиризм, использующий частые проверки и адаптацию, гибкость и прозрачность - наиболее подходящий подход.
В начале 1990-х Кен Швабер использовал то, что усилило Scrum в его компании Advanced Development Methods; в то время как Джефф Сазерленд, Джон Скумниоталес и Джефф МакКенна разработали аналогичный подход в Easel Corporation, используя одно слово scrum.
Кен и Джефф работали вместе, чтобы объединить свои идеи в единое целое. фреймворк, Scrum. Они тестировали Scrum и постоянно улучшали его, что привело к их статье 1995 года, вкладу в Agile Manifesto в 2001 году и повсеместному распространению и использованию Scrum с 2002 года.
В 1995 году Сазерленд и Швабер совместно представили статью с помощью структуры Scrum на семинаре по проектированию и внедрению бизнес-объектов, который проходил в рамках Объектно-ориентированное программирование, системы, языки и приложения '95 (OOPSLA '95) в Остине, штат Техас. Следующие годы Швабер и Сазерленд вместе объединили этот материал - со своим опытом и развивающейся хорошей практикой - для разработки того, что стало известно как Scrum.
В 2001 году Швабер работал с Майком Бидлом для описания метода в книге «Гибкая разработка программного обеспечения с использованием Scrum». Подход Scrum к планированию и управлению разработкой продукта включает доведение полномочий по принятию решений до уровня эксплуатационных свойств и определенности.
В 2002 году Швабер вместе с другими основал и установил аккредитацию Certified Scrum серии. Швабер покинул Scrum Alliance в конце 2009 года и основал Scrum.org, который курирует параллельную серию аккредитации Professional Scrum.
С 2009 года Швабер и Сазерленд опубликовали и обновили общедоступный документ под названием The Scrum Guide. Он пересматривался 5 раз, текущая версия - ноябрь 2017 года.
В структуре Scrum есть три роли. Они идеально расположены рядом, чтобы обеспечить оптимальное общение между членами команды. Скрам определяет только эти три роли, как у многих организаций есть другие роли.
Владелец продукта, представляющий лицом и голос клиента (или может представлять пожелания комитета) обеспечивает достижение хороших результатов в бизнесе. Следовательно, владелец продукта несет ответственность за продукт и за максимизацию ценности, которую использует команда. Владелец продукта определяет продукт в терминах, ориентированных на клиента (обычно пользовательских историй ), их в Журнал невыполненных работ и расставляет приоритеты на основе важности и зависимостей.. В команде по схватке должен быть только один владелец продукта (хотя владелец продукта может поддерживать более одной команды). Эта роль не должна сочетаться с ролью мастера схватки. Владелец компании должен использовать большую часть разработки продукта. Владелец продукта должен диктовать, как команда использует техническое решение, а скорее стремится к консенсусу среди членов команды. Эта очень важна и требует глубокого понимания роли сторон: бизнеса и инженеров (разработчиков) в команде scrum. Следовательно, хороший владелец продукта должен уметь сообщать, что нужно бизнесу, спрашивать, зачем им это нужно (потому что могут быть более эффективными способами этого достижения), и передать сообщение всем заинтересованным сторонам, включая команду разработчиков, используя технический язык, по мере необходимости.. Владелец продукта использует эмпирические инструменты Scrum для управления очень сложной работой, одновременно контролируя риски и достигая ценности.
Связь - основные обязанности владельца продукта. Способность обозначать приоритеты и сопереживать команды и заинтересованным сторонам жизненно важна для того, чтобы направлять продукт в правильном направлении. Роль владельца продукта устраняет коммуникационный разрыв между командой и ее заинтересованными сторонами, выступая в качестве представителя группы сторонних.
Как лицо команды для руководства сторон., ниже приведены некоторые из задач по обмену информацией между владельцем продукта и заинтересованными сторонами:
Сочувствие - ключевой атрибут, которым должен обладать владелец продукта - способность поставить себя на место другого. Владелец продукта общается разными заинтересованными сторонами, у которых есть разный опыт, должности и цели. Владелец продукта уметь видеть с этих разных точек зрения. Чтобы быть эффективным, владельцем продукта разумно уровень детализации, который требуется аудитории. Команды разработчиков нужны подробные отчеты и спецификации, чтобы они могли создать, соответствующие условия работы. Предоставление большего количества информации, чем может привести к потере через Сторону и потере времени. Прямые средства коммуникации являются наиболее предпочтительными для опытных владельцев Agile-продуктов.
Способность владельца продукта к эффективному общению также включает в себя услуги по учету владения техниками, которые могут использовать друг друга, согласовывать приоритеты между интересами сторонних программ, взаимодействовать с программным обеспечением для эффективного выполнения требований.
Команда разработчиков включает от трех до девяти человек, необходимые для создания приращений ценной продукции в каждом спринте.
Пока члены команды упоминаются в некоторой литературе относится к любому, кто играет роль в разработке и поддержке системы или продукта, исследователям, проектировщикам, специалистам по данным, статистиков, аналитиков, инженеров, программистов и других тестировщиков, в том числе другие. Некоторые из них считают, что термин «разработчик» применим к ним.
Команда самоорганизуется. Хотя работа не должна поступать в команду, кроме как через владельца продукта, и ожидается, что мастер схватки защитит команду от чрезмерного отвлечения внимания, команда все же следует использовать к прямому взаимодействию с клиентами и / или заинтересованными сторонами, чтобы получить максимальное понимание и оперативность. обратной связи.
Скрам помогает Скрам-мастеру, который отвечает за устранение препятствий, мешающих команде обеспечить цели и результаты продукта. Скрам-мастер не является традиционным руководителем команды или менеджером проекта, но действует как буфер между командой и любыми отвлекающими факторами. Мастер схватки обеспечивает соблюдение рамок схватки. Скрам-мастер помогает мышам, что следует согласовать процессам в структуре Scrum, часто используются ключевые сессии. Роль также упоминается как фасилитатор команды или лидер-слуга, чтобы усилить эти двойные точки зрения.
Основные обязанности мастера включают (но не ограничиваются ими):
Скрам-мастер помогает людям и организациям принимать эмпири ческие и бережливые мышление, оставляющее после себя надежды на достоверность и способность.
Одним из отличных ролей мастера схватки от менеджера проекта является то, что последний может иметь обязанности по управлению людьми, а мастер схватки - нет. Скрам-мастер обеспечивает ограниченное руководство, поскольку команда будет наделена полномочиями и будет самоорганизованной. Скрам формально не признает роль менеджера проекта, поскольку тенденции командования и управления могут вызвать трудности.
Фреймворк Скрама 
Процесс Scrum Спринт (также известный как итерация или временный интервал) - это основная единица разработки в Scrum. Спринт - это ограниченное по времени усилие; то есть продолжительность согласовывается и фиксируется заранее для каждого спринта и обычно составляет от одной недели до одного месяца, причем две недели наиболее частыми.
Каждый спринт начинается с мероприятия по планированию спринта, устанавливает элементы спринт цель и необходимые бэклога продукта. Команда принимает то, что, по их мнению, готово, и переводит это в бэклог спринта с требуемых работ и предполагаемым прогнозом достижения цели спринта. Каждый спринт заканчивается обзором спринта и ретроспективой спринта, чтобы показать заинтересованным сторонам и выявлять уроки и улучшения для следующих спринтов.
Scrum подчеркивает ценные, полезные результаты в конце спринта, которые действительно выполнены. В случае программного обеспечения это вероятно, означает, что программное обеспечение было полностью интегрировано.
В начале спринта команда Scrum проводит мероприятие по планированию спринта, чтобы:
Ежедневный схватка в вычислительной комнате. Это централизованное расположение помогает команде начать работу вовремя. Каждый день во время спринта команда проводит ежедневную схватку (или стендап ) с конкретными инструкциями:
Любое препятствие (например, камень преткновения, риск, проблема, отложенная зависимость, предположение, которое оказалось необоснованным), выявленное в ежедневном схватке, должно быть зафиксировано мастером схватки и отображено в схватке команды или на доске с разделенными рисками, с согласованным лицом, назначенным для работы над решением (за пределами ежедневного sc ром). В то время как валюта рабочего статуса - это ответственность всей команды, мастер схватки часто обновляет диаграмму выгорания спринта. Если команда не видит ценности в этих мероприятиях, ответственность за выяснение причин несет мастер схватки. Это часть ответственности по обучению команды и заинтересованных сторон принципам Scrum.
Во время ежедневного Scrum не должно происходить никаких подробных обсуждений. По окончании встречи отдельные участники могут собраться вместе, чтобы подробно обсудить проблемы; такую встречу иногда называют «сеансом обсуждения» или «вечеринкой».
В конце спринта команда проводит два мероприятия: обзор спринта и ретроспектива спринта.
При обзоре спринта команда:
Рекомендации по обзору спринта:
В ретроспективе спринта команда:
Рекомендации по ретроспективе спринта:
Бэклог уточнение (ранее называвшееся чисткой) - это постоянный процесс проверки элементов бэклога продукта и проверки того, что они должным образом подготовлены и упорядочены таким образом, чтобы сделать их понятными и выполнимыми для команд, когда они входят в спринт через деятельность по планированию спринта. Элементы невыполненной работы продукта могут быть разбиты на несколько более мелких. Критерии приемки могут быть уточнены. Зависимости могут быть выявлены и исследованы.
Хотя изначально это не было основной практикой Scrum, в Scrum Guide было добавлено уточнение бэклога и принято как способ управления качеством элементов бэклога продукта, поступающих в спринт, с рекомендуемыми инвестициями в размере до 10% способность команды к спринту.
Бэклог также может быть технический долг (также известный как проектный долг или долг код). Это концепция разработки программного обеспечения, которая предполагает предполагаемую стоимость дополнительных доработок, вызванных использованием простого сейчас, а не использование лучшего решения, который потребовал бы больше времени.
Владелец продукта может отменить спринт при необходимости. Владелец продукта может сделать это при участии команды, мастера схватки или руководства. Например, руководство может пожелать, чтобы владелец продукта отменил спринт, если внешние обстоятельства сводят на нет ценность цели спринта. Если спринт завершается ненормально, следующий шаг является проведением нового планирования спринта, при котором требуется ограничение.
Журнал невыполненных работ по продукту представляет собой разбивку работ, которые необходимо выполнить, и содержит упорядоченный список требований к продукту, которые команда схватки поддерживает для продукта. Общие форматы включают пользовательские истории и варианты использования. Требования определяют функции, исправления ошибок, нефункциональные требования и т. Д. - все, что необходимо сделать для создания жизнеспособного продукта. Владелец продукта приоритезирует элементы невыполненной работы продукта (PBI) на основе таких соображений, как риск, ценность для бизнеса, размер и необходимая дата.
Бэклог продукта - это то, что будет доставлено, упорядоченное в той системе, в которой оно должно быть доставлено. Он виден всем, но может быть изменен только с согласия владельца продукта, который в конечном итоге несет ответственность за заказ элементов невыполненных работ по продукту для команды выбора разработчиков.
Бэклог содержит оценки бизнеса продукта и оценки по разработке команды разработчиков, которые, но не всегда, указываются в Очки истории с использованием округленных Шкала Фибоначчи. Эти оценки позволяют владельцу продукта оценить сроки и могут повлиять на упорядочение элементов невыполненных работ по продукту; например, если две функции имеют одинаковую ценность для бизнеса, владелец продукта может запланировать более раннюю поставку одним с меньшими усилиями по разработке (поскольку возврат инвестиций выше) или одной с более высокими усилиями по разработке (потому что это более сложно или рискованно, и они хотят избавиться от этого раньше).
Ответственность за невыполнение работ по продукту и за бизнес-ценность каждого элемента невыполненной работы по продукту лежит на владельце продукта. Усилия по доставке каждого элемента оценивает команду разработчиков в сюжетных точках времени. Оценивая сюжетные точки, команда снижает зависимость отдельных разработчиков; это особенно полезно в динамических командах, где разработчики часто поручаются другим проектам после завершения спринта. Например, если пользовательская история оценивается в 5 баллов, она остается 5 независимо от того, сколько разработчиков над ней работают
Очки истории определяют усилия во временном интервале, поэтому не меняются со временем. Например, за один час человек может ходить, бегать или карабкаться вверх, но затрачиваемое усилие явно отличается. Прогрессирование разрыва через камеру Фибоначчи побуждает инструмент анализа продуманные. Оценка 1, 2 или 3 подразумевает аналогичные усилия (1 - тривиальный), но если оценивает 8 или 13 (или выше), влияние как на выполнение, так и на бюджет может быть значительным. Ценность использования Story Points заключается в том, что команда может повторно использовать их, сравнивая аналогичную работу из предыдущих спринтов. Например, оценка 5 для одной команды может быть 2 для другой, имеющей старших разработчиков и более высокие навыки.
В каждой команде должен быть владелец продукта, хотя во многих случаях владелец продукта может работать с более чем одной командой. Владелец продукта несет ответственность за максимизацию ценностей продукта. Владелец продукта собирает информацию и обратную связь от многих людей и лоббируется ими, но в совокупности принимает решение о том, что создается.
Журнал невыполненных работ по продукту:
Обычно product owner и scrum-команда работают вместе, чтобы разработанная работа; это становится бэклогом продукта, который появляется по мере появления новой информации о продукте и его клиентах, и поэтому более поздние спринты могут касаться новой работы.
Бэклог продукта в простейшей форме - это просто список элементов, над которым нужно работать. Наличие правил внесения правил добавления, удаление и упорядочение работы помогает принять все обоснованные решения о том, как изменить продукт.
Владелец продукта расставляет приоритеты по элементам невыполненной работы по продукту, исходя из того, какие из них потребуются в очередь. Затем команда выбирает, какие предметы они могут выполнить в предстоящем спринте. На доске схватки перемещает элементы из бэклога продукта в бэклог спринта, который представляет собой список элементов, которые они будут создавать. Концептуально для команды идеально выбрать только то, что, по ее мнению, она может выполнить, из верхней части списка, но на практике нередко можно увидеть, что команды могут выполнить из списка элементов с более низким приоритетом. выбранные. Обычно это происходит, потому что в спринте остается время, чтобы выполнить больше работы. Пункты работать в верхней части бэклога, области, должны быть разбиты на истории, которые подходят для работы команды разработчиков. Чем дальше идет очередь, тем менее изысканными должны быть элементы. Как сказали Швабер и Бидл: «Чем ниже приоритет, тем меньше деталей, пока вы не сможете разглядеть элемент невыполненной работы».
команда «Бегущая команда» работает с невыполненной работой, прогнозировать, что изменения вне их среды - команда может узнать о новых рыночных возможностях, которые могут испытать угрозы со стороны участников конкурентов, а также отзывы клиентов, которые могут изменить способ работы продукта. Все эти новые идеи, как правило, побуждают команду адаптировать бэклог для включения новых знаний. Это часть фундаментального мышления гибкой команды. Мир меняется, бэклог никогда не заканчивается.
Доска задач схватки Бэклог спринта - это список работ, которые команда разработчиков должна выполнить во время следующего спринта. Список составляющих команды scrum, постепенно выбирает элементы бэклога продукта в приоритетном порядке из верхней части бэклога продукта, пока они не чувствуют, что у них работы для заполнения спринта. Команда разработчиков должна помнить о своей прошлой производительности, оценивая свои возможности для нового спринта, и использовать это в качестве ориентира для определения того, сколько «усилий» они могут выполнить.
Элементы невыполненной работы продукта могут быть разбиты на задачи команды разработчиков. Задачи в бэклоге спринта никогда не назначаются (и не передаются) команде кем-то другим; скорее члены команды подписываются (или вытягивают) задачи по мере необходимости в соответствии с приоритетом невыполненных работ, а также своими собственными навыками и возможностями. Это способствует самоорганизации команды разработки и вовлечению разработчиков.
Бэклог спринта является собственностью команды разработчиков. Часто сопутствующая доска задач используется для просмотра и изменения состояния задач спринта, например, выполнения, выполнения и выполнения.
После фиксации невыполненной работы спринта не может быть добавлена дополнительная работа, кроме команды. После того, как спринт был доставлен, выбирается следующий набор функций.
Приращение - это выпускаемый результат спринта, который соответствует цели спринта. Он формируется из всех завершенных элементов бэклога спринта. Инкремент должен быть полным, в соответствии с определением готового (DoD) команды scrum, полностью функционирующим и в пригодном для использования состоянии независимо от того, решает ли владелец продукта фактически развернуть его.
Следующие артефакты и методы могут быть использованы, чтобы помочь людям использовать Scrum.
Образец диаграммы Burndown для завершенного спринта, показывающий оставшиеся усилия в конце каждого дня. График выгорания спринта - это общедоступная диаграмма, показывающая оставшуюся работу в невыполненной работе спринта. Обновляется каждый день, он дает простое представление о ходе спринта. Он также быстрые визуализации для справки. Горизонтальная ось диаграммы выгорания спринта показывает дни в спринте, а вертикальная ось показывает объем работы, оставшейся каждый день (обычно представляющий собой оценку оставшихся часов работы).
Во время планирования спринта строится диаграмма идеального сгорания. Затем во время спринта каждый участник берет задачи из бэклога спринта и работает над ними. В конце дня они обновляют оставшиеся часы для выполнения задач. Таким образом, фактическая диаграмма выгорания обновляется день за днем.
Его не следует путать с диаграммой освоенного объема.
Образцом диаграммы выгорания для релиза, показывающей объем выполненных каждого спринта (MVP = минимально жизнеспособный продукт) Таблица выгорания релизов - это способ для обеспечения вид и поддержка прогресса в направлении выпуска. Он обновляется в конце каждого спринта и показывает прогресс в достижении объема прогноза. Горизонтальная ось диаграммы выгорания выпуска показывает спринты в выпуске, вертикальная ось показывает объем работы, выполненной в конце каждого спринта (обычно представляющий совокупные баллы выполненной работы за историю). Прогресс отображается в виде линии, которая растет горизонтальной линии, представляющей прогноз прогноза; Отображается с прогнозом, основанным на прогрессе на сегодняшний день, который указывает, сколько объема может быть выполнено в данной области.
Диаграмма выгорания релиза позволяет легко увидеть, сколько работы было выполнено, сколько работы было добавлено или удалено (если горизонтальная линия осциллографа перемещается) и сколько работы осталось сделать.
Критерии запуска для определения того, достаточно ли заданы спецификации и входные данные для запуска рабочего элемента, то есть пользовательской истории.
критерий выхода для определения того, завершен ли элемент невыполненной работы продукта. Во многих случаях Министерство обороны требует, чтобы все регрессионные тесты были успешными. Определение «готово» может варьироваться от одной команды схватки к другой, но должно быть единообразным внутри одной команды.
Общее усилие, на которое команда способна в спринте. Число определяется путем оценки работы (обычно в пользовательской истории баллов), выполненной в последнем спринте. Сбор исторических данных о скорости - это руководство, помогающее команде понять, сколько работы они могут выполнить.
Ограниченный по времени период, используемый для исследования концепции или создания простого прототипа. Скачки могут быть запланированы на период между спринтами, или, для более крупных команд, скачок может быть принят как одна из многих целей выполнения спринта. Скачки часто возникают перед поставкой крупных или сложных элементов невыполненной работы по продукту, чтобы обеспечить бюджет, расширить знания или предоставить подтверждение концепции. Продолжительность и цель (ы) спайк согласовывается между владельцем продукта и командой разработчиков перед запуском. В отличие от обязательств спринта, всплески могут или не могут обеспечить ощутимые, доступные и ценные функции. Например, цель всплеска может состоять в том, чтобы успешно принять решение о порядке действий. Пик заканчивается, когда время истекло, не обязательно, когда цель была доставлена.
Также называемая дрон-шипом, трассирующая пуля - это шип с текущей архитектурой, текущий набор технологий, текущий набор лучших практик, результатом которого является производственный код качества. Это может быть просто очень узкая реализация функциональности, но не одноразовый код. Это производственное качество, и остальные итерации могут основываться на этом коде. Название имеет военное происхождение как боеприпас, что делает путь пули видимым, что позволяет вносить поправки. Часто эти реализации предоставляют собой «быстрый запуск» по всем уровням приложения, например, подключение поля ввода одной формы к серверной части, чтобы убедиться, что уровни подключаются должным образом.
Преимущества Scrum могут быть более трудными для достижения, когда:
Как и другие гибкие методы, эффективное внедрение Scrum может поддерживаться с помощью широкого набора инструментов.
Многие компании используют универсальные инструменты, такие как электронные таблицы, для создания и поддержки таких артефактов, как блогэк спринта. Существуют также программные пакеты с открытым исходным кодом и проприетарные пакеты для Scrum, которые предназначены для разработки продуктов с использованием Scrum, либо используются несколько подходов к разработке, включая Scrum.
Другие организации реализуют Scrum без программных инструментов и свои артефакты в бумажных формах, таких как бумага, белые доски и стикеры.
Scrum - это обратная связь - управляемый эмпирический подход, который, как и любой другой эмпирический контроль процессов, основан на три столпа: прозрачность, проверка и адаптацию. Вся работа в рамках Scrum быть видна тем, кто отвечает за результат: процесс, рабочий процесс, прогресс и т. Д. Чтобы сделать эти видимые вещи эффективными, команда схватки часто проверяет. за работой. При частой проверке команда может определить, когда их работа выходит за допустимые пределы, и адаптировать свой или разработанный продукт.
Эти три столпа требуют доверия и открытости в команде, которая соответствует следующим пяти ценностям Scrum enable:
Гибридизация Scrum с другими методологиями разработки программного обеспечения является обычным явлением, поскольку Scrum не охватывает весь жизненный цикл разработки продукта ; поэтому необходимо добавить дополнительные процессы для создания более комплексной реализации. Например, в начале разработки продукта обычно использовать руководство по процессу для бизнес-моделей, требований и определения приоритетов начального высокоуровневого проектирования, а также прогнозирования бюджета и расписания.
Различные авторы и сообщества людей, которые используют Scrum, также предлагают более подробные того, как применить или адаптировать методы Scrum к конкретным проблемам или организациим. Многие называют эти методологические приемы «шаблонами» - по аналогии с шаблонами проектирования вуре и программном продукте.
Scrumban - это модель производства программного обеспечения, основанная на Scrum и Канбан. Scrumban особенно подходит для обслуживания продукта с частыми и неожиданными элементами, такими как производственные дефекты или ошибки программирования. В таких случаях ограниченные по времени спринты структуры Scrum могут воспринимать как менее полезные, хотя ежедневные мероприятия Scrum и другие методы, в зависимости от команды и текущей ситуации. Визуализация этапов работ и ограничения выполнения незавершенного работ и дефектов знакомы по модели Канбан. Используя эти методы, рабочий процесс команды направляется таким образом, чтобы обеспечить минимальное время выполнения каждого рабочего элемента или программирования, и, с другой стороны, гарантирует, что каждый член команды постоянно занят.
Чтобы проиллюстрировать каждый этап работы, команды, работающие в одном пространстве, используют стикеры или большие доску. В случае децентрализованных команд можно использовать программное обеспечение для сценических иллюстраций, например, Assembla, JIRA или Agilo.
Основное различие между Scrum и Kanban заключается в том, что в Scrum-работа делится на спринты, которые для фиксированного количества времени, тогда как в Kanban поток работы является непрерывным. Это видно в таблицах этапов работы, которые в Scrum очищаются после каждого спринта, тогда как в Kanban все задачи отмечены в одной таблице. Scrum ориентирован на команды с многогранным ноу-хау, тогда как Kanban делает возможными специализированные функциональные команды.
Scrum of scrums - это метод масштабного управления Scrum для нескольких команд работают над одним и тем же продуктом, позволяя им обсуждать прогресс в их взаимозависимости, уделяя особое внимание тому, как координировать доставка программного обеспечения, особенно в областях дублирования и интеграции. В зависимости от ритма (времени) схватки соответствующий ежедневный схватка для каждой схватки соответствует назначению одного члена в качестве одного члена в соответствии с послами из других команд. В зависимости от контекста, послами могут быть технические участники или scrum-мастер каждой команды.
Вместо простого обновления прогресса, схватка scrum должна быть определена на том, как команды коллективно работают над разрешением, смягчением или принятием любого риска, препятствия, зависимости и допущения (RIDA), которые были идентифицированы. Схватка отслеживает эти данные RIDA с помощью собственного бэклога, как такая доска рисков (иногда такая доска рисков) ROAM после инициалов решенных, принадлежащих, контролирующих и смягченных), что обычно приводит к большей экономике и сотрудничеству между командами..
Каждый представитель должен отвечать на следующие четыре вопроса:
Как пишет Джефф Сазерленд,
Я изначально определил Скрам Scrums (Кен Швабер работал со мной в IDX), я могу с уверенностью сказать, что Scrum of Scrums - это не «мета Scrum». Scrum of Scrums в том виде, в котором я его использовал, отвечает за доставку программного обеспечения всех команд к Определению Готово в конце спринта или за выпуски во время спринта. PatientKeeper доставляется в производство четыре раза за спринт. Ancestry.com доставляет в производство 220 раз за двухнедельный спринт. Hubspot доставляет живое программное обеспечение 100-300 раз в день. Мастер Scrum of Scrums несет ответственность за выполнение этой работы. Итак, Scrum of Scrums - это оперативный механизм доставки.
Крупномасштабный Scrum (LeSS) - это среда разработки продукта, которая расширяет Scrum с помощью правил масштабирования и рекомендаций без исходных потерь целей Scrum.
Структура из двух уровней: первый уровень LeSS предназначен для восьми команд; второй уровень, известный как «LeSS Huge», вводит дополнительные элементы масштабирования для разработки с участием до сотен разработчиков. «Масштабирование Scrum начинается с понимания и способности принять стандартный Scrum для одной команды. Масштабный Scrum требует изучения цели элементов Scrum для достижения той же цели, оставаясь в рамках ограничений стандартного правила Scrum ».
Бас Водде и Крейг Ларман развили структуру LeSS на основе своего опыта работы с крупномасштабной разработкой продуктов, особенно в телекоммуникационной и финансовой отраслях. Он развился, взяв Scrum и попробовал множество различных экспериментов, чтобы узнать, что работает. В 2013 году меры были закреплены в правилах LeSS. Цель LeSS - «очистить от накипи» сложность организации, избавиться от ненужных организационных решений и решить их более простыми методами. Меньше ролей, меньше управления, меньше организационных структур.
Сообщается, что церемониальные встречи Scrum вредит продуктивности и тратят время, которое можно было бы лучше потратить на фактическую продуктивность
Практики Scrum, если они не реализованы правильно в духе Agile Manifesto, имеют тенденцию превращаться в форму микроменеджмента.
Scrum также предполагает, что количество усилий, необходимые для выполнения определенных задач, может быть точно количественно с помощью показателей, хотя в большинстве случаев это может быть непредсказуемым.
 | На Викискладе есть материалы, связанные с Scrum (разработка). |
