-
Notifications
You must be signed in to change notification settings - Fork 17
exam12 4
Основные практические приемы применения теории массового обслуживания в гибкой разработке программных средств (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 является 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'ы, ретроспективы. Для ускорения выполнения этих процедур необходимо использовать инструменты.
Project backlog содержит перечень пользовательских историй (user story), упорядоченный по приоритету и порядку реализации. Ответственный за ведение Project backlog — владелец продукта Scrum.
Sprint backlog содержит перечень требований, выбранных Scrum-командой из Project backlog с учетом приоритета, оценок трудозатрат, ресурсов команды и длительности Sprint'а.
Scrum-доска — это инструмент открытой демонстрации состояния текущей работы Scrum-команды. Scrum-доска состоит из трёх колонок: «сделать» (To-do), «в процессе» (In progress), «сделано» (Done).
На Scrum-доске размещается весь бэклог текущего Sprint’а. Обычно карточки пользовательских историй располагаются на доске сверху вниз в порядке убывания приоритета. Допускается декомпозиция пользовательских историй на задачи (технические, функциональные, организационные).
Карточки пользовательских историй и задач, передвигаются по доске из колонки в колонку, в соответствии с тем, как команда берёт их на исполнение (In Progress), и завершает (Done). Для обеспечения видимости прогресса работы команды «убывание работы» по дням, отображается на Burndown Chart’е.
Диаграмма, демонстрирующая количество сделанной и оставшейся работы относительно времени на разработку проекта. Данные диаграммы необходимо ежедневно обновлять, чтобы в реальном времени показывать прогресс работ в текущем Sprint’е всем членам Scrum-команды.
Канбан – это метод улучшения процессов, используемых гибкими командами для разработки программного обеспечения. Команды, применяющие его, начинают понимать, как они создают программное обеспечение, и постепенно улучшают его. Канбан имеет очень важную связь со способом управления проектом, который применяет команда.
Соответственно, Канбан – это не методология для разработки программного обеспечения и не система управления проектами.
Каденции является очень важным инструментом сбора информации и подачи ее обратно в систему. Это регулярные встречи для обсуждения движения по проектам. Их регулярность задает ритм работы.
Выделяют всего 7 канденций в системе:
- Ежедневные митинги для обсуждения статуса заблокированных работ.
- Встреча для получения новых работ и обязательств. Проводится один раз в две недели. На ней определяются обязательства по работам как предоставление качественного сервиса для клиента.
- Встреча для планирования поставки. Проводится раз в две недели. На ней возвращаются взятые обязательства.
- Встреча для обсуждения качества предоставляемых услуг. Проводится раз в две недели. На ней осуждаются качественные и количественные показатели сервиса и возможности для его улучшения.
- Операционная встреча. Проводится раз в месяц. На ней обсуждаются качественные характеристики взаимодействия разных отделов сервиса.
- Встреча – обзор возможных рисков. Проводится ежемесячно. На ней обсуждаются возникновения возможных рисков от заблокированных работ для предоставления качественного сервиса.
- Стратегическая встреча. Проводится раз в квартал. На ней обсуждаются стратегии развития.
Канбан-доска – это инструмент, который команды используют для визуализации рабочего процесса. Она похожа на доску задач Scrum: имеет колонки и стикеры (карточки). Однако существует три очень важных различия между доской задач и канбан-доской:
• канбан-доски содержат только истории и не показывают задачи;
• столбцы в канбан-досках обычно могут быть разными у различных команд;
• на канбан-досках могут устанавливаться лимиты на объем работ в колонке.
На канбан-досках нет задач, зато есть рабочие элементы (работы). Так называется самостоятельная единица работы, которую нужно отследить через всю систему. На досках отражается состояние рабочих элементов в рабочем процессе независимо от потока ценности, это называется картой жизненного цикла. Таким образом, канбан-доска определяет конкретные этапы, которые проходит каждый рабочий элемент.
Первый этап в улучшении процесса – это понимание того, как в настоящее время работает команда, и практика визуализации в Канбане позволяет это сделать.
При необходимости команда может вносить изменения. Таким образом получается более точная визуализация рабочего процесса в команде.
Если на канбан-доске видно все течение релиза, то можно увидеть все возможные проблемы (бутылочное горлышко, искусственная задержка выполнения работ, непрогнозируемое увеличение трудозатрат, блокировка выполнения работ по внешним обстоятельствам, простаивание ресурса и т.д.). В представленном ниже примере, работы ожидают приемки руководства в плоть до окончания релиза.
Оптимальный процесс – процесс, в котором все члены команды равномерно загружены, работы переходят со средней скоростью без скапливания на отдельных этапах (неравномерностей).
Выявленные неравномерности исправляются с помощью установки жестких ограничений на количество незавершенных работ на соответствующих этапах разработки (limit work in progress, WIP-лимит).
Когда команда устанавливает WIP-лимит на столбец (ставим цифру), перед ним нужно создать дополнительный этап - очередь. Он перестает быть местом, где скапливается масса рабочих элементов.
Цель Канбана заключается в достижении максимальной скорости потока работ (прохождение работ по доске от начального до конечного этапа). Когда команда находит оптимальный темп для поставки в сочетании с удобной обратной связью, она максимизирует поток.
Эффективный инструмент измерения потока – кумулятивная диаграмма потока (cumulative flow diagram, CFD).
CFD показывает среднюю частоту поступления (число рабочих элементов, ежедневно добавляемых в рабочий процесс), среднюю емкость (общее количество рабочих элементов в рабочем процессе), а также может показывать среднее время производства.
На основе стабильности CFD можно сделать вывод об эффективности применения WIP-лимитов, и, если необходимо, изменить их. Идеальная CFD – когда не существует скачков. В этом случае поток стабилен.
- Лекция 12. Понятие исполнительного устройства в очереди в системе массового обслуживания
- Э.Стеллман, Д.Грин. Постигая Agile. Ценности, принципы, методологии.
- Д. Андерсон. Канбан. Альтернативный путь в Agile
- Спринты - Atlassian
- Словарь терминов Scrum — ScrumTrek
- Что дает Канбан метод организации? — Покоряем
- Scrum - Википедия
- Мини-справочник и руководство по Scrum - Хабр
- Инструменты Scrum для команд, использующих Agile - JetBrains