Скрам — Обзор

Agile стал одним из основных модных слов в индустрии разработки программного обеспечения. Но что такое гибкая разработка? Проще говоря, гибкая разработка — это другой способ выполнения команд и проектов по разработке программного обеспечения.

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

Модель водопада

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

Итеративная инкрементная модель

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

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

Agile Development

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

Ранние реализации гибких методов включают Rational Unified Process (1994), Scrum (1995), Crystal Clear, Extreme Programming (1996), адаптивную разработку программного обеспечения, функционально-ориентированную разработку (1997) и метод разработки динамических систем (DSDM) (1995). Теперь они все вместе называются гибкими методологиями , после того как Agile Manifesto был опубликован в 2001 году.

Agile Manifesto

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

Agile Manifesto выглядит следующим образом:

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

• Индивидуумы и взаимодействия над процессами и инструментами
• Рабочее программное обеспечение над всеобъемлющей документацией
• Сотрудничество с клиентом в процессе переговоров
• Реагирование на изменения после плана

То есть, хотя в пунктах справа есть значение, мы больше ценим элементы слева ».

… Манифест для гибкой разработки программного обеспечения, Авторы: Бек, Кент и др. (2001)

Определение проворных элементов манифеста

Пункты манифеста слева можно описать следующим образом:

Предмет манифеста	Описание
Индивидуумы и взаимодействия	Значение должно быть уделено: самоорганизация и самомотивация членов команды постоянное взаимодействие для работы, разъяснения, информация среди членов команды
Рабочее программное обеспечение	Поставка рабочего программного обеспечения через короткие промежутки времени помогает завоевать доверие и уверенность клиентов в команде.
Сотрудничество с клиентами	Постоянное участие заказчика в команде разработчиков обеспечивает связь необходимых модификаций.
Отвечая на изменения	Сосредоточьтесь на быстром реагировании на предложенные изменения, что стало возможным благодаря коротким итерациям.

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

Ключевые принципы Agile

Agile Manifesto основан на следующих принципах:

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

Agile методологии

Методология динамического развития системы (DSDM)

Это гибкая структура для программных проектов. Он был использован для тонкой настройки традиционных подходов. Самая последняя версия DSDM называется DSDM Atern. Название Atern — сокращение от Arctic Tern — морской птицы, которая может путешествовать на огромные расстояния, что представляет многие особенности метода, такие как естественные способы работы, такие как расстановка приоритетов и сотрудничество.

Scrum

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

Экстремальное программирование (XP)

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

Разработка через тестирование (TDD)

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

Опираться

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

Kanban

Это система для улучшения и поддержания высокого уровня производства. Kanban — это один из методов, с помощью которого достигается Just-In-Time (JIT), стратегия, используемая организациями для контроля затрат на инвентаризацию. Kanban стал эффективным инструментом поддержки всей производственной системы, и это оказалось отличным способом для продвижения улучшений.

Заключение

За последние 10 лет постоянно растет количество историй успеха, в которых компании значительно улучшили успех и производительность своих групп по разработке ИТ и проектов с гибкими практиками. Это привело к тому, что Agile получил широкое распространение в различных отраслях, включая СМИ и технологии, крупные корпорации и даже правительство.

Agile Framework помогает командам извлечь выгоду из:

• Более быстрое время доставки / Рынок
• Уменьшить неопределенность и риск
• Увеличьте возврат инвестиций (ROI), сосредоточившись на потребительской ценности

Среди этих различных гибких методологий Scrum за последние 20 лет оказался чрезвычайно успешным во всем мире.

Скрам — Фреймворк

Scrum является основой для разработки и поддержки сложных продуктов. Кен Швабер и Джефф Сазерленд разработали Scrum. Вместе они стоят за Правилами Скрама.

Скрам Определение

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

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

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

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

Примечание. По всей отрасли существуют заблуждения, что Scrum означает отсутствие документации, команда scrum состоит только из разработчиков и так далее. Это не совсем так; мы дадим разъяснения по ним в следующих разделах.

Scrum Process Framework

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

спринт

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

• При планировании спринта работа, выполняемая в спринте, планируется совместно командой Scrum.

• Ежедневная встреча Scrum — это 15-минутное мероприятие для Scrum Team, которое позволяет синхронизировать действия и составить план на этот день.

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

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

При планировании спринта работа, выполняемая в спринте, планируется совместно командой Scrum.

Ежедневная встреча Scrum — это 15-минутное мероприятие для Scrum Team, которое позволяет синхронизировать действия и составить план на этот день.

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

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

Заключение

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

Скрам — Роли

Команда Scrum состоит из трех ролей, а именно: ScrumMaster, владелец продукта и команда.

ScrumMaster

ScrumMaster (иногда пишется как Scrum Master, хотя после «Scrum» в официальном термине нет пробела) является хранителем процесса scrum. Он / она несет ответственность за

• заставить процесс идти гладко
• устранение препятствий, влияющих на производительность
• организация и проведение критических встреч

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

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

Владелец продукта является единственным лицом, ответственным за управление бэклогом продукта. Управление бэклогом

• Четко выраженные позиции в продуктах.

• Заказ товаров из списка продуктов для наилучшего достижения целей и задач.

• Оптимизация ценности работы, которую выполняет Команда.

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

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

Четко выраженные позиции в продуктах.

Заказ товаров из списка продуктов для наилучшего достижения целей и задач.

Оптимизация ценности работы, которую выполняет Команда.

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

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

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

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

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

Команда

Команда самоорганизуется и кросс-функциональна. Это означает, что команда состоит из аналитиков, дизайнеров, разработчиков, тестировщиков и т. Д. В зависимости от ситуации и в зависимости от проекта.

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

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

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

Скрам — СкрамМастер

ScrumMaster является обученным ответственным лицом, которое оказывает услуги, как описано ниже —

Услуги ScrumMaster для Владельца продукта

ScrumMaster обслуживает Владельца продукта несколькими способами, в том числе —

• Поиск методов эффективного управления бэклогом продуктов.

• Помочь команде Scrum понять необходимость в четких и кратких материалах, содержащихся в бэклоге продукта.

• Понимание планирования продукта в эмпирической среде.

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

• Понимание и практика ловкости.

• Содействие Scrum событиям по мере необходимости.

Поиск методов эффективного управления бэклогом продуктов.

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

Понимание планирования продукта в эмпирической среде.

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

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

Содействие Scrum событиям по мере необходимости.

Услуги ScrumMaster для команды Scrum

ScrumMaster обслуживает Scrum Team несколькими способами, в том числе —

• Тренировка Скрам Команды по самоорганизации и кросс-функциональности.

• Помощь команде Scrum в создании ценных продуктов.

• Устранение препятствий на пути прогресса Скрам Команды.

• Содействие Scrum событиям по запросу или необходимости.

• Тренировка команды Scrum в организационной среде, в которой Scrum еще не полностью принят и не понят.

Тренировка Скрам Команды по самоорганизации и кросс-функциональности.

Помощь команде Scrum в создании ценных продуктов.

Устранение препятствий на пути прогресса Скрам Команды.

Содействие Scrum событиям по запросу или необходимости.

Тренировка команды Scrum в организационной среде, в которой Scrum еще не полностью принят и не понят.

СкрамМастер Услуги для организации

ScrumMaster обслуживает организацию несколькими способами, включая:

• Руководство и тренировка организации в принятии Scrum.

• Планирование внедрения Scrum в организации.

• Помогая сотрудникам и заинтересованным сторонам понять и принять Scrum и эмпирическую разработку продукта.

• Вызывает изменения, которые увеличивают производительность Scrum Team.

• Работа с другими ScrumMasters для повышения эффективности применения Scrum в организации.

Руководство и тренировка организации в принятии Scrum.

Планирование внедрения Scrum в организации.

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

Вызывает изменения, которые увеличивают производительность Scrum Team.

Работа с другими ScrumMasters для повышения эффективности применения Scrum в организации.

Заключение

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

Scrum — События

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

• Спринт
• Спринт Планирование
• Ежедневные встречи Scrum
• Обзор Спринта
• Ретроспектива Спринта

Спринт

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

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

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

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

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

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

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

Планирование Спринта фокусируется на следующих двух вопросах —

• Что должно быть и что может быть доставлено в Приращении Спринта?
• Как будет достигнута работа, необходимая для выполнения Sprint?

Входные данные для этой встречи —

• Журнал ожидания продукта
• Последний продукт Инкремент
• Прогнозируемая мощность команды во время спринта
• Прошлые показатели команды

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

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

Работа во время спринта оценивается во время планирования спринта и может иметь различные размеры и / или усилия. К концу встречи по планированию спринта работа делится на задачи продолжительностью один день или меньше. Это делается для облегчения распределения работы и отслеживания завершения. Если команда понимает, что у нее слишком много или слишком мало работы, она может пересмотреть выбранные позиции Бэклога продукта с Владельцем продукта.

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

Ежедневные встречи Scrum

Ежедневное совещание Scrum — это 15-минутное совещание для Группы, которое проводится ежедневно, чтобы быстро понять работу с момента последнего Ежедневного совещания Scrum и составить план на следующие 24 часа. Эта встреча также называется Ежедневная встреча.

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

Во время встречи каждый член команды объясняет:

• Что он сделал вчера, что помогло команде достичь цели в спринте?

• Что он сделает сегодня, чтобы помочь команде достичь цели спринта?

• Видит ли он какие-либо препятствия, мешающие ему или команде достичь цели спринта?

Что он сделал вчера, что помогло команде достичь цели в спринте?

Что он сделает сегодня, чтобы помочь команде достичь цели спринта?

Видит ли он какие-либо препятствия, мешающие ему или команде достичь цели спринта?

Daily Scrum ошибочно считается событием отслеживания статуса, хотя на самом деле это событие планирования.

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

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

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

Ниже приведены преимущества ежедневных встреч Scrum —

• Улучшить коммуникацию в Команде.

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

• Выделите и способствуйте быстрому принятию решения.

• Повысить уровень знаний команды.

Улучшить коммуникацию в Команде.

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

Выделите и способствуйте быстрому принятию решения.

Повысить уровень знаний команды.

Спринт Обзор

Обзор Спринта проводится в конце каждого Спринта. Во время обзора спринта просматривается презентация полученного приращения. На этой встрече Scrum Team и заинтересованные стороны сотрудничают, чтобы понять, что было сделано в Sprint. Исходя из этого и любых изменений в Журнале работы продукта во время Спринта, участники приходят к следующим необходимым шагам, которые могут оптимизировать ценность. Таким образом, целью Sprint Review является получение обратной связи и прогресса в совокупности.

Спринт-обзор обычно проводится в течение двух часов для двухнедельных спринтов и в течение четырех часов для месячных спринтов.

Scrum Master гарантирует, что —

• Встреча состоится.

• Участники понимают цель.

• Встреча сосредоточена на требуемой повестке дня и завершается в течение требуемого времени.

Встреча состоится.

Участники понимают цель.

Встреча сосредоточена на требуемой повестке дня и завершается в течение требуемого времени.

Обзор Sprint включает в себя следующие аспекты —

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

• Владелец продукта объясняет, какие элементы журнала невыполненных работ были выполнены во время спринта, а какие еще не выполнены.

• Команда обсуждает, что прошло хорошо во время спринта, с какими проблемами он столкнулся и как эти проблемы были решены.

• Команда демонстрирует выполненную работу и отвечает на вопросы, если таковые имеются, о Приращении.

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

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

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

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

Владелец продукта объясняет, какие элементы журнала невыполненных работ были выполнены во время спринта, а какие еще не выполнены.

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

Команда демонстрирует выполненную работу и отвечает на вопросы, если таковые имеются, о Приращении.

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

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

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

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

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

Цель ретроспективы Спринта —

• Объедините уроки последнего спринта в отношении людей, отношений, процессов и инструментов.

• Определите основные пункты, которые прошли успешно и потенциальные улучшения.

• Создание плана по внедрению улучшений для повышения качества продукции.

Объедините уроки последнего спринта в отношении людей, отношений, процессов и инструментов.

Определите основные пункты, которые прошли успешно и потенциальные улучшения.

Создание плана по внедрению улучшений для повышения качества продукции.

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

Ссылка

Scrum Guide © 1991-2013 Кен Швабер и Джефф Сазерленд, Все права защищены.

Скрам — Артефакты

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

• Резерв продукта
• Журнал Спринта
• Диаграмма выгорания
• инкремент

Это минимально необходимые артефакты в проекте Scrum, и артефакты проекта этим не ограничиваются.

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

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

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

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

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

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

Элементы Журнала Продукта могут быть обновлены в любое время Владельцем Продукта или по усмотрению Владельца Продукта.

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

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

Журнал Спринта

Журнал ожидания для Sprint — это набор элементов Журнала работы с продуктом, выбранных для Sprint, а также план для увеличения продукта и реализации цели Sprint.

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

Журнал ожидания спринта — это план с достаточным количеством деталей, которые можно понять, но команда должна отслеживать «Ежедневные схватки». Команда изменяет Журнал Спринта во всем Спринте, а Журнал Спринта появляется во время Спринта. Это происходит, когда команда прорабатывает план и узнает больше о работе, необходимой для достижения цели спринта.

Поскольку новая работа требуется, Команда добавляет ее в Журнал ожидания Спринта. По мере того, как работа выполнена или завершена, предполагаемая оставшаяся работа обновляется Когда элементы плана считаются ненужными, они удаляются. Только Команда может изменить свой Журнал Спринта во время Спринта. Журнал ожидания Спринта — это хорошо видимая в реальном времени картина работы, которую Команда планирует выполнить во время Спринта, и она принадлежит исключительно Команде.

инкремент

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

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

То же самое понимание помогает Группе узнать, сколько элементов Бэклога продукта она может выбрать во время Планирования Спринта. Целью каждого Sprint является предоставление Приращений потенциально высвобождаемой функциональности.

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

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

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

Диаграмма выжигания спринта

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

Спринт Burn-Down Chart — это практика для отслеживания работы, затраченной Scrum Team. Было доказано, что это полезный метод для отслеживания прогресса Спринта в достижении Цели Спринта.

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

Заключение

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

Ссылка

Scrum Guide © 1991-2013 Кен Швабер и Джефф Сазерленд, Все права защищены.

Scrum — Истории пользователей

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

Пользовательские истории

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

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

В проектах Scrum Product Backlog — это список пользовательских историй. Эти пользовательские истории располагаются по приоритетам и заносятся в список невыполненных работ на совещании по планированию спринта.

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

Структура пользовательской истории

Структура User Story выглядит следующим образом:

Как <Тип пользователя> ,

Я хочу <Выполнить некоторую задачу> ,

Так что <я могу достичь какой-то цели / выгоды / ценности> .

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

История пользователя: снятие наличных с клиента

Как клиент ,

Я хочу снять наличные в банкомате ,

Чтобы мне не пришлось ждать в очереди в банке

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

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

Ниже приведен примерный критерий приемлемости для примера пользовательского рассказа «Снятие наличных».

Критерий принятия 1:

Учитывая, что аккаунт кредитоспособен

• И карта действительна
• И диспенсер содержит деньги,

Когда клиент запрашивает наличные

Затем убедитесь, что учетная запись списана

• И убедитесь, что деньги выдаются
• И убедитесь, что карта возвращается.

Критерий приемки 2:

С учетом того, что счет списан

• И карта действительна

Когда клиент запрашивает наличные

Затем убедитесь, что сообщение об отказе отображается

• И убедитесь, что деньги не выдаются
• И убедитесь, что карта возвращается.

Написание пользовательских историй

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

Нефункциональные требования в пользовательских историях

Нефункциональные требования можно включить и в пользовательские истории. В данном примере банкомата, банкомат, который должен быть доступен пользователю 24X7, 365 дней, является нефункциональным требованием, которое можно описать с помощью варианта использования.

Управление пользовательскими историями

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

Преимущества с пользовательскими историями

• Основное преимущество User Story заключается в самом определении, ориентированном на пользователя. Это потому, что, в конечном счете, именно пользователь будет использовать продукт в соответствующих пользовательских сценариях. Он соединяет конечных пользователей с членами команды.

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

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

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

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

Основное преимущество User Story заключается в самом определении, ориентированном на пользователя. Это потому, что, в конечном счете, именно пользователь будет использовать продукт в соответствующих пользовательских сценариях. Он соединяет конечных пользователей с членами команды.

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

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

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

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

Заключение

Пользовательские истории Scrum приближают пользователей к команде Scrum и предотвращают сюрпризы в последнюю минуту.

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

Отслеживание спринта обычно выполняется с использованием Burn-Down Chart. График выгорания показывает оставшееся усилие в дневное количество часов. Например, давайте рассмотрим 2-недельный спринт —

Спринт Продолжительность : 2 недели

Количество дней в неделю : 5

Количество часов в день : 6

Количество ресурсов : 6

Следовательно, общее оставшееся усилие в начале спринта составляет 2 * 5 * 6 * 6 = 360 часов.

Следовательно, в идеальном сценарии 36 часов работы сокращаются в оставшейся работе, и диаграмма выгорания выглядит следующим образом:

Если спринт выполняется ежедневно, как планировалось, ход схватки практически совпадает с идеальным баром.

Если работа по спринту задерживается, а временное обязательство не выполняется, диаграмма выгорания выглядит следующим образом:

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

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

Заключение

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

Скрам — Оценка

В Scrum Projects оценка выполняется всей командой во время совещания по планированию спринта. Целью Оценки будет рассмотрение пользовательских историй для спринта по приоритетам и по способности команды выполнить поставку в течение временного интервала спринта.

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

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

Размер приращения продукта оценивается в терминах очков истории пользователя. Как только размер определен, усилия оцениваются с помощью прошлых данных, т. Е. Усилия на точку пользовательской истории, называемой продуктивностью.

Методы оценки Скрама

Оценка Scrum пользовательских историй в терминах степени сложности для каждой из пользовательских историй. Для оценки степени сложности используется конкретная шкала.

Существует несколько типов шкал, которые используются в Scrum Estimate. Ниже приведены некоторые примеры —

• Числовой размер (от 1 до 10)
• Размеры футболки (XS, S, M, L, XL XXL, XXXL)
• Последовательность Фибоначчи (1, 2, 3, 5, 8, 13, 21, 34 и т. Д.)
• Породы собак (чихуахуа, ………, дог)

Техника оценки обычно выбирается таким образом, чтобы вся команда Scrum была знакома и довольна значениями шкалы. Наиболее часто используемый и самый популярный метод — это Покер планирования, основанный на последовательности Фибоначчи.

Планирование Техники Покера

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

Планирование Покер играется с колодой карт. Поскольку используется последовательность Фибоначчи, карты имеют номера — 1, 2, 3, 5, 8, 13, 21, 34 и т. Д. Эти числа представляют Очки истории. У каждого оценщика есть колода карт. Числа на карточках должны быть достаточно большими, чтобы их могли видеть все члены команды, когда один из членов команды держит карточку.

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

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

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

Команда может обсудить историю и их оценки в течение еще нескольких минут.

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

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

Преимущества планирования оценки покера

Планирование покера сочетает в себе три метода оценки —

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

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

Аналогия : Оценка аналогии использует сравнение пользовательских историй. Оцениваемая пользовательская история сравнивается с аналогичными пользовательскими историями, реализованными ранее. Это приводит к точным результатам, так как оценка основана на проверенных данных.

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

Заключение

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

Scrum — Инструменты

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

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

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

Ниже приведен список некоторых инструментов Scrum, доступных на рынке по состоянию на день. Инструменты с открытым исходным кодом помечены звездочкой.

Axosoft	Airgile	Agile Cockpit	Джира (ГринХоппер)	Mingle
Scrumwise	Agilo For Scrum	Банановый скрам	Kunagi	Сейчас
Версия первая	AgileWrap	Ежедневное Scrum	Интервалы	Pango Scrum
Acunote	Agile Tracking Tool *	Digaboard *	iMeta Agility	Pivotal Tracker
Agile Agenda	Agile Task	EasyBacklog	Ice Scrum *	pmScrum
Agile Bench	Agile Soup	Объяснить PMT	Hansoft	Prj Planner
Agile Buddy	Проворный менеджер	Agile Express *	GravityDev	Карты проекта
Agile Fant *	Agile Log	Fire Scrum *	Fulcrum *	Квантовый Шепот
Quick Scrum	Retrospectiva *	Scrum’d	Скрам Фабрика *	Scrumpy
Rally Dev	Scrinch *	Scrum Dashboard *	Scrum Edge	Scrum Pad
Redmine Backlogs	Scrum 2 Go	Скрам Стол	Скрам До	Чирикать Scrum
Scrumrf	Время схватки *	Scrumwise	Выбор фабрики решений	Снасти*
Городская черепаха	ScrumTool	Скрам Работы	Timebox	Острый Оранжевый Скрам

Заключение

Agile в целом, Scrum в частности не означает, что нет документации работы. Скрам-артефакты определены, Scrum-планирование и отслеживание хорошо известны.

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

Скрам — Преимущества

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

Преимущества для клиента

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

Преимущества для организации

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

Преимущества для менеджеров по продукту

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

Преимущества для руководителей проектов

Менеджер проекта играет роль Scrum Master в проекте. Совместная природа Scrum способствует простому и конкретному планированию и отслеживанию. Использование Burndown Charts для понимания оставшейся работы, а также ежедневные встречи Scrum позволяют руководителю проекта постоянно узнавать о состоянии проекта. Эта осведомленность необходима для мониторинга проекта, а также для быстрого выявления и решения проблем.

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

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

Скрам — Сертификаты

Scrum-сертификаты предлагаются Scrum Alliance. Предлагаются следующие сертификаты —

• Сертифицированный ScrumMaster (CSM)
• Сертифицированный владелец продукта Scrum (CSPO)
• Сертифицированный специалист по схватке (CSP)
• Сертифицированный Scrum Coach (CSC)
• Сертифицированный Scrum Trainer (CST)

Сертифицированный ScrumMaster (CSM)

Сертифицированный Scrum Master — это базовый сертификат, позволяющий стать членом Scrum Alliance, сыграть роль Scrum Master и получить право на получение других сертификатов. Сертификация требует посещения курса CSM. После этого кандидат получает электронное письмо с указанием деталей членства в Scrum и онлайн-экзамена CSM. После сдачи экзамена кандидат получает сертифицированную сертификацию ScrumMaster (CSM).

Сертифицированный владелец продукта Scrum (CSPO)

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

Сертифицированный специалист по схватке (CSP)

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

Кандидат может получить сертификат CSP сразу после сертификации CSM или сертификации CSPO, при условии, что кандидат активно практикует роль ScrumMaster или роль Владельца продукта в течение требуемого периода времени.

Сертифицированный Scrum Coach (CSC)

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

Сертифицированный Scrum Trainer (CST)

Сертифицированный Scrum Trainer — это сертификат для тех, кто хочет преподавать классы CSM или CSPO. Кандидаты должны иметь либо CSM, либо CSPO, и должны быть CSP не менее года, прежде чем подавать заявку.

Scrum — часто задаваемые вопросы

Ниже приведены некоторые часто задаваемые вопросы о Scrum —

Вопрос: В чем разница между Scrum и Agile Development?

Ответ : Agile Development — это методология программного обеспечения, в то время как Scrum — одна из структур процессов, которая следует за Agile.

Вопрос: Спринты и итерации одинаковы?

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

• Жизненные циклы Sprint и Iteration разные.
• Спринты ограничены по времени, а итерации нет.
• Продолжительность Спринтов намного меньше по сравнению с продолжительностью Итераций.

Вопрос: Является ли Scrum Master названием должности или ролью, которую заполняет кто-то с существующим названием работы?

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

Вопрос: Могут ли роли Владельца продукта и ScrumMaster играть один и тот же человек?

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

Вопрос: Не требуется ли для Scrum Project никакой документации?

Ответ : Нет. Scrum-проекты, как и любые другие проекты, требуют документации, такой как пользовательские истории, дизайн, тестовые примеры и т. Д.

Заключение

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