Agile/Scrume/Kanban как выравнивать процессы, максимизировать процессы

Материал подготовлен в рамках обучения Product University, январь, 2021

Для начала определим кто такой менеджер?

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

С чем это связано?

Менеджер должен уметь правильно ставить задачи команде, следить за результатами поставками, он также должен знать основы Agile, Scrume, Kanban. Чтобы иметь представления как работать с командой.

Что такое Agile?

Agile (agile software development, от англ. agile – проворный, шустрый, сообразительный) – это семейство «гибких» подходов к разработке ПО.

А теперь простыми словами, некоторые считают что Agile это методология, но любой опытный Product Manager скажет Вам что Agile это способ мышления он не включает практики, а определяет принципы и ценности это некая философия, которыми руководствуется команда.

Подход к проектам по разработке ПО

• Гибкая методология разработки,

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

• Короткие горизонты планирования (1-2 мес.)

• Реализация внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля

• Каждый участник процесса «конвейерной сборки» вовлекается в процесс переосмысления своих задач и общего дела; каждый может вносить изменения и даже остановить разработку

Agile Manifesto - основной документ, содержащий описание ценностей и принципов гибкой

1. Люди и взаимодействие важнее процессов и инструментов;

2. Работающий продукт важнее исчерпывающей документации;

3. Сотрудничество с заказчиком важнее согласования условий контракта;

4. Готовность к изменениям важнее следования первоначальному плану.

Таким образом, не отрицая важности того, что справа, всё-таки больше ценится то, что слева.

Особенность реализации проектов

• Фиксированы срок и стоимость проекта.

• Лучший контроль качества – контроль результата каждой итерации

• Отсутствует конечный скоуп проекта - нет четко описанного результата

Что такое Scrum?

Scrum (в переводе с англ: схватка, потасовка, толпа) — методология управления проектами, применяется при необходимости гибкой разработки; методология делает акцент на качественном контроле процесса разработки

Scrum – самая популярная из гибких методологий разработки

Позволяет решать задачи

• меньшими силами

• в сжатые сроки

• с минимальными затратами.

РЕЗУЛЬТАТ КАЖДЫЕ 2 НЕДЕЛИ!

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

В Scrum задачи принято оценивать в Story points или в часах. Без оценки не получится сформировать спринт: ведь нам нужно знать, успеем ли мы сделать задачи за 2 недели. Через 2 недели мы получаем ценную статистику — сколько часов или Story points команда смогла сделать за спринт.

Velocity — это производительность команды за один спринт. Этот параметр позволяет Scrum менеджеру предсказать, где команда будет через 2 недели.

Перед началом спринта команда сама формирует список задач на итерацию, далее запускается спринт.

ОЧЕНЬ ВАЖНА РОЛЬ ВЛАДЕЛЬЦА ПРОДУКТА, который постоянно участвует в проекте, понимает, что должно быть достигнуто, оценивает все риски и выгоды.

По методологии Scrum, оптимальной является группа из 5-9 ЧЕЛОВЕК.

Как максимизировать и выравнивать процессы?

На самом деле здесь уже все продумано, и придумать велосипед не нужно!

Используется всего четыре артефакта:

• Product Backlog
• Sprint Backlog
• Sprint Goal
• Sprint Burndown Chart.

Sprint backlog

Sprint Backlog – это обязательство команды: что они должны выполнить за ближайшие 2 недели. Каждое требование разделено на задачи, которые представлены на доске.

Sprint Goal

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

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

Sprint Burndown Chart

• диаграмма сгорания
• в качестве “сгорающих” элементов выступают человеко-часы или идеальные единицы (Story Points).
• диаграмма обновляется каждый раз, когда завершается какая-либо задача.

Ритуалы

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

Ритуалы в скрам это:

• Sprint Planning Meeting
• Daily Meeting
• Sprint Review
• Retrospective

Sprint Planning Meeting (встреча по планированию спринта)

• выполняется всей командой перед началом спринта
• команда выбирает требования из Product Backlog и формирует Sprint Backlog
• если требуется учесть взаимосвязи между операциями, то это делается здесь
• команда декомпозирует требования на задачи (tasks)
• каждая задача проходит оценку в трудозатратах или универсальных единицах
• во время встречи Product Owner отвечает на вопросы команды.

Daily Meeting (ежедневная встреча команды).

Основные принципы:

• проходит ежедневно и только в одно и то же время;
• встречи не более 15 минут;
• чтобы успеть каждый должен ответить всего на 3 вопроса: что я сделал вчера, чем я занимаюсь сегодня, какие есть проблемы?

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

Sprint Review – сдача спринта Product Owner

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

Ценность Scrum для обычного заказчика во многом состоит в том, что результат работ (плохой или отличный, не важно) будет продемонстрирован в любом случае. Это знает и команда и Product Owner и другие заинтересованные лица. Если команда не проводит демонстрацию (иное название Sprint Review), то это дискредитирует все преимущества гибких процессов.

Структура встречи:

• команда зачитывает требования из Sprint Backlog
• по каждому критерию приемки происходит демонстрация полученных результатов
• каждый вопрос со стороны Product Owner’а записывается, чтобы иметь возможность ответить на них позже
• каждое новое требование Product Owner’a выписывается, чтобы позже включить его в Product Backlog.

Retrospective

Ритуал, который направлен на обмен опытом внутри команды. Встреча проводится после Sprint Review. На встрече присутствует вся команда и Scrum Master. На встрече может присутствовать Produt Owner, если считает нужным.

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

• какие решения должна принять команда, чтобы сделать процесс более предсказуемым?
• какие проблемы мешают команде выполнять взятые на себя обязательства?
• как улучшить взаимодействие с Product Owner’ом?
• какие ошибки совершает команда и почему.

Kanban

Kanban, это система управления бережливыми производством (перевод с японского: «сигнал»/«карточка»), которая использует информационные карточки для передачи заказа на всех этапах изготовления. Простыми словами, мы отслеживаем весь путь продукта, от идеи до выхода “на полку магазина”.

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

Kanban используют для реализации проектов.

Kanban дает больше гибкости, если под гибкостью понимать частоту смены приоритетов. Если вчера разработчик залил выполненную задачу, а сегодня получили данные с "передовой" и узнали, что вот эта штука не работает так, как было задумано, то дают новые требования. Дополненные новые задачи поднимаются вверх и программист берет эту задачу «сверху», выполняет ее и, к вечеру все работает как надо. Все счастливы и эффективны как никогда.

В Канбан «скорость работы команды» отсутствует и считается только среднее время на полную реализацию задачи

Карточки, на которых указаны информация о сроках выполнения, описание или номер процесса и имя исполнителя, прикрепляются , к доске с расчерченными колонками:

Бэклог — задачи, которые надо выполнить

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

Задачи, которые выполнены, но еще не переданные тестировщикам

Задачи, готовы к передаче отделу тестирования

Задачи, которые проходят проверку проект-менеджером (ПМ)

Выполненные задачи

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

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

4 базовых принципа «Kanban»

1) Отталкивайтесь от того, что у вас есть сейчас

2) Стремиться к поэтапным, постоянным и эволюционным изменениям

3) Уважайте поточные процессы и роли

4) Поддерживать лидерство на всех уровнях

Почему важно визуализировать?

Kanban — это в первую очередь визуализация

- Визуальное отображение задач. Все задачи должны быть представлены в виде карточек и отражены на доске.

- Фокус на невыполненных задачах

- Постоянное улучшение

- Уделяйте внимание мелочам

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

Kanban имеет и недостатки:

Система плохо работает с командами численностью более 5 человек

Он не предназначен для долгосрочного планирования.

В Kanban не принято делать оценку. Это опционально, команда решает сама. Здесь нет понятия «скорость работы команды», считается только среднее время на задачу. Время это считается с помощью специального отчета — Cycle Time.

Cycle Time для задачи = время выполнения задачи минус время начала работы над задачей

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

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

Возможность изменять ход производства / разработки.