Pbr scrum что это

User Stories в Agile-разработке. Критерии приёмки (Acceptance Criteria).
Свод правил. Сценарно-ориентированный подход. Использование Gherkin.

Критерии приёмки (Acceptance Criteria, AC) — важная практика для улучшения коммуникации между разработчиками и заказчиками, а также неотъемлемая часть создания качественных пользовательских историй (User Stories) в Agile-проектах.

В статье мы рассмотрим примеры составления AC для User Story. Для составления критериев приёмки будем использовать 2 техники: свод правил и сценарно-ориентированный подход на Gherkin, основанный на методологии BDD.

Статья полезна аналитикам, владельцам продуктов, менеджерам и тестировщикам, работающим с User Stories.

Время на чтение статьи: 12 минут
Оглавление

Основы бизнес-анализа и разработки
требований в Agile

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

6 ScrumMaster Как проводить PBR

Ценность критериев приёмки

Критерии приёмки (Acceptance Criteria, AC) — это неотъемлемая часть пользовательских историй в Agile-разработке. Критерии приёмки одинаково важны и команде разработки, и заказчику. С их помощью мы:

• Определяем границы User Story
• Достигаем консенсуса между командой и заказчиком о том, что именно делаем
• Увеличиваем точность оценки User Story, качественно планируем занятость команды и сроки выпуска продукта

• Готовим тестовые кейсы и можем автоматизировать тестирование
• Выявляем негативные сценарии

Ценность критериев приёмки

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

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

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

Другая важная функция критериев приёмки — планирование и оценка задач. Они помогают команде разработчиков правильно оценивать User Story, распределять пользовательские истории между исполнителями и планировать выпуск функционала заказчику.

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

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

Источник: systems.education

Методология Scrum

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

История появления:

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

В 1993 г. за счет придуманного Дж.Сазерлендом скрам-процесса его команда Easel Corporation смогла за рекордно короткий срок в 6 месяцев создать сложный программный продукт для ФБР США, при этом уложиться в бюджет, допустить минимальное количество багов и успешно завершить проект, который другие подрядчики не могли завершить на протяжении 10 лет.

Катализатором создания гибких agile-подходов управления проектами, к которым относится Scrum, стали Теория ограничений, революционная практика бережливого производства и командной работы компаний Toyota, Honda, Fuji-Xerox, Canon. Необходимость создания инновационного подхода к разработке продуктов возникла в связи с тем, что Waterfall — классический последовательный подход — не позволял быстро и экономично, без срыва сроков и превышения бюджета, создавать продукты, максимально отвечающие требованиям клиента.

Каскадная модель (Waterfall/Водопад) предполагает поэтапное продвижение к цели и работу по заранее согласованному техническому заданию, строго по изначальному плану. Процесс идет медленно, а поскольку готовый продукт поставляется по окончании проекта, часто итог абсолютно не удовлетворяет заказчика. Такая модель разработки и управления проектами подходит для предсказуемых процессов с четким техзаданием и низким объемом изменений, без вариативности в процессе создания. Например, для проекта по строительству здания.

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

Для какого вида бизнеса или коллектива Scrum наиболее применим

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

Методологию можно применять в любых видах деятельности, где в процессе создания продукта есть непрогнозируемый объем изменений и при этом требуется слаженная коллективная работа. Как agile-коуч я запускала и развивала Scrum-команды в компаниях из сфер образования, онлайн-обучения, производства одежды, разработки сайтов, производства видеорекламы. Знаю, что по Скраму уже работают и нотариусы, и дизайнеры. Главное, чтобы размер одной скрам-команды не превышал 5-9 человек и все понимали правила и командные процедуры, по которым строится работа.

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

Как и по каким принципам Scrum работает на практике

C 1995 г. Метод совершенствовали и дополняли, а с 2010 года все основные положения собраны в Scrum Guide (скрам гайд): понятный документ с описанием всех составляющих фреймворка и инструкциями правильной работы по Scrum. В нем содержатся правила, мероприятия, артефакты, роли людей и их взаимодействие внутри процесса.

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

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

Команде важно распределить 2 роли: Владелец продукта (Product Owner) и Scrum-мастер. Владелец продукта — ответственный за максимальную ценность продукта, реализацию проекта, определение бизнес-приоритетов и работу всей команды. Scrum-мастер отвечает за корректное внедрение Scrum, чтобы сам процесс был понятен всем участникам и эффективно работал по правилам.

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

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

Как работает Scrum процесс

Команда работает по спринтам — интервалам с одинаковой длительностью. Чаще всего это спринты длиной 1 или 2 недели, максимальный спринт — 1 месяц.

Каждый спринт состоит из одинакового набора регулярных мероприятий: Планирование спринта, ежедневные Daily стэндап-митинги, Обзор спринта и Ретроспектива спринта.

Команда записывает в Бэклог список функций, требований к продукту, желаний заказчика, добавляет в него новые задачи по ходу работы. На Планировании спринта по выбранным Владельцем продукта приоритетам бэклога команда определяет цель спринта и задачи на спринт для ее достижения. Технически спринты размещаются на Scrum-доску, где каждому участнику команды видны его задачи на спринт.
Ежедневно проводит короткие 15-минутные митинги для синхронизации и обсуждения, что из плана спринта сделано за вчера, что будет сделано сегодня и есть ли проблемы, требующие решения. В конце спринта команда проводит Review-обзор спринта с презентацией результата работы и подведением итогов достижения цели спринта. А после на Ретроспективе спринта обсуждает, как может улучшить сам процесс и командное взаимодействие.

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

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

Пошаговый алгоритм внедрения Scrum в компании

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

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

Опорный чек-лист внедрения Scrum выглядит так:

1. сформируйте кросс-функциональную скрам-команду
2. прочитайте и обсудите в команде скрам-гайд
3. распределите роли в команде: команда разработки, Владелец продукта, Скрам-мастер
4. определите длительность спринта
5. организуйте работу команды: где будете фиксировать все задачи (например, Trello, Jira) и когда проводить все регулярные скрам-встречи
6. сформируйте бэклог
7. приоритизируйте бэклог — Владелец продукта определяет, что из всего списка имеет самый высокий приоритет и пойдет в работу в первую очередь
8. проведите первое планирование и распределите, кто и что конкретно будет делать в спринте — все участники команды сами определяют и фиксируют свои задачи
9. контролируйте процесс и динамику выполнения задач на ежедневных стэндапах — это задача Скрам-мастера
10. в конце спринта подведите в команде итоги, что получилось, что нет и почему
11. завершите спринт ретроспективой — узнайте, как дела у людей, с которыми вы работаете, обсудите, как вы можете улучшить командное взаимодействие
12. повторите новый спринт
13. обкатайте процесс на одной команде и только потом переходите к масштабированию на департамент или всю компанию

Подводные камни использования Scrum

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

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

Сложности, с которыми может столкнуться компания при внедрении:

1. Cопротивление изменениям со стороны линейных сотрудников и топ-менеджеров.
2. Неуместный микроменеджмент: когда работаем по Scrum, но по старой памяти директивного менеджмента руководитель в середине спринта меняет цели и докидывает всей команде незапланированные задачи.
3. Product owner и scrum-мастер в одном лице: у человека не хватает времени на качественную работу по своему приоритету. Не стоит объединять эти 2 роли в одном человеке, у них разные приоритеты и функционал. Скрам-мастер заботится о процессе, командных встречах, людях и атмосфере в команде, Владельцу продукта же нужно фокусироваться на приоритизации бэклога и результативности работы всего направления.

Если вы хотите научиться применять на практике Agile, Scrum и Kanban и получить все преимущества от использования гибких подходов, тогда регистрируйтесь на наш ближайший тренинг Agile Certified Professional 22-25 ноября 2022 в онлайн формате!

Зарегистрироваться на тренинг

Подписывайтесь на наши соцсети, чтобы не пропускать новые статьи:

Источник: productlab.ru

Основы SCRUM: владелец продукта и скрам-мастер

Как выглядит структура SCRUM, в чем смысл итерационного подхода в управлении проектом и какие основные роли существуют в рамках такого подхода?

24.04.2019 12:40 11695

На основе лекции Максима Якубовича, преподавателя MBA Русской Школы Управления, эксперта по управлению проектами и моделированию бизнес-процессов.

Спринт

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

Как разрабатывать продукт

В итерационном подходе продукт разрабатывают параллельно. Каждая итерация должна включать (эти стадии особенно часто используют при разработке ИТ-проекта): 1. Проработку требований. 2. Создание дизайна. 3. Разработку продукта. 4. Тестирование.

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

Три важные части SCRUM

Метод состоит из трех важных частей: 1. Роли: владелец продукта, скрам-мастер, команда. 2. Ритуалы (типы событий): планирование спринта, обзор спринта, спринт ретроспектива, ежедневный скрам. 3. Артефакты (документы): бэклог продукта, спринт бэклог, burndown charts. Этот простой для понимания подход описан всего на 18 страницах SCRUM Guide. В этом материале мы опишем две первые роли.

Узнать больше о методах управления проектами можно из курсов Русской Школы Управления.

Роли в SCRUM

Скрам предполагает наличие трех ролей: 1. Владелец продукта. 2. Скрам-мастер. 3. Команда. По сравнению с руководством по управлению проектами PMBoK, в скраме на одну роль меньше. Роль заказчика проекта в этой парадигме частично выполняет владелец продукта.

Эти роли похожи, но не совпадают полностью. А скрам-мастер не похож на руководителя проекта. Лишь команда проекта во всех системах — это участники проекта, которые выполняют какие-то задачи.

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

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

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

Задачи владельца продукта

1. Он фокусируется на вопросе «ЧТО ДОЛЖНО БЫТЬ СДЕЛАНО?» — какие функции нужно реализовать в продукте проекта. Владелец продукта не вмешивается в вопрос «КАК?», потому что этот вопрос — ответственность команды проекта. Если он станет вмешиваться в детали, может пострадать весь проект.

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

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

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

Скрам-мастер

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

Задачи скрам-мастера

1 .Внедряет ценности Agile и практики SCRUM. 2. Помогает команде увидеть препятствия в работе. 3. Занимается развитием команды. Скрам-мастер должен в принципе понимать сильные и слабые стороны каждого участника, предлагать основные принципы и форматы работы, популяризировать приемы и техники работы для повышения производительности команды.

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

Источник: uprav.ru