Scrum что это такое

02.01.202408.09.2023 admin 0 Comments

Будь гибким: как понять Scrum и создать agile-команду

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

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

Как и зачем появилась Scrum-методология

До появления Scrum в мире разработки программного обеспечения было принято использовать «водопадный подход». Работа над продуктом велась по следующему плану.

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

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

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

Манифест гибкой разработки ПО

1. Люди важнее инструментов.
2. Качество продукта важнее документации.
3. Взаимодействие с заказчиком важнее контракта.
4. Готовность к изменениям важнее установленного плана.

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

12 принципов Agile

1. Главное — хорошее ПО и довольный заказчик.
2. Готовность к изменениям в любой момент.
3. Полностью рабочее ПО — как можно чаще.
4. Встреча команды — лучше всего для обмена информацией.
5. Заказчик и команда разработки должны работать вместе.
6. Доверять людям делать свою работу.
7. Есть рабочее ПО — есть прогресс.
8. Гибкие процессы — непрерывное развитие.
9. Внимание к качеству способствует гибкости.
10. Простота процесса позволяет не делать лишней работы.
11. Самоорганизующаяся команда лучше работает.
12. Постоянное стремление к большей эффективности.

Одна из методологий гибкого процесса разработки программного обеспечения, которая базируется на agile-принципах, — Scrum.

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

Принципы Scrum

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

Работа короткими циклами (спринтами)

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

Гибкость. «Проверять и адаптироваться»

Гибкость процесса и тестирование продукта после каждого спринта. Если что-то идёт не так, команда всегда готова сменить стратегию разработки или пересмотреть бэклог продукта.

Участие заказчика и пользователей в создании продукта

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

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

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

О важности scrum-команды

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

Состав команды

Принципы работы scrum-команды

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

Совершенствование продукта за счёт самосовершенствования сотрудника.

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

Каждая команда самодостаточна, так как в ней собраны люди с разными навыками.

Процесс работы scrum-команды

Процесс работы scrum-команды проходит в несколько обязательных этапов.

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

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

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

Задача scrum-мастера — понять, если что-то идёт не так, и помочь команде справиться с трудностями.

Scrum-команда вешает в помещении для совещаний доску с разноцветными стикерами. Она делится на части, где отражается весь процесс работы над проектом. Тут могут быть варианты, но обязательно присутствуют три части. Первая — «Что нужно сделать», вторая — «В работе», третья — «Сделано». Этот простой способ помогает всем членам команды следить за общим ходом работы.

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

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

Как внедрить scrum-методологию

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

Кажется, что всё просто. Нужны несколько последовательных действий.

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

2. Назначить владельца продукта

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

3. Выбрать scrum-мастера

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

4. Создать список требований к продукту

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

5. Спланировать спринт

Разделить всю работу на периоды. Планировать каждый спринт. Не весь процесс разработки сразу, а только ближайший цикл.

6. Постоянно анализировать и оценивать результат

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

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

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

Пишет про управление в Skillbox. Работала координатором проектов в Русском музее, писала для блога агентства CRM-маркетинга Out of Cloud.

Упорядоченный список задач, над которыми scrum-команда работает при создании продукта.

Источник

SCRUM: стоит ли прогибаться под изменчивый мир?

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

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

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

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

На основе выводов, сделанных по результатам долгих наблюдений, вывели «Манифест гибкой разработки программного обеспечения». В него включили четыре пункта:

В 2001 году они детально описали принципы своей методологии и выпустили книгу «Agile Software Development with SCRUM». На сегодняшний день этот подход считается одним из самых популярных среди разработчиков.

Базовые принципы Scrum

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

Базовые принципы Scrum:

Scrum-команда

Scrum-команда в большинстве случае состоит из 5-9 человек, реже — из 3-4. В рамках скрама коллектив не может быть больше, потому что усложняется взаимодействие между каждым звеном, что негативно сказывается на эффективности работы.
Состав

В команде есть три основные роли:

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

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

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

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

Примерный перечень обязанностей владельца:

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

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

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

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

Примерный перечень обязанностей скрам-мастера:

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

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

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

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

Примерный перечень команды разработчиков:

Принципы работы Scrum-команды

Успешная работа по методологии Scrum возможна при соблюдении трех принципов:

Процесс работы Scrum-команды

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

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

После этого на основе бэклога оговаривается объем работ и длительность цикла. Также заранее определяют результат: что должны получить по итогам спринта.

2. Проведение регулярных совещаний. Ежедневно или еженедельно команда проводит короткие совещания (не более 15-30 минут). В них участвуют владелец продукта, скрам-мастер и все разработчики. Цель встреч — получить от каждого ответы на три вопроса:

3. Организация скрам-доски. В конференц-зале, где проводятся регулярные совещания, вешается доска, разделенная на три части: «что нужно сделать», «в работе» и «сделано».

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

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

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

5. Подведение итогов. После завершения каждого спринта проводится тестирование выполненной части программного обеспечения. В нем также принимают участие потенциальные потребители (фокус-группа). Владелец собирает обратную связь и принимает решения для успешной работы в дальнейшем.

Артефакты Scrum

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

Журнал продукта

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

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

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

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

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

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

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

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

График спринта

График спринта — это расписанный задачами календарь работы в рамках текущей итерации. В нем отображается оставшийся до конца спринта объем работы. Команда регулярно оценивает график и при необходимости оперативно реагирует на какие-либо изменения.

Особое внимание календарю уделяет владелец продукта. По нему оценивается скорость работы и соблюдение дедлайнов. Например, если со временем объем работы не уменьшается, значит, в процессе есть какие-то отклонения и требуется срочная корректировка действий команды.

Как правильно внедрить Scrum-методологию

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

Если вы решились на изменения, проводите внедрение поэтапно:

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

Подведем итоги

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

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

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

Источник

SCRUM: Понимание и применение фреймворка

После заморозки стартапа (более подробно можно ознакомиться в статье) компания заинтересовалась возможностью трансформации существующего производства, включающего 400 сотрудников, работающих в 6 продуктовых направлениях. Этой публикацией, я запускаю цикл статей, в которых попытаюсь предложить формализованный подход по оценке степени зрелости аспектов разработки для внедрения SCRUM.

Для решения этой сложной задачи была предложена программа, которая включает в себя 4 этапа:

Оценка готовности производственных подразделений к трансформации.

Разработка этапов трансформации.

Разработка механизмов трансформации.

Разработка ценностной модели обоснования трансформации.

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

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

Философия эмпиризма

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

Характеристика

Метод исследования

Метрика

Наблюдение за инструментами фиксации проблем (JIRA).

Отсутствует декомпозиция — 0 баллов.

1 уровень декомпозиции — 1 балл.

2 уровня декомпозиции — 3 балла.

3 уровня декомпозиции — 5 баллов.

Опрос респондентов: «Как вы относитесь к проблеме?»

Проблема — негативное событие и его нельзя допускать — 0 баллов.

Проблема — явление, к которому я уже привык — 3 балла.

Проблема — возможность для роста и изучения нового — 5 баллов.

Наблюдение за реакцией сотрудников с руководящей функцией при возникновении проблемы.

Негативная реакция со стороны руководителя — 0 баллов.

Позитивная реакция со стороны руководителя — 5 баллов.

Наблюдение за реакцией сотрудников при возникновении проблемы.

Негативная реакция со стороны сотрудника — 0 баллов.

Позитивная реакция со стороны руководителя — 5 баллов.

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

Культурные ценности

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

Характеристика

Метод исследования

Метрика

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

Работа появляется спонтанно вне определённого контекста — 0 баллов.

Вся работа запланирована и выполняется в контексте спринта — 5 баллов.

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

Стейкхолдеры практикуют неконструктивную обратную связь (обвинение, унижение) — 0 баллов.

Стейкхолдеры проявляют лояльность в отношении работ и дают обратную связь в конструктивном ключе — 5 баллов.

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

У частников ярко выражена модель ассоциации проблемы с индивидуальными способностями сотрудников — 0 баллов.

Участники с пониманием относятся к ограниченности как своих знаний, так и окружающих их людей; с желанием делятся опытом с коллегами — 5 баллов.

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

Участники настороженно относятся к сложным задачам, которые вызывают отторжение — 0 баллов.

Участники с вызовом относятся к сложным проблемам и расценивают их как возможность сделать очередную запись успеха — 5 баллов.

Наблюдение за персональной приверженностью сотрудников в части достижения целей спринта.

Сотрудники не ощущают зоны ответственности, нет понимания собственного вклада — 0 баллов.

Сотрудники ощущают персональную ответственность перед командой и продуктом; есть также понимание собственного вклада — 5 баллов.

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

Команда как функциональная единица

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

Характеристика

Метод исследования

Метрика

Наблюдение за принципами организации групп и наличие сущности «команда».

Отсутствует понятие команды — 0 баллов.

Команда образована по функциональному признаку — 1 балл.

Самоорганизация команды по предметному признаку — 3 балла.

Команда образована по предметному признаку (направление) — 5 баллов.

Наблюдение за наличием функций:

— развитие продуктовой команды;
— поддержка среды с культурными ценностями;
— поддержка среды в рамках фреймворка SCRUM;
— мотивация продуктовой команды;
— применение модели «менеджер — слуга»;
— организация производства;
— решение внутренних и внешних конфликтов.

Роль отсутствует, функции роли отсутствуют — 0 баллов.

Роль отсутствует, функции роли присутствуют — 1 балл.

Роль присутствует, функции роли отсутствуют — 3 балла.

Роль присутствует, функции роли присутствуют — 5 баллов.

Наблюдение за наличием функций:

— разработка дорожной карты продукта;
— управление продуктовым бэклогом;
— планирование и развитие продукта;
— проведение демонстрации продукта;
— проведение ежедневных стендапов;
— разработка бизнес-гипотез.

Роль отсутствует, функции роли отсутствуют — 0 баллов.

Роль отсутствует, функции роли присутствуют — 1 балл.

Роль присутствует, функции роли отсутствуют — 3 балла.

Роль присутствует, функции роли присутствуют — 5 баллов.

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

Роль включает в себя только компетенции программирования — 0 баллов.

Роль включает в себя все необходимые компетенции для поставки версии продукта — 5 баллов.

0–13 баллов — низкий результат, характеризующий отсутствие команды в качестве производственной единицы признанной на уровне организации. Необходимо разработать комплексную программу мероприятий для выделения и формирования команды в контексте организационных уровней компании. Не допускается проводить мероприятия для отдельно взятых характеристик за рамками комплексной программы.

14–16 баллов — средний результат, характеризующий наличие команды как класса, но существуют определённые ограничения для полного раскрытия потенциала. Необходимо определить проблемные характеристики для улучшения и разработать мероприятия. Допускается применение мероприятий без общей программы.

17–20 баллов — высокий результат, характеризующий наличие самодостаточной организационной единицы производства инкремента продукта, признанной на уровне организации. При данном результате, рекомендуется сделать акцент на мероприятиях направленные на управление продуктом, непрерывное обеспечение качества и CI/CD, как вектор роста команды.

События

События представляют из себя правила коммуникаций в разрезе следующих вопросов:

кто должен коммуницировать?

когда должен коммуницировать?

с какой целью должен коммуницировать?

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

Характеристика

Метод исследования

Метрика

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

Событие отсутствует — 0 баллов.

Присутствует событие с фиксированной периодичностью (2–4 недели) — 5 баллов.

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

Событие отсутствует — 0 баллов.

Событие проходит каждый день и несколько раз — 1 балл.

Событие фиксировано по времени, проходит каждый день и больше 15 минут — 3 балла.

Событие фиксировано по времени, проходит каждый день и ограничено 15 минутам — 5 баллов.

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

Событие отсутствует — 0 баллов.

Событие не имеет ритмичности и происходит хаотично — 1 балл.

Событие имеет ритмичность, но не ограничено по времени — 3 балла.

Событие имеет ритмичность и ограничено по времени (4 часа—2-х недельный спринт) — 5 баллов.

Наблюдение за событием, на котором происходит демонстрация работоспособного инкремента стейкхолдерам.

Событие отсутствует — 0 баллов.

Событие не имеет ритмичности и происходит хаотично — 1 балл.

Событие имеет ритмичность, но не ограничено по времени — 3 балла.

Событие имеет ритмичность и ограничено по времени (2 часа–2-х недельный спринт) — 5 баллов.

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

Событие отсутствует — 0 баллов.

Событие не имеет ритмичности и происходит хаотично — 1 балл.

Событие имеет ритмичность, но не ограничено по времени — 3 балла.

Событие имеет ритмичность и ограничено по времени (2 часа–2-х недельный спринт) — 5 баллов.

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

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

21–25 баллов — высокий результат, характеризующий наличие эффективно выстроенных коммуникаций и ритмичные процессы производства продукта. При данном результате, рекомендуется сделать акцент на характеристике «критерии завершённости» в качестве точки роста компетенций команды и качества выпускаемого инкремента.

Артефакты

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

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

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

Инкремент — протестированная и работоспособная версия с добавочной ценностью для клиента, которая соответствует критериям завершённости.

Характеристика

Метод исследования

Метрика

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

Бэклог продукта отсутствует — 0 баллов.

Бэклог продукта имеет вид разбросанных задач — 1 балл.

Бэклог имеет вид отфильтрованного списка по предмету — 3 балла.

Бэклог единое место хранения всех задач по продукту — 5 баллов.

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

Бэклог спринта отсутствует — 0 баллов.

Бэклог спринта имеет вид разбросанных задач — 1 балл.

Бэклог имеет вид отфильтрованного списка по предмету — 3 балла.

Бэклог единое место хранения всех задач по спринту — 5 баллов.

Наблюдение за фактом выпуска протестированной и работоспособной версии продукта.

Понятие инкремента отсутствует — 0 баллов.

Понятие инкремента присутствует, но выпуск работоспособной версии не происходит по факту окончания спринта — 1 балла.

Понятие инкремента отсутствует, но выпуск работоспособной версии происходит по факту окончания спринта — 3 балла.

Понятие инкремента присутствует, триггером появления служит спринт — 5 баллов.

0–9 баллов — низкий результат, характеризующий сложность существующих подходов в части управления и планирования содержанием работ. Данная сложность может быть причиной увеличения времени ожидания ответа на запрос внутри команды, а также причиной низкой концентрацией на актуальных задачах.

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

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

Критерии завершённости

Список критериев завершённости (далее DoD, от английского definition of done) является формальным чек-листом для принятия решения о выпуске инкремента. Критерии определяются стандартами организации. Если они отсутствуют, то команда должна определить список DoD. По мере развития команды список критериев завершённости будет развиваться параллельно улучшению качества выпускаемого инкремента.

Характеристика

Метод исследования

Метрика

Наличие списка DoD

Наблюдение за существованием списка критериев завершённости и его использование для выпуска инкремента.

DoD отсутствует — 0 баллов.

DoD отсутствует, существуют разбросанные критерии — 1 балл.

DoD присутствует, инкремент выпускается без соответствия критериям — 3 балла.

DoD присутствует, инкремент выпускается при соответствии критериям — 5 баллов.

Наблюдение за наличием критерия, который характеризует отсутствие уязвимостей в исходном коде.