Scrum что это в бизнесе

06.10.202305.07.2022 admin 0 Comments

Мини-справочник и руководство по Scrum

Данная статья – это мини-справочник и руководство по методу Scrum, созданные в результате прочтения книги Сазерленда, статей из интернета и применения на практике.

Надо различать Agile и Scrum. Agile – это методология (наука), а Scrum – это метод достижения цели.

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

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

Счастливые люди успешнее на 50%. А значит они на 50% более продуктивные, если счастливы и находят смысл в своей работе. При этом они на 88% более лояльны, потому что понимают, что работают не зря, посвящая половину своего времени развитию этого бизнеса

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

Мини-справочник Scrum

Scrum (скрам) – схватка, гибкий метод управления проектами. Термин пришел из игры рэгби.

Product Owner (продакт оунэр) – владелец продукта, связующее звено между заказчиком и командой разработки. Самая главная ответственность Product Owner – это создание и контроль Product Backlog.

Основные обязанности и ответственность Product Owner при управлении Product Backlog:

Scrum Master (скрам мастер) – арбитр, который организует и проводит совещания, следит за соблюдением всех принципов скрама, разрешает противоречия и защищает команду от отвлекающих факторов, проводит фасилитацию митингов, отвечает за учет, хранение и выдачу SCRUM-инвентаря. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса.

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

Development Team (дэвэлопмэнт тим) – команда разработки, кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: программистов, тестировщиков, аналитиков, архитекторов и т.д. Размер команды составляет от 5 до 9 человек (5 оптимально). Команда является единственным полностью вовлеченным участником разработки и отвечает за результат как единое целое. Данная рабочая единица является самодостаточной, самоуправляемой и самоорганизующейся. Это как некий единый организм, состоящий из отдельных элементов.

Stakeholders (стэкхолдэрс) – дословно акционеры, лица, которые инициируют проект (бизнес-заказчики), которым скрам-проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review).

User – пользователь продукта.

Product Backlog (продакт бэклог) – или Backlog требования к продукту, пожелания заказчика по функционалу и дизайну, все «хотелки»; они расставляются по степени важности и ценности для заказчика.

Epic (эпик) – одна из нескольких глобальных функций продукта. В эпике могут содержаться User Story, например, пакет пожеланий одного пользователя или список задач (Task) для реализации Эпика.

User Story (юзер стори) – или Story, cюжет, в которых содержатся пожелания пользователя.

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

Sprint (спринт) – временной промежуток от 1 до 4 недель, за который команда создает часть продукта, готовую к демонстрации и ценную для заказчика. Оптимальная продолжительность спринта – 1-2 недели. Это делается для того, чтобы информация, полученная в начале первой недели, не забылась к концу второй недели и не требовалось время на восстановление связей.

Sprint Goal (спринт гоол) – цель спринта.

Sprint Planning Meeting (спринт плэнин митин) – планирование Sprint, скрам-собрание, где участвует Scrum Team. Выбираются задания из Бэклога, которые возможно выполнить за спринт.

Scrum Poker (скрам покэ) – быстрый и точный способ сбора оценок при помощи колоды карт с числами Фибоначчи (1,2,3,5,8,13). Можно использовать мобильные приложения для Scrum Poker. Задачи с оценкой 13 необходимо дробить на более мелкие.

Story Points (стори поинтc) – единица оценки сложности выполнения задачи. Story Points имеет смысл применять, если проект состоит из 3-х и более спринтов, так как у команды накапливается статистика и опыт оценивания задач. На проекте из одного-двух спринтов использовать Story Points нет смысла, если только не для получения практики.

Daily Scrum Meeting (дэйли скрам митин) – ежедневное собрание не более 15 минут, проводимое в одно и то же время. Участвует скрам тим, наблюдать могут все. Проводит скрам-мастер. Цель митинга – оперативный обмен информацией, все в курсе происходящего, нет коммуникационных разрывов. Задаются три вопроса: что сделал вчера? что будешь делать сегодня? какие препятствия встают на пути к цели?

Sprint Review (спринт ревью) – обзор спринта, участвуют все, встреча открытая. Команда рассказывает, что было сделано, и демонстрирует те части проекта, которые окончательно готовы.

Sprint Retrospective Meeting (спринт рэтроспэктив митин) – ретроспектива, участвует скрам тим. Собрание за «круглым» столом. Обсуждаются вопросы: что прошло хорошо, а что плохо? что можно было сделать лучше? Главное, никого не обличать! Рассматривается рабочий процесс. Цель – совершенствование рабочего процесса, стать «супер» командой.

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

Velocity (велосити) – скорость команды; для аналитики строится график Velocity, где по оси Х кол-во спринтов, а по оси Y Story Points.На основе этих показателей выстраиваются средние Velocity и Story Points.

Burndown Chart (бёрдаун чарт) – диаграмма сгорания задач. Направление графика сверху вниз. Предназначен для отслеживания оставшегося объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Первому дню спринта соответствует максимальное кол-во Story Points.

Burnup Chart (бёрнап чарт) – диаграмма сгорания задач. Направление графика снизу вверх. Предназначен для отслеживания объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Последнему дню спринта соответствует максимальное кол-во Story Points.

Abnormal Termination (Абнормол тёрминэйшн) – остановка спринта, аномальное действие. Остановку инициирует Product Owner. Происходит митинг, на котором обсуждаются причины возникновения Abnormal Termination. Затем Спринт запускается вновь.

Руководство Scrum

Product Backlog
Формируется при общей встрече или индивидуальных интервью со всеми заинтересованными лицами (стэкхолдерами, пользователями). Записываются User Story, требования и пожелания.

Задачи с компонентами типа: 3IIIC, 5VE сложнее и требуют больше времени.

123, ABC – быстрее, потому что мозгу не надо переключаться между разными типами задач.

User Story

Происходит совместно с Development team. Команда должна оценить каждую задачу: выполнима ли она в принципе? достаточно ли информации для выполнения?

Формируется Sprint. Sprint Planning Meeting. Scrum Poker

Продолжительность митинга не более 8 часов. Для 2-x недельного спринта митинг длится 2 часа. Для визуализации исполнения задач в спринте удобно использовать Kanban-доску.

Расставление Story Points (за основу взят ряд Фибоначчи – 1,2,3,5,8,13). Задачи 13 и более поинтов необходимо дробить на более мелкие. Срок выполнения задачи одним разработчиком не более одного дня или 8 часов. Если в проекте всего один спринт, то нет смысла расставлять Story Points, потому что не будет статистики и соответственно не будет точности определения оценок.
Для корректного присвоения Story Points можно вести статистику, как, например, в такой таблице:

Проводится каждый день. Все могут наблюдать. Говорит только Scrum Team. Проводит Scrum Master.

Участвуют все. Знаменуется значительным приростом функционала продукта. Демонстрация работы готового продукта или функционала.

Длительность митинга: по одному часу на каждую неделю спринта (2 часа Sprint Review = 2-х недельному спринту).Подготовка к данной встрече не должна превышать 2-х часов.

Sprint Retrospective Meeting. Ретроспектива.

Проводится в последний день спринта.

Призвана оценить результат команды. Задаются вопросы: что можно улучшить? как? как повысить эффективность команды?
Время на ретроспективу для 2-х недельного спринта не более 2-х часов.
Понятие Кайдзен и счастье. Кайдзен – непрерывное совершенствование. Счастливые люди = высокая производительность команды.

Можно задать вопросы: Что может сделать вас счастливее в следующем спринте? Что сделает вас счастливее вообще?

Источник

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 баллов.

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