Основные практические приемы применения теории массового обслуживания в гибкой разработке программных средств (Scrum)

Реферат к лекции 12 Понятие исполнительного устройства и очереди в системе массового обслуживания

Выполнил: Еремин Илья, ИДБ-18-07

Проверил: Чернат Николай, ИДБ-18-07

Глоссарий

Термин	Перевод	Определение
Scrum	Скрам	Итеративный процесс разработки программного обеспечения: для программного продукта создается много последовательных выпусков, в которых постепенно добавляется требуемая функциональность
Increment	Инкремент	Готовая к использованию часть продукта, которая должна быть реализована к завершению спринта
Sprint	Спринт	Короткий временной интервал, в течение которого Scrum-команда выполняет заданный объем работы
Sprint Planning	Планирование Спринта	Встреча Scrum-команды, на которой происходит планирование работы на следующий Sprint
Daily Scrum	Ежедневный Скрам	Встреча, которая длится не более пятнадцати минут и проводится каждый рабочий день в одном и том же месте в одно и то же время
Sprint Review	Обзор Спринта	Встреча, которая проводится в конце Спринта, чтобы клиенты и заинтересованные лица провели инспекцию Инкремента и дали обратную связь по нему, а Scrum-команда, при необходимости, сделала адаптацию Project backlog
Sprint Retrospective	Ретроспектива Спринта	Встреча, которая дает возможность Scrum-команде провести инспекцию своей работы и создать план улучшений на следующий Sprint
Project backlog	Бэклог проекта	Перечень пользовательских историй (user story), упорядоченный по приоритету и порядку реализации
Sprint backlog	Бэклог спринта	Перечень требований, выбранных Scrum-командой из бэклога проекта с учетом приоритета, оценок трудозатрат, ресурсов команды и длительности Спринта
Каденция	Петля обратной связи	Регулярная встреча для обсуждения движения по проектам

Scrum

У каждого Scrum-проекта есть владелец продукта, Scrum-мастер и команда. Проект можно назвать эффективным, когда Scrum-мастер, владелец продукта и команда начинают работать вместе, а не врозь, – это начинает походить на Scrum-проект.

Основой Scrum является Sprint, в течении которого выполняется работа над продуктом. Sprint ограничен по времени (1-4 недели) и имеет фиксированную продолжительность. По окончанию Sprint’а должна быть получена новая рабочая версия продукта, которую представляют на демо-встречах.

Перед началом каждого Sprint производится Sprint Planning, на котором производится оценка содержимого Project Backlog и формирование Sprint Backlog. Каждый Sprint должен иметь цель, которая достигается с помощью выполнения задач из Sprint Backlog.

Каждый день производится Daily Scrum, на котором каждый член команды отвечает на вопросы «что я сделал вчера?», «что я планирую сделать сегодня?», «какие препятствия на своей работе я встретил?». Задача Daily Scrum — определение статуса и прогресса работы над Sprint, раннее обнаружение возникших препятствий, выработка решений по изменению стратегии, необходимых для достижения целей Sprint'а.

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

Итак, неотъемлемыми элементами Scrum являются планирование, Sprint'ы, ретроспективы. Для ускорения выполнения этих процедур необходимо использовать инструменты.

Инструменты Scrum

Project backlog

Project backlog содержит перечень пользовательских историй (user story), упорядоченный по приоритету и порядку реализации. Ответственный за ведение Project backlog — владелец продукта Scrum.

Sprint backlog

Sprint backlog содержит перечень требований, выбранных Scrum-командой из Project backlog с учетом приоритета, оценок трудозатрат, ресурсов команды и длительности Sprint'а.

Scrum-доска

Scrum-доска — это инструмент открытой демонстрации состояния текущей работы Scrum-команды. Scrum-доска состоит из трёх колонок: «сделать» (To-do), «в процессе» (In progress), «сделано» (Done).

На Scrum-доске размещается весь бэклог текущего Sprint’а. Обычно карточки пользовательских историй располагаются на доске сверху вниз в порядке убывания приоритета. Допускается декомпозиция пользовательских историй на задачи (технические, функциональные, организационные).

Карточки пользовательских историй и задач, передвигаются по доске из колонки в колонку, в соответствии с тем, как команда берёт их на исполнение (In Progress), и завершает (Done). Для обеспечения видимости прогресса работы команды «убывание работы» по дням, отображается на Burndown Chart’е.

Burndown chart

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

Канбан

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

Соответственно, Канбан – это не методология для разработки программного обеспечения и не система управления проектами.

Инструменты Канбана

Каденции

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

Выделяют всего 7 канденций в системе:

1. Ежедневные митинги для обсуждения статуса заблокированных работ.
2. Встреча для получения новых работ и обязательств. Проводится один раз в две недели. На ней определяются обязательства по работам как предоставление качественного сервиса для клиента.
3. Встреча для планирования поставки. Проводится раз в две недели. На ней возвращаются взятые обязательства.
4. Встреча для обсуждения качества предоставляемых услуг. Проводится раз в две недели. На ней осуждаются качественные и количественные показатели сервиса и возможности для его улучшения.
5. Операционная встреча. Проводится раз в месяц. На ней обсуждаются качественные характеристики взаимодействия разных отделов сервиса.
6. Встреча – обзор возможных рисков. Проводится ежемесячно. На ней обсуждаются возникновения возможных рисков от заблокированных работ для предоставления качественного сервиса.
7. Стратегическая встреча. Проводится раз в квартал. На ней обсуждаются стратегии развития.

Канбан-доска

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

• канбан-доски содержат только истории и не показывают задачи;

• столбцы в канбан-досках обычно могут быть разными у различных команд;

• на канбан-досках могут устанавливаться лимиты на объем работ в колонке.

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

Улучшение процесса при помощи Канбана

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

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

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

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

Выявленные неравномерности исправляются с помощью установки жестких ограничений на количество незавершенных работ на соответствующих этапах разработки (limit work in progress, WIP-лимит).

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

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

Эффективный инструмент измерения потока – кумулятивная диаграмма потока (cumulative flow diagram, CFD).

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

На основе стабильности CFD можно сделать вывод об эффективности применения WIP-лимитов, и, если необходимо, изменить их. Идеальная CFD – когда не существует скачков. В этом случае поток стабилен.

Источники:

1. Лекция 12. Понятие исполнительного устройства в очереди в системе массового обслуживания
2. Э.Стеллман, Д.Грин. Постигая Agile. Ценности, принципы, методологии.
3. Д. Андерсон. Канбан. Альтернативный путь в Agile
4. Спринты - Atlassian
5. Словарь терминов Scrum — ScrumTrek
6. Что дает Канбан метод организации? — Покоряем
7. Scrum - Википедия
8. Мини-справочник и руководство по Scrum - Хабр
9. Инструменты Scrum для команд, использующих Agile - JetBrains