Файл: Разработка регламента выполнения процесса «Управление информационными ресурсами».pdf

Agile-методологии с каждым годом применяют все больше компаний по всему миру. Компания ScrumTrek проводит ежегодное исследование State of Agile среди организаций по всему миру с целью определения зрелости Agile-практик в компаниях. В 2019 году в исследовании принимали участие респонденты по всему миру: 46% респондентов из компаний, штат сотрудников которых превышает 5000 человек; 18% - из компаний со штатом сотрудников численностью 1000-5000, и 36% - менее 1000 человек (13th annual State of Agile report, 2019). Из респондентов, которые являются сотрудниками компаний, специализирующихся на разработке программного обеспечения, 27% респондентов из компаний, со штатом сотрудников численностью менее 100 человек; 33% - из компаний, в которых от 100 до 1000 сотрудников и 40% из компаний, штат которых превышает 1000 человек (рисунок 1).

По данным ежегодного исследования State of Agile, на сегодняшний день agile-методологии используют 97% респондентов: в 22% из них agile-методологии используются только всеми командами компании; в 26% более чем половиной команд и в 48% компаний менее половины команд применяют agile-практики в своей работе.

Рисунок 1. Распределение респондентов по размеру штата сотрудников организаций

Источник: https://stateofagile.com/#ufh-i-521251909-13th-annual-state-of-agile-report/473508

Наиболее популярным фреймворком является Scrum – его используют 54% респондентов. 32% компаний используют комбинированные методики, состоящие из нескольких различных методологий:

• 8% респондентов используют гибрид Scrum и Kanban (Srcumban);
• 10% респондентов используют гибрид Scrum и XP (Extreme Programming);
• 14% респондентов используют гибрид из нескольких гибких методологий.

В чистом виде методологиями Kanban, Lean и XP пользуются всего 5%, 2% и 1% респондентов, соответственно (рисунок 2).

Рисунок 2. Распределение респондентов по используемым методологиям

Источник: Источник: https://stateofagile.com/#ufh-i-521251909-13th-annual-state-of-agile-report/473508

Наиболее популярными практиками, применяемыми на сегодняшний день в рамках методологий Agile, являются:

• ежедневный standup (daily standup) (86%);
• планирование итерации (sprint planning) (80%);
• ретроспективы (retrospectives) и обзоры (review) итерации (80%)
• использование коротких итераций (67%);
• оценка задач (planning poker/team estimation) (61%);
• kanban (61%);
• планирование релиза (release planning) (57%);
• назначение владельца продукта (product owner) (57%);
• единая команда разработки, включающая специалистов по аналитике, разработке и тестированию (54%);
• частые релизы (50%);
• расположение команды в едином пространстве (45%);
• построение дорожной карты продукта (product roadmapping) (50%).

Диаграмма распределения голосов респондентов относительно используемых agile-практик и инструментов представлена на рисунке 3.

Рисунок 3. Распределение голосов респондентов относительно используемых agile-практик

Источник: Источник: https://stateofagile.com/#ufh-i-521251909-13th-annual-state-of-agile-report/473508

Фреймворк Scrum, который используется более чем в половине опрошенных компаний, является наиболее часто используемой методологией. Фреймворк предполагает процесс разработки продукта при участии одной команды и состоит из ролей, событий, артефактов и правил. Scrum используется как итеративный подход для поставки работающего продукта (The Scrum Guide, 2017).

Scrum-команда включает в себя 3 базовых роли: Product owner, Scrum master и Development team (Команда разработки).

1. Product owner (PO, владелец продукта) – связующее звено между заказчиком и командой разработки. PO владеет бэклогом продукта (Product Backlog) (перечнем пользовательских историй, которые необходимо выполнить в рамках проекта) и несет ответственность за максимизацию ценности продукта.
2. Scrum master (SM) – помогает команде максимизировать эффективность работы путем обучения, мотивации и устранения препятствий; отвечает за соблюдение командой скрам-правил.
3. Команда разработки (Development team, DT) является кроссфункциональной и включает в себя специалистов, которые участвуют в процессе разработки, например, аналитиков, разработчиков, тестировщиков и дизайнеров. Команда должна обладать всеми необходимыми навыками для разработки продукта, за качество продукта отвечает вся команда, а не отдельные ее участники (Rusbase, 2017).

Рабочий процесс в Scrum состоит из следующих событий:

• Sprint (спринт, итерация);
• Sprint Planning (Планирование спринта);
• Daily Scrum (Ежедневный стендап);
• Sprint Review (Анализ спринта);
• Sprint Retrospective (Ретроспектива спринта).

И артефактов:

• Product Backlog (Бэклог продукта);
• Sprint Backlog (Бэклог спринта);
• Increment (Инкременты).

Разработка по Scrum осуществляется итерационно: по окончании итерации (спринта) должна быть реализована новая версия работающего продукта. Длительность Спринта не должна превышать 4 недели (обычно используется длительность 2 недели). Перед началом Спринта производится Планирование спринта (Sprint Planning), на котором из Бэклога продукта (Product Backlog) отбираются пользовательские истории для Бэклога спринта (Sprint Backlog), который представляет собой перечень пользовательских историй, которые необходимо реализовать в рамках Спринта, а также определяются требования к инкременту (Increment) продукта (Definition of Done, DoD), далее Бэклог спринта разбивается на отдельные задачи (Tasks). Каждый день проводится Ежедневный стендап (Daily Scrum), цель которого отследить прогресс в работе во время Спринта.

По окончании Спринта проводятся две встречи:

• Анализ спринта (Sprint Review) – демонстрация версии продукта (Increment) PO и заказчику (и другим заинтересованных лицам) с целью получения обратной связи;
• Ретроспектива спринта (Sprint Retrospective) – обсуждение проблем, возникших в рабочем процессе.

Схема процесса разработки по фреймворку Scrum представлена на рисунке 4.

Рисунок 4. Процесс Scrum

Источник: https://medium.com/@jw207427/how-scrum-help-turn-around-our-development-process-dac6ff7c700

Для оценки задач в Scrum используются Story Points – оценка, которая выставляется элементу бэклога (пользовательской истории, User Story) на основании количества усилий, которые необходимо приложить для ее решения (Cohn, 2016). При оценке учитываются:

• сложность истории;
• объем работ;
• уровень рисков и неопределенности при выполнении работ.

При оценке в Story Points элементу бэклога присваивается некоторое количественное значение, которое показывает относительную сложность реализации между пользовательскими историями. Например, история со значением 1 Story Point должна быть вдвое меньше истории со значением Story Points = 2. Важно, чтобы оценка в Story Points учитывала все работы, которые потребуются для доведения элемента бэклога до состояния готовности (от анализа истории до завершения тестирования).

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

• всей команде раздаются карты с числами из шкалы оценки;
• выбирается история и обсуждаются требования к ней;
• после завершения обсуждения по команде модератора каждому из участников необходимо выбрать карту с числом, соответствующим оценке истории, и положить ее «рубашкой» вверх;
• по команде модератора участники переворачивают карты: если оценки участников близки по значению, оценка согласуется и модератор присваивает ее истории. В противном случае, участники забирают карты обратно и продолжают обсуждение задачи (Habr, 2020).

Фреймворк Kanban. Kanban – гибкий подход к разработке ПО, который обеспечивает прозрачность рабочих процессов и позволяет улучшить процесс разработки. Фреймворк Kanban основывается на принципах системы бережливого производства (Lean), которое предполагает повышение качества продукта при сокращении расходов за счет максимального вовлечения в процесс каждого сотрудника (Agile Practice Guide, 2017).

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

Метод Kanban может быть применен в командах, для которых важны следующие критерии:

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

Kanban предназначен для последовательного процесса, в котором для продвижения работ по этапам процесса используется принцип pull system – при завершении одной работы на этапе команда может взять следующую работу из предыдущего этапа. Ценность несет только завершенная работа, поэтому в методе Kanban цель команды заключается в коллективном завершении всех работ с соблюдением лимитов на объемы незавершенных работ на этапах. Основные принципы и свойства метода представлены на рисунке 5.

Рисунок 5. Принципы и свойства метода Kanban

Источник: Agile Practice Guide, 2017

Для визуализации процесса разработки в гибких методологиях используются доски (Task Board). Доска в agile-методологиях может быть:

• виртуальной (специализированное ПО);
• физической (пробковая доска или флипчарт).

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

• TO DO (необходимо сделать);
• IN PROGRESS (в работе);
• DONE (сделано).

Задачи представляют собой карточки, которые перемещаются между столбцами в зависимости от их статуса: когда команда берет задачу в работу, задача перемещается в столбец IN PROGRESS. После того, как команда завершила работу над задачей, она перемещает соответствующую задачу в столбец DONE (рисунок 6). Чтобы контролировать нагрузку команды, можно устанавливать лимиты на количество задач на каждом из этапов.

Рисунок 6. Kanban-доска

Источник: https://www.patboard.com/shop/full-scrum-kanban-board-kit-nanocups-for-glass/

В Srcum-доске, помимо перечисленных выше столбцов, должен присутствовать столбец, включающий в себя задачи бэклога (BACKLOG). При необходимости, на доске могут быть добавлены дополнительные столбцы, например: бэклог текущего спринта – SPRINT и тестирование – TESTING/VERIFY (рисунок 7).

Рисунок 7. Scrum-доска

Источник: https://www.patboard.com/shop/full-scrum-kanban-board-kit-nanocups-for-glass/

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

Для визуализации прогресса выполнения работ в гибких методологиях используются диаграммы:

• Burndown Chart (диаграмма сгорания);
• Burnup Chart (диаграмма сгорания наоборот).

Диаграмма Burndown Chart показывает на временной шкале, сколько Story Points осталось выполнить до завершения спринта и сколько Story Points уже выполнено: по оси X указывается время, по оси Y – количество невыполненных задач в Story Points (Scrum Time, 2020). Цель команды – выполнить («сжечь») все Story Points до конца Спринта.

На графике присутствуют две кривые:

• идеальная (планируемая) кривая: строится на предположении, что задачи выполняются с постоянной скоростью в N Story Points в день;
• фактическая кривая: визуализирует реально выполненное количество Story Points за каждый день (рисунок 8).

Рисунок 8. Burndown Chart

Источник: https://www.projectmanagement.com/blog-post/40731/Burndown-vs-Burnup-Chart

Диаграмма Burnup Chart показывает на временной шкале, сколько Story Points уже выполнено: по оси X указывается время, по оси Y – количество выполненных задач в Story Points.

На графике присутствуют две кривые:

• идеальная (планируемая) кривая: строится на предположении, что задачи выполняются с постоянной скоростью в N Story Points в день;
• фактическая кривая: визуализирует реально выполненное количество Story Points за каждый день (рисунок 9).

Рисунок 9. Burnup Chart

Источник: https://www.projectmanagement.com/blog-post/40731/Burndown-vs-Burnup-Chart

Верхняя граница отмечается кривой Scope («Все задачи»), фактическая кривая достигает кривой Scope в тот момент, когда все задачи спринта выполнены.

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