Вы находитесь на странице: 1из 78

Современные процессы разработки ПО

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


- Scrum метод
Кафедра
«Информационные и управляющие системы»
Ст. преп. Лина Павловна Котлярова

2011 г. Котлярова Л.П. 1


Содержание
• Agile методологии - Scrum
– Словарь терминов
– Распределение ролей и обязанностей
(ответственности)
– Технологическая цепочка процесса Agile ( Agile
Process Workflow)
– Процессы в деталях, артефакты процессов
– Метрики

2011 г. Котлярова Л.П. 2


Scrum Method
• Scrum метод был применен в 1990-х Ken
Schwaber и Mike Beedle
• Scrum метод разработан для разработки
программных продуктов, базируясь на идеях
о разработке коммерческих процессов,
описанных Takeuchi и Nonaka в статье в 1986
• Scrum метод придает большее значение
управлению, чем спечифичным технологиям
производства ПО. Был использован в
соединении с CMMI

2011 г. Котлярова Л.П. 3


Scrum метод
 Итеративный, инкрементальный
процесс
 Придается особое значение
работающему продукту, полностью
проверенного тестами, и готового к
выпуску
 Группа специалистов различного
профиля

2011 г. Котлярова Л.П. 4


Основы Scrum метода
• Базовым рабочим циклом является спринт
(sprint)
­ Длительность спринта обычно 1-4 недели,
фиксированной продолжительности,
заканчивается на определенной дате, даже если
работа не закончена
• Список требований с расставленными
приоритетами
- В начале спринта команда отбирает часть
требований из списка и обязуется сделать их к
концу спринта

2011 г. Котлярова Л.П. 5


Основы Scrum метода
• Каждый день проводится короткое собрание
всей команды, на котором:
­ Каждый отчитывается перед командой о
проделанной работе
­ Вносят изменения в проектные артефакты,
которые показывают, сколько еще осталось
сделать
• В конце спринта
- Команда показывает, что было сделано
- Получает отзыв для следующего спринта

2011 г. Котлярова Л.П. 6


Agile Glossary - Терминология

2011 г. Котлярова Л.П. 7


Agile – словарь терминов (1)
• Backlog – незавершенная работа:
список задач, ошибок, свойств,
Backlog которые надо сделать (доделать)
Незавершенная
• Product backlog – список
работа незавершенных (нереализованных)
требований заказчика для продукта
• Product Backlog Item (item) – часть
• Product Backlog
работы, которую команда может
• Product Backlog Item выполнить за один цикл Sprint. Части
работ можно разбивать на одну или
• Sprint Backlog
несколько задач
• Sprint Backlog Item • Sprint Backlog – определяет набор
задач, которые надо выполнить,
чтобы достигнуть цели конкретного
спринта
• Sprint Backlog Item (task) – часть
работы, от 4 до 16 часов. Члены
команды добровольно выбирают
задачи, ежедневно обновляют
плановое кол-во часов. Задачи
приписаны к «элементам» (items)
2011 г. Котлярова Л.П. 8
Разница между
Product Backlog / Sprint Backlog

Product Sprint Item 1


Sprint Item 2
PBI 1
Sprint Item 3
PBI 2 Sprint Item 4
PBI 3
Sprint Item 1
PBI 4 Sprint Item 2
Sprint Item 3
PBI 5 Sprint Item 4
Sprint Item 5
PBI 6 Sprint Item 6

PBI n

2011 г. Котлярова Л.П. 9


Agile – словарь терминов (2)
• Sprint Planning – Ответственный за
продукт и команда обсуждают какую
Ceremonies часть работы команда будет делать в
“Церемонии”
течение следующего «спринта».
Согласуют набор целей для
«спринта» и определяют какие
«элементы» будут включены в
«спринт»
• Daily Meeting – ежедневное собрание
для проверки состояния работы.
• Sprint Planning Каждый отвечает на 3 вопроса.
• Daily Meeting • Sprint Review – обзор результатов
• Sprint Review
конкретного «спринта». Проводится в
конце каждого «спринта».
• Sprint Retrospective Демонстрация прототипа
• Sprint Retrospective – Проводится в
конце каждого «спринта» после
«спринт обзора». Команда и Scrum
Master обсуждают что удалось и что
надо улучшить в след. «спринте».

2011 г. Котлярова Л.П. 10


Agile – словарь терминов (3)
• Product Burndown Chart – это
обзорный график на состояние всего
проекта. Показывает сколько работы,
которую еще надо сделать, было в
начале каждого спринта.

• Sprint Burndown Chart – этот график


изображает общее число часов,
оставшихся для выполнения задачи
Burndown по дням. Он показывает где ваша
charts команда находится относительно
“Догорающие завершения задач, которые относятся
графики” к «элементам», которые надо
завершить для достижения целей
• Product Burndown Chart конкретного спринта.
• Sprint Burndown Chart

2011 г. Котлярова Л.П. 11


Agile – словарь терминов (4)
• Sprint – период времени (обычно от 2
до 4 недель), в течение которого
команда разрабатывает и поставляет
• Sprint заказчику набор функциональности.
• Velocity • Velocity (Скорость) - сколько
нереализованных требований для
• Impediments продукта (в усилиях) команда может
• User Story
сделать в течение одного спринта
• Impediments (Помехи) – всё, что
• Triage Meeting мешает членам команды выполнить
работу настолько эффективно,
насколько возможно
• User Story – Требование системного
Others уровня для ПО. Обычно они короткие и
Другие состоят из нескольких предложений.
• Triage Meeting («сортировка») -
проектные собрания, на которых баги
разбиваются на категории. Наиболее
важное различие – между теми багами,
которые не будут исправлены в данном
релизе, и теми, которые будут.

2011 г. Котлярова Л.П. 12


Triage Process

2011 г. Котлярова Л.П. 13


Agile Glossary
• Product Backlog
Backlog • Product Backlog Item
Незавершенная
• Sprint Backlog
работа
• Sprint Backlog Item

Ceremonies • Sprint Planning


“Церемонии” • Daily Meeting
• Sprint Review
• Sprint Retrospective

Burndown
charts
“Догорающие
• Sprint • Product Burndown Chart
графики”
• Velocity • Sprint Burndown Chart
Others
• Impediments
Другие
• User Story
• Triage Meeting

2011 г. Котлярова Л.П. 14


Sprint – Abnormal Termination
(анормальное прекращение)
Иногда изменения по весомым бизнес причинам происходят во время
выполнения Спринта. Scrum позволяет в таких случаях прибегнуть к
анормальному прекращению спринта - Abnormal Sprint termination

Команда Ответственный за продукт


Когда
остановить
Спринт ?

Всякий раз, когда команда обнаруживает, что не может


достичь целей Спринта, и когда Ответственный за продукт
обнаруживает, что нет ценности в списке задач для данного
Спринта
2011 г. Котлярова Л.П. 15
Обзор технологической цепочки
процесса Agile ( Scrum Process
Workflow)

2011 г. Котлярова Л.П. 16


Технологическая цепочка
Agile процесса Scrum

2011 г. Котлярова Л.П. 17


Распределение ролей и
обязанностей

2011 г. Котлярова Л.П. 18


Распределение ролей в проекте

Тестировщик (Team
Ответственный за
Member - Test)
продукт (Product Owner)

Специалист по качеству
Руководитель программы
(Quality Specialist)
(Program Manager)

Скрам мастер Разработчик (Team


(Scrum Master) Member - Dev)

2011 г. Котлярова Л.П. 19


Agile роли и обязанности (1/4)

Product Owner (ответственный за продукт)

• Определить функциональность продукта,


определить содержание релиза и назначить дату
выпуска продукта
Program Manager (руководитель
• Собрать требования от будущих пользователей, программы проектов)

заинтересованных лиц, чтобы сформировать Что такое программа проектов ?


единую точку зрения на приоритет системных Группа проектов должна управляться
скоординировано, чтобы добиться
требований преимуществ, которые невозможны,
• Отвечает за прибыльность продукта (ROI) если управлять проектами по
отдельности.
• Устанавливает приоритеты для
функциональности в соответствии с требованиями Program Manager отвечает за
руководство программы, управляет
рынка коллективом программы (functional
• Должен уметь изменять функциональность и supervisor)

приоритеты каждые 30 дней


• Принимать или отклонять результаты работы
• Отвечать за сопровождение Product Backlog
2011 г. Котлярова Л.П. 20
Agile роли и обязанности (2/4)

Scrum Master
• Улучшать инженерные практики и инструменты
• Обеспечивать следование процессу
• Определять проектный Agile процесс путем подстройки
• Содействовать тесной кооперации всех участников организационного процесса, при необходимости
проекта, устранять барьеры
• Определять цели качества для проекта и метрики
• Защищать команду от внешних воздействий, устранять
• Подготовить проектный план (Agile Project Plan) и план
помехи (Impediments)
поставок (Agile Release Plan)
• Приглашать соответствующих людей на ежедневные
• Планировать и отслеживать проектные риски
спринт обзоры и собрания для планирования
• Собирать и анализировать метрики
• Проводить ежедневные собрания, спринт обзоры и
ретроспективные обзоры, собрания для планирования • Подготовить презентацию для еженедельного проектного
(Daily, Sprint Review, Sprint Retrospective and Sprint Planning обзора и распространять её
meetings)
• Подготовить презентацию для спринт обзора
• Устранять барьеры между разработкой и заказчиком,
• Отвечать за незавершенные задачи спринтов (Sprint
чтобы заказчик прямо управлял разработкой
Backlog)
функциональности
• Поддерживать соответствие между элементами Product
• Работать с заказчиком для увеличения ROI и достигать
Backlog и Sprint Backlog
проектных целей

2011 г. Котлярова Л.П. 21


Agile роли и обязанности (3/4)

Developer Team Member (разработчик)


Test Team Member (тестировщик)
• Создание кода и unit tests (тесты для проверки
отдельных элементов) • Верифицирует ошибки (баги) и задачи
• Создавать тесты для регрессионного
• Выполнять обзоры кода тестирования
• Автоматизировать регрессионные тесты
• Создавать сборки кода (билды) и хранить их в насколько это возможно
базе конфигураций проекта • Отчитываться о найденных ошибках
• Выполнение тестов (exploratory tests)
• Участвовать в собраниях проекта (Daily, Sprint • Участвовать в собраниях проекта (Daily,
Sprint Planning, Sprint Review and Sprint
Planning, Sprint Review and Sprint Retrospective Retrospective meetings)
• Сообщать о любых препятствиях,
meetings) мешающих работе
• Сообщать о любых препятствиях, мешающих • Поддерживать трассировку между
тестами (test cases) и Product Backlog items
работе • Отчитываться о затраченных усилиях
(оставшаяся работа на конец дня)
• Отчитываться о затраченных усилиях
(оставшаяся работа на конец дня)

2011 г. Котлярова Л.П. 22


Agile Roles & Responsibilities (4/4)

Quality Specialist (Ответственный по качеству)

• Собирает и анализирует отчеты по окончании проектов


• Консультирует как подстроить процесс для проекта или сервисное обслуживание
• Участвует в реализации превентивных и корректирующих действий (PARs/CARs -
preventive and corrective action requests)
• Консультирует и верифицирует соответствие проектным планам и процессам;
высказывает свои замечания, если необходимо
• Поддерживает проектную команду в активностях, связанных с управлением на основе
количественного анализа, включая выбор критических процессов, предоставление
статистических данных и др.
• Помогает Scrum Master понять и использовать организационный план по качеству
• Помогает Scrum Master с подстройкой и выбором проектных метрик
• Участвует в собраниях проекта (Daily, Sprint Planning, Sprint Review and Sprint
Retrospective meetings)

2011 г. Котлярова Л.П. 23


Технологическая цепочка процесса
Agile Scrum в деталях

2011 г. Котлярова Л.П. 24


Agile Процессы (1/6)
Подготовительный процесс

На выходе:
• План выпуска продукта
Задачи: (начальный)

• Определить • Проектный план


На входе: заинтересованных лиц • Начальный список задач
• Представление проекта • Собрать команду

• Требования высокого • Решить логистич.проблемы


уровня • Подготовить нач.список задач
• Подготовить нач.план для
релизов

2011 г. Котлярова Л.П. 25


Agile Процессы (2/6)
Спринт процесс

На выходе:
• Скорректированный
список задач продукта
Задачи: • Список незавершенных
• Обзор списка задач продукта задач спринта
• Провести собрание для • Сборка готового кода
На входе: планирования спринта (Product Increment)

• Список задач продукта • Описать или изменить HLD • Скорректированный план


выпуска продукта
• План выпуска продукта • Выполнить ежедневную
работу (см.комментарий для • Скорректированный
• Проектный план видов работ) проектный план
• Провести собрание по • Протокол
результатам спринта ретроспективного обзора
спринта
• Провести ретроспективный
обзор спринта • Презентация для
собрания по результатам
• Выполнить приемочные тесты
спринта
ответственного за продукт
2011 г. Котлярова Л.П. 26
Sprint Planning Meeting

Scrum Sprint planning


Master 1 ЧАСТЬ
• Product Owner представляет
4 часа
Product наиболее приоритетный Product
Owner Backlog максимум
• Команда выбирает задачи, за
которые берется
• Устанавливают цель Спринта
Team
2 ЧАСТЬ
• Решают как достичь цели
4 часа
спринта (design)
Planning макс.
• Создаются задачи
• Оценка задач для спринта
делается сообща, а не только
одним Scrum Master

2011 г. Котлярова Л.П. 27


Agile Процессы (3/6)
Ежедневный рабочий процесс разработки

На выходе:
Задачи: • Новый / измененный
• Выбрать задачу или ошибку из списка задач спринта для исходный код
реализации • Новые / измененные unit
На входе:
• Если задача исследовательская, то провести исследование test cases
• Список задач продукта и скорректировать Sprint Backlog Item
• Новая сборка кода (Build)
• План выпуска продукта • Если задача для разработки или исправление ошибки:
• Скорректированный
• Проектный план • кодировать исправление или новую список незавершенных
функциональность задач спринта
• создать и запустить unit test • Скорректированный
список задач продукта
• выполнить code reviews
• интегрировать изменения и запустить локально unit
test suite
• удалить предупреждения компиляции
• добавить код на общую ветку разработки, создать
билд
• документировать детали билда
• убедиться, что билд успешен
• скорретировать конкретный Sprint Backlog Item or Bug
2011 г. Котлярова Л.П. 28
Agile Процессы (4/6)
Процесс проектирования

Задачи: На выходе:
• Рассмотреть продуктовые задачи, которые будут • Измененная архитектура /
На входе: разрабатываться на данном спринте High Level Design

• Список задач продукта • Определить изменения, необходимые для их


включенных в спринт реализации в коде
• Конкретные элементы из • Улучшить системную архитектуру / дизайн
списка задач спринта
• Выявить любые проблемы в реализации изменений
• Обсудить подход и изменения для каждой
продуктовой отдельной задачи
• Согласовать предлагаемые изменения в
архитектуре/дизайне со всеми разработчиками, кого
это затрагивает
• Скорректировать задачи спринта
• Проинформировать других разработчиков и
получить согласие

2011 г. Котлярова Л.П. 29


Agile Процессы (5/6)
Ежедневный процесс тестирования

Задачи: На выходе:
• Инсталлировать последний имеющийся билд • Скорректированный
• Определить объем дневного системного тестирования список незавершенных
• Если объем тестирования – верификация ошибок / задач: задач спринта
На входе:
• выбрать задачу или баг для проверки, изменить поле назначения (в • Скорректированный
• Список задач продукта базе ошибок) список задач продукта
• План выпуска продукта • проверить требование или ошибку
• Скорректированный
• изменить поля в базе для проверенного элемента набор тестов для
• Проектный план
• создать тесты для проверки новой или исправленной функциональности регрессионного
• выполнить обзор тестов (test cases review)
тестирования

• Если объем тестирования – регрессионное тестирование:


• выбрать набор тестов для исполнения
• выполнить выбранные тесты
• отчитаться по найденным ошибкам
• создать отчет (Test Log Report)
• Если объем тестирования – Exploratory Test:
• скорректировать Exploratory Test Chart
• выполнить тесты (Exploratory session)
• отчитаться по найденным ошибкам
• создать тесты для проверки новой или исправленной функциональности
• выполнить обзор тестов (test cases review)

2011 г. Котлярова Л.П. 30


Agile Процессы (6/6)
Процесс спринта для выпуска продукта (релиза)

На выходе:
• Продукт, переданный
заказчику
Задачи: • Документация,
На входе:
• Провести собрание по планированию относящаяся к продукту
• Собранный и проверенный спринта (Sprint Planning meeting) (Release Notes)
код (Product Increment) от
предыдущего спринта • Выполнить активности, связанные с • Результаты
выпуском релиза ретроспективного обзора
• Список продуктовых спринта
элементов в состоянии • Провести ретроспективный обзор спринта
«Выполнено», относящиеся к • Скорректированный план
конкретному релизу выпуска релизов

2011 г. Котлярова Л.П. 31


Метрики

2011 г. Котлярова Л.П. 32


Agile Метрики (1/2)

Agile Training March 24, 2012

2011 г. Котлярова Л.П. 33


Agile Метрики (2/2)

Agile Training March 24, 2012

2011 г. Котлярова Л.П. 34


Back-Up Slides

2011 г. Котлярова Л.П. 35


• Scrum Masters, QS
– Подготовительный процесс
• Sprint & Team Capacity Guidelines [Sprint и руководящие
принципы для возможностей команды]
– Sprint process
• Ежедневные митинги
• Triage Process [процесс сортировки задач/ошибок,
установление очередности работ]
• Sprint review
• Sprint retrospective guideline
• Tracking and metrics [отслеживание и метрики]
– Выпуск продукта, релиз

2011 г. Котлярова Л.П. 36


• Developers, Scrum Masters
– Design Process (Code, Cont integration and UT)
[процесс разработки]
– Development daily work process [каждодневный
процесс разработки]
– Daily meetings (progress) [как оценивать прогресс
на ежедневных собраниях]
– Review process & Done criteria [процесс обзора и
критерии готовности]

2011 г. Котлярова Л.П. 37


• Testers, Scrum Masters
– Test Process [процесс тестирования]
– Exploratory test guidelines [руководство для
исследовательского тестирования]
– Review process & Done criteria [процесс обзора и
критерии готовности]
Scrum Masters, QS
– Quality Topics: Audit Checklists

2011 г. Котлярова Л.П. 38


• Developers, Testers, Scrum Masters
– Setting up the Environment Topics [настройка
окружения разработки]
• Product Backlog Management – EPMS – Metrics Book
integration (optional: RequisitePro – Rational Architect)
Product Owner
• The role of the Product Owner in Agile projects

2011 г. Котлярова Л.П. 39


Организация и планирование производства ПО 2011 г.

Современные процессы разработки ПО


Гибкие методологии разработки
- Scrum метод
Кафедра
«Информационные и управляющие системы»
Ст. преп. Лина Павловна Котлярова

2011 г. Котлярова Л.П. 1

Котлярова Л.П. 1
Организация и планирование производства ПО 2011 г.

Содержание
• Agile методологии - Scrum
– Словарь терминов
– Распределение ролей и обязанностей
(ответственности)
– Технологическая цепочка процесса Agile ( Agile
Process Workflow)
– Процессы в деталях, артефакты процессов
– Метрики

2011 г. Котлярова Л.П. 2

Котлярова Л.П. 2
Организация и планирование производства ПО 2011 г.

Scrum Method
• Scrum метод был применен в 1990-х Ken
Schwaber и Mike Beedle
• Scrum метод разработан для разработки
программных продуктов, базируясь на идеях
о разработке коммерческих процессов,
описанных Takeuchi и Nonaka в статье в 1986
• Scrum метод придает большее значение
управлению, чем спечифичным технологиям
производства ПО. Был использован в
соединении с CMMI

2011 г. Котлярова Л.П. 3

(from http://www.umsl.edu/~sauterv/analysis/6840_f09_papers/Nat/Agile.html)
Scrum was applied in 1990s by Ken Schwaber and Mike Beedle. It is an agile,
iterative, incremental developing method which assumes that changes and chaos
exist through entire life-circle of the project and attempt to solve these problems
[6]
Scrum is designed to add energy, focus, clarity and transparency to project teams
development software systems. It allows team to operate in close proximity to
foster rapid system evolution. [4]
In Scrum, work is structured in cycles of work called sprints , iterations of work
that are typically two to four weeks in duration. During each sprint, teams pull
from a prioritized list of customer requirements, called user stories , so that the
features that are developed first are of the highest value to the customer. At the
end of each sprint, a potentially shippable product is delivered. [9]
Scrum naturally focuses an entire organization on building successful products.
Without major changes -often within thirty days - teams are building useful,
demonstrable product functionality. Scrum can be implemented at the beginning
of a project or in the middle of a project or product development effort that is in
trouble. [10]

[4] Phalnikar.,Deshpand.,&Joshi (2008).Applying Agile Principles for Distributed


Software Development
[6] Department of Computer Science, Comsats Institute of Information
Technology, Lahore, Pakistan
[9] Meng.X., Wang.Y., Shi.Lei.,&Wang.F(2007).A process pattern Language for
Agile Methods. 14 th Asia-Pacific Software Engineering Conference
Котлярова Л.П.
[10] http://www.scrumalliance.org/pages/what_is_scrum 3
Организация и планирование производства ПО 2011 г.

Scrum метод
 Итеративный, инкрементальный
процесс
 Придается особое значение
работающему продукту, полностью
проверенного тестами, и готового к
выпуску
 Группа специалистов различного
профиля

2011 г. Котлярова Л.П. 4

Котлярова Л.П. 4
Организация и планирование производства ПО 2011 г.

Основы Scrum метода


• Базовым рабочим циклом является спринт
(sprint)
­ Длительность спринта обычно 1-4 недели,
фиксированной продолжительности,
заканчивается на определенной дате, даже если
работа не закончена
• Список требований с расставленными
приоритетами
- В начале спринта команда отбирает часть
требований из списка и обязуется сделать их к
концу спринта

2011 г. Котлярова Л.П. 5

Котлярова Л.П. 5
Организация и планирование производства ПО 2011 г.

Основы Scrum метода


• Каждый день проводится короткое собрание
всей команды, на котором:
­ Каждый отчитывается перед командой о
проделанной работе
­ Вносят изменения в проектные артефакты,
которые показывают, сколько еще осталось
сделать
• В конце спринта
- Команда показывает, что было сделано
- Получает отзыв для следующего спринта

2011 г. Котлярова Л.П. 6

Котлярова Л.П. 6
Организация и планирование производства ПО 2011 г.

Agile Glossary - Терминология

2011 г. Котлярова Л.П. 7

Scrum метод оперирует терминами, часть из которых свойственна только


этому методу

Котлярова Л.П. 7
Организация и планирование производства ПО 2011 г.

Agile – словарь терминов (1)


• Backlog – незавершенная работа:
список задач, ошибок, свойств,
Backlog которые надо сделать (доделать)
Незавершенная
• Product backlog – список
работа незавершенных (нереализованных)
требований заказчика для продукта
• Product Backlog Item (item) – часть
• Product Backlog
работы, которую команда может
• Product Backlog Item выполнить за один цикл Sprint. Части
работ можно разбивать на одну или
• Sprint Backlog
несколько задач
• Sprint Backlog Item • Sprint Backlog – определяет набор
задач, которые надо выполнить,
чтобы достигнуть цели конкретного
спринта
• Sprint Backlog Item (task) – часть
работы, от 4 до 16 часов. Члены
команды добровольно выбирают
задачи, ежедневно обновляют
плановое кол-во часов. Задачи
приписаны к «элементам» (items)
2011 г. Котлярова Л.П. 8

Agile Glossary
Agile терминология (часть 1).

Backlog: is a list of tasks, bugs, features that need to be done


Незавершенная работа: список задач, ошибок, свойств (функциональности), которые надо доделать

Product Backlog: Is a list of customer requirements for the entire product


Незавершенные свойства продукта: список несделанных (незаконченных) требований заказчика для целого продукта

Product Backlog Item: A product backlog item ("PBI", "backlog item", or "item") is a unit of work small enough to be completed by a team
in one Sprint iteration. Backlog items are decomposed into one or more tasks.
Сокращенно «item» или «элемент». Небольшая часть работы, которую команда может выполнить за один цикл Sprint. Элементы
работы можно разбивать на одну или несколько задач.

Sprint Backlog: Defines the work for a sprint, represented by the set of tasks that must be completed to achieve the sprint goals.
Определяет работу для «спринта» в виде набора задач, которые надо выполнить, чтобы достигнуть цели «спринта».

Sprint Backlog Item: (or task) is a unit of work generally between four and sixteen hours. Team members volunteer for tasks. They update
the estimated number of hours remaining on a daily basis, influencing the sprint burn down chart. Tasks are contained by backlog items.
Сокращенно «task» или «задача». Часть работы, рассчитанная, обычно, на 4 - 16 часов. Члены команды добровольно берутся
выполнять задачи. Они ежедневно обновляют оставшееся планируемое количество часов, и это отражается на «sprint burn down
chart» (графике оставшихся в «спринте» задач). Задачи приписываются к «элементам» работы.

Котлярова Л.П. 8
Разница между
Product Backlog / Sprint Backlog

Product Sprint Item 1


Sprint Item 2
PBI 1
Sprint Item 3
PBI 2 Sprint Item 4
PBI 3
Sprint Item 1
PBI 4 Sprint Item 2
Sprint Item 3
PBI 5 Sprint Item 4
Sprint Item 5
PBI 6 Sprint Item 6

PBI n

2011 г. Котлярова Л.П. 9


Организация и планирование производства ПО 2011 г.

Agile – словарь терминов (2)


• Sprint Planning – Ответственный за
продукт и команда обсуждают какую
Ceremonies часть работы команда будет делать в
“Церемонии”
течение следующего «спринта».
Согласуют набор целей для
«спринта» и определяют какие
«элементы» будут включены в
«спринт»
• Daily Meeting – ежедневное собрание
для проверки состояния работы.
• Sprint Planning Каждый отвечает на 3 вопроса.
• Daily Meeting • Sprint Review – обзор результатов
• Sprint Review
конкретного «спринта». Проводится в
конце каждого «спринта».
• Sprint Retrospective Демонстрация прототипа
• Sprint Retrospective – Проводится в
конце каждого «спринта» после
«спринт обзора». Команда и Scrum
Master обсуждают что удалось и что
надо улучшить в след. «спринте».

2011 г. Котлярова Л.П. 10

Agile Glossary
Agile терминология (часть 2).

Sprint Planning: Is a negotiation between the team and the product owner about what the team will do during the next sprint. The Product
Owner and all team members agree on a set of sprint goals, which is used to determine which product backlog items to commit from the
uncommitted backlog to the sprint.
Ответственный за продукт и команда обсуждают какую часть работы команда будет делать в течение следующего «спринта».
Ответственный за продукт и все члены команды согласуют набор целей для «спринта», которые используются, чтобы определить
какие «элементы» из списка будут включены в «спринт».

Daily Meeting: Is a status check where the team meets and shares progress, impediments and short term assignments. Usually three questions
asked: "What did you do yesterday?", "What will you do today?" and "What is blocking progress?".
Ежедневное собрание. Это проверка состояния работы, когда члены команды встречается вместе и рассказывают о том, что
сделано, какие имеются препятствия, кратких поручениях или задачах. Обычно обсуждаются 3 вопроса: «Что вы сделали вчера?»,
«Что вы будете делать сегодня?», «Какой прогресс «незавершенки»?»

Sprint Review: At the end of each sprint a sprint review meeting is held. During this meeting the team shows what they accomplished during
the sprint. Typically this takes the form of a demo of the new features.
В конце каждого «спринта» проводится собрание в виде «спринт обзора». Во время этого собрания команда показывает
достижения конкретного «спринта». Обычно, это проходит в виде демонстрации прототипа с новыми свойствами (новой
функциональностью).

Sprint Retrospective: The sprint retrospective meeting is held at the end of every sprint after the sprint review meeting. The team and Scrum
Master meet to discuss what went well and what to improve in the next sprint. The sprint retrospective should be time-boxed.
Проводится в конце каждого «спринта» после «спринт обзора». Команда и Scrum мастер встречаются, чтобы обсудить что
выполнялось успешно во время конкретного «спринта» и что надо улучшить для следующего. Время для этого собрания должно
быть ограничено.

Котлярова Л.П. 10
Организация и планирование производства ПО 2011 г.

Agile – словарь терминов (3)


• Product Burndown Chart – это
обзорный график на состояние всего
проекта. Показывает сколько работы,
которую еще надо сделать, было в
начале каждого спринта.

• Sprint Burndown Chart – этот график


изображает общее число часов,
оставшихся для выполнения задачи
Burndown по дням. Он показывает где ваша
charts команда находится относительно
“Догорающие завершения задач, которые относятся
графики” к «элементам», которые надо
завершить для достижения целей
• Product Burndown Chart конкретного спринта.
• Sprint Burndown Chart

2011 г. Котлярова Л.П. 11

Agile Glossary
Agile терминология (часть 3).

Product Burndown Chart: The product burndown chart is a "big picture" view of a project's progress. It shows how much work was left to
do at the beginning of each sprint.
Продуктовый «догорающий график» - это обзорный график на состояние проекта. Показывает сколько работы, которую еще надо
сделать, было в начале каждого «спринта»

Sprint Burndown Chart: A sprint burndown chart (or "sprint burndown graph") depicts the total task hours remaining per day. This shows
you where your team stands regarding completing the tasks that comprise the product backlog items that achieve the goals of the sprint. The
X-axis represents days in the sprint, while the Y-axis is effort remaining (usually in ideal engineering hours).
«Догорающий график» для «спринта» изображает общее число часов, оставшихся для выполнения задачи по дням. Этот график
показывает где ваша команда находится относительно завершения задач, которые относятся к «элементам», которые надо
завершить для достижения целей конкретного «спринта». Х-ось означает дни в спринте, У-ось означает требующиеся усилия
(обычно в идеальных инженерных часах).

Котлярова Л.П. 11
Организация и планирование производства ПО 2011 г.

Agile – словарь терминов (4)


• Sprint – период времени (обычно от 2
до 4 недель), в течение которого
команда разрабатывает и поставляет
• Sprint заказчику набор функциональности.
• Velocity • Velocity (Скорость) - сколько
нереализованных требований для
• Impediments продукта (в усилиях) команда может
• User Story
сделать в течение одного спринта
• Impediments (Помехи) – всё, что
• Triage Meeting мешает членам команды выполнить
работу настолько эффективно,
насколько возможно
• User Story – Требование системного
Others уровня для ПО. Обычно они короткие и
Другие состоят из нескольких предложений.
• Triage Meeting («сортировка») -
проектные собрания, на которых баги
разбиваются на категории. Наиболее
важное различие – между теми багами,
которые не будут исправлены в данном
релизе, и теми, которые будут.

2011 г. Котлярова Л.П. 12

Agile Glossary
Agile терминология (часть 4).

Sprint: A time period (usually 30 days) in which development team implements and delivers a set of functionalities. It is recommended to use
iterations with equal duration.
Спринт – это период времени (обычно от 2 до 4 недель), в течение которого команда разрабатывает и поставляет заказчику набор
функциональности. Рекомендуется применять итерации одинаковой продолжительности.

Velocity: Is how much product backlog effort a team can handle in one sprint. This can be estimated by viewing previous sprints, assuming
the team composition and sprint duration are kept constant.
Скорость: сколько нереализованных требований для продукта (в усилиях) команда может сделать в течение одного спринта. Это
можно оценить, анализируя данные по предыдущим спринтам, предполагая, что состав команды и период спринта остаются
неизменными.

Impediments: Anything that prevents a team member from performing work as efficiently as possible is an impediment.
Помехи: всё, что мешает членам команды выполнить работу настолько эффективно, насколько возможно.

User Story: A user story is a software system requirement. Usually they are short and consist of several sentences. User stories are a quick
way of handling customer requirements without having to deal with large formal requirement documents and tedious tasks related to their
maintenance.
Требование системного уровня для ПО. Обычно они короткие и состоят из нескольких предложений. Это быстрый путь работать с
требованиями заказчика без того, чтобы иметь дело с документами огромного размера, содержащие формальные требования, и
утомительной работы поддерживать эти документы в соответствии с изменениями.

Triage Meeting: are project meetings in which open bugs are divided into categories. The most important distinction is between bugs that
will not be fixed in this release and those that will.
Собрание «сортировки». Это проектные собрания, на которых открытые дефекты разбиваются на категории. Наиболее важное
различие – между теми дефектами, которые не будут исправлены в данном релизе, и теми, которые будут.

Definition of Done (DoD): критерий для того, чтобы определить завершен ли элемент из Backlog. Каждая команда может иметь
свой собственный DoD.

Котлярова Л.П. 12
Triage Process

2011 г. Котлярова Л.П. 13


Организация и планирование производства ПО 2011 г.

Agile Glossary
• Product Backlog
Backlog • Product Backlog Item
Незавершенная
• Sprint Backlog
работа
• Sprint Backlog Item

Ceremonies • Sprint Planning

“Церемонии” • Daily Meeting


• Sprint Review
• Sprint Retrospective

Burndown
charts
“Догорающие
• Sprint • Product Burndown Chart
графики”
• Velocity • Sprint Burndown Chart
Others
• Impediments
Другие
• User Story
• Triage Meeting

2011 г. Котлярова Л.П. 14

Agile Glossary - рисунок

Котлярова Л.П. 14
Sprint – Abnormal Termination
(анормальное прекращение)
Иногда изменения по весомым бизнес причинам происходят во время
выполнения Спринта. Scrum позволяет в таких случаях прибегнуть к
анормальному прекращению спринта - Abnormal Sprint termination

Команда Ответственный за продукт


Когда
остановить
Спринт ?

Всякий раз, когда команда обнаруживает, что не может


достичь целей Спринта, и когда Ответственный за продукт
обнаруживает, что нет ценности в списке задач для данного
Спринта
2011 г. Котлярова Л.П. 15
Организация и планирование производства ПО 2011 г.

Обзор технологической цепочки


процесса Agile ( Scrum Process
Workflow)

2011 г. Котлярова Л.П. 16

Котлярова Л.П. 16
Организация и планирование производства ПО 2011 г.

Технологическая цепочка
Agile процесса Scrum

2011 г. Котлярова Л.П. 17

Agile процесс начинается с подготовительной стадии (Preparation Stage), затем следует спринт цикл, который
включает от 1 до n итераций (или спринтов). Выпускающий спринт (Release Sprint) происходит тогда, когда
результаты предыдущих спринтов в виде добавлений в продукт (Product Increment), готовы для выпуска продукта
на рынок.

Цель Preparation stage обозначить позицию, где итеративный Scrum цикл должен начинаться. Подготовительная
стадия включает определение видения будущего проекта, вовлечение заинтересованных сторон (stakeholders),
выбор членов команды, обозначение начального количества несделанных работ (Initial Product Backlog), создание
планов (Agile Project Plan and Agile Release Plan).
Создается «дорожная карта» (roadmap) с числом спринтов, необходимых, чтобы имплементировать Initial Product
Backlog и все плановые релизы (выпуски продукта). Как только Preparation stage закончена, начинается цикл
спринтов (Sprints Cycle).
В начале спринта команда стартует вместе с Product Owner, гарантируя, что команда правильно расставила
приоритеты и сроки для Product Backlog. Это позволяет команде выбрать достижимый набор задач из backlog с
наивысшим приоритетом и определить как реализовать их на Sprint Planning meeting.

Затем команда ежедневно работает над задачами (Sprint Backlog tasks), синхронизируя свои активности на
ежедневном скрам собрании (Scrum Meeting).
В конце спринта команда подготавливает прототип (билд) с инкрементальной функциональностью (Product
Increment), который демонстрируют Ответственному за продукт (Product Owner), будущим пользователям
(выделенной группе) и другим заинтересованным лицам во время спринт обзора (Sprint Review). Ответная
реакция, полученная на этом обзоре, будут добавлены в список незавершенных требований заказчика для продукта (Product Backlog) и
ответственный за продукт определит приоритеты для каждого такого элемента.

Перед началом следующего спринта команда обсуждает свою производительность и эффективность и предлагают
улучшения в своей работе во время проведения спринт обзора (Sprint Retrospective). Ответственный за продукт
(Product Owner) исполняет свои приёмочные тесты (Acceptance Test) для очередного билда или сборки продукта
(Product Increment), и по результатам этих тестов могут быть изменены либо требования на продукт, либо
занесены баги (ошибки) на продукт, которые тоже надо добавлять в Product Backlog и расставлять приоритеты.

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

Котлярова Л.П. 17
Организация и планирование производства ПО 2011 г.

Распределение ролей и
обязанностей

2011 г. Котлярова Л.П. 18

Котлярова Л.П. 18
Организация и планирование производства ПО 2011 г.

Распределение ролей в проекте

Тестировщик (Team
Ответственный за
Member - Test)
продукт (Product Owner)

Специалист по качеству
Руководитель программы
(Quality Specialist)
(Program Manager)

Скрам мастер Разработчик (Team


(Scrum Master) Member - Dev)

2011 г. Котлярова Л.П. 19

The roles involved in Motorola Agile process are:

The Product Owner – Ответственный за продукт,


The Program Manager – Руководитель Программы (менеджер),
The Scrum Master – Скрам мастер,
The Developer Team Member – Разработчик, член команды,
The Quality Specialist – специалист по качеству,
The Tester Team Member – Тестировщик, член команды

Котлярова Л.П. 19
Организация и планирование производства ПО 2011 г.

Agile роли и обязанности (1/4)

Product Owner (ответственный за продукт)

• Определить функциональность продукта,


определить содержание релиза и назначить дату
выпуска продукта
Program Manager (руководитель
• Собрать требования от будущих пользователей, программы проектов)

заинтересованных лиц, чтобы сформировать Что такое программа проектов ?


единую точку зрения на приоритет системных Группа проектов должна управляться
скоординировано, чтобы добиться
требований преимуществ, которые невозможны,
• Отвечает за прибыльность продукта (ROI) если управлять проектами по
отдельности.
• Устанавливает приоритеты для
функциональности в соответствии с требованиями Program Manager отвечает за
руководство программы, управляет
рынка коллективом программы (functional
• Должен уметь изменять функциональность и supervisor)

приоритеты каждые 30 дней


• Принимать или отклонять результаты работы
• Отвечать за сопровождение Product Backlog
2011 г. Котлярова Л.П. 20

Обязанности Ответственного за продукт (Product Owner):

• Определить свойства (функциональность) продукта, определить содержание релиза и


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

• Отвечает за прибыльность продукта

• Устанавливает приоритеты для функциональности в соответствии с требованиями рынка

• Должен уметь изменять функциональность и приоритеты каждые 30 дней

• Принимать или отклонять результаты работы

• Отвечать за сопровождение Product Backlog

Руководитель программы проектов (Program Manager)


Программа проектов ? Группа проектов должна управляться скоординировано,
чтобы добиться преимуществ, которые невозможны, если управлять проектами по
отдельности.
Program Manager отвечает за руководство программы, управляет коллективом программы
(functional supervisor)

Котлярова Л.П. 20
Организация и планирование производства ПО 2011 г.

Agile роли и обязанности (2/4)

Scrum Master
• Улучшать инженерные практики и инструменты
• Обеспечивать следование процессу
• Определять проектный Agile процесс путем подстройки
• Содействовать тесной кооперации всех участников организационного процесса, при необходимости
проекта, устранять барьеры
• Определять цели качества для проекта и метрики
• Защищать команду от внешних воздействий, устранять
• Подготовить проектный план (Agile Project Plan) и план
помехи (Impediments)
поставок (Agile Release Plan)
• Приглашать соответствующих людей на ежедневные
• Планировать и отслеживать проектные риски
спринт обзоры и собрания для планирования
• Собирать и анализировать метрики
• Проводить ежедневные собрания, спринт обзоры и
ретроспективные обзоры, собрания для планирования • Подготовить презентацию для еженедельного проектного
(Daily, Sprint Review, Sprint Retrospective and Sprint Planning обзора и распространять её
meetings)
• Подготовить презентацию для спринт обзора
• Устранять барьеры между разработкой и заказчиком,
• Отвечать за незавершенные задачи спринтов (Sprint
чтобы заказчик прямо управлял разработкой
Backlog)
функциональности
• Поддерживать соответствие между элементами Product
• Работать с заказчиком для увеличения ROI и достигать
Backlog и Sprint Backlog
проектных целей

2011 г. Котлярова Л.П. 21

Обязанности Scrum Master:

• Обеспечивать следование процессу


• Содействовать тесной кооперации всех участников проекта, устранять барьеры
• Защищать команду от внешних воздействий, устранять помехи (Impediments)
• Приглашать соответствующих людей на ежедневные спринт обзоры и собрания для планирования
• Проводить ежедневные собрания, спринт обзоры и ретроспективные обзоры, собрания для
планирования (Daily, Sprint Review, Sprint Retrospective and Sprint Planning meetings)
• Устранять барьеры между разработкой и заказчиком, чтобы заказчик прямо управлял разработкой
функциональности
• Работать с заказчиком для увеличения ROI и достигать проектных целей

• Улучшать инженерные практики и инструменты


• Определять проектный Agile процесс путем подстройки организационного процесса, при
необходимости
• Определять цели качества для проекта и метрики
• Подготовить проектный план (Agile Project Plan) и план поставок (Agile Release Plan)
• Планировать и отслеживать проектные риски
• Собирать и анализировать метрики
• Подготовить презентацию для еженедельного проектного обзора и распространять её
• Подготовить презентацию для спринт обзора
• Отвечать за незавершенные задачи спринтов (Sprint Backlog)
• Поддерживать соответствие между элементами Product Backlog и Sprint Backlog

Котлярова Л.П. 21
Организация и планирование производства ПО 2011 г.

Agile роли и обязанности (3/4)

Developer Team Member (разработчик)


Test Team Member (тестировщик)
• Создание кода и unit tests (тесты для проверки
отдельных элементов) • Верифицирует ошибки (баги) и задачи
• Создавать тесты для регрессионного
• Выполнять обзоры кода тестирования
• Автоматизировать регрессионные тесты
• Создавать сборки кода (билды) и хранить их в насколько это возможно
базе конфигураций проекта • Отчитываться о найденных ошибках
• Выполнение тестов (exploratory tests)
• Участвовать в собраниях проекта (Daily, Sprint • Участвовать в собраниях проекта (Daily,
Sprint Planning, Sprint Review and Sprint
Planning, Sprint Review and Sprint Retrospective Retrospective meetings)
• Сообщать о любых препятствиях,
meetings) мешающих работе
• Сообщать о любых препятствиях, мешающих • Поддерживать трассировку между
тестами (test cases) и Product Backlog items
работе • Отчитываться о затраченных усилиях
(оставшаяся работа на конец дня)
• Отчитываться о затраченных усилиях
(оставшаяся работа на конец дня)

2011 г. Котлярова Л.П. 22

Команда разработки (The team):


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

Обязанности Developer Team Member (разработчика):

•Создание кода и unit tests (тесты для проверки отдельных элементов)


•Выполнять обзоры кода
•Создавать сборки кода (билды) и хранить их в базе конфигураций проекта
•Участвовать в собраниях проекта (Daily, Sprint Planning, Sprint Review and Sprint
Retrospective meetings)
•Сообщать о любых препятствиях, мешающих работе
•Отчитываться о затраченных усилиях (оставшаяся работа на конец дня)

Обязанности Test Team Member (тестировщика):


•Верифицирует ошибки (баги) и задачи
•Создавать тесты для регрессионного тестирования
•Автоматизировать регрессионные тесты насколько это возможно
•Отчитываться о найденных ошибках
Котлярова Л.П.
•Выполнение тестов (exploratory tests) 22
Организация и планирование производства ПО 2011 г.

Agile Roles & Responsibilities (4/4)

Quality Specialist (Ответственный по качеству)

• Собирает и анализирует отчеты по окончании проектов


• Консультирует как подстроить процесс для проекта или сервисное обслуживание
• Участвует в реализации превентивных и корректирующих действий (PARs/CARs -
preventive and corrective action requests)
• Консультирует и верифицирует соответствие проектным планам и процессам;
высказывает свои замечания, если необходимо
• Поддерживает проектную команду в активностях, связанных с управлением на основе
количественного анализа, включая выбор критических процессов, предоставление
статистических данных и др.
• Помогает Scrum Master понять и использовать организационный план по качеству
• Помогает Scrum Master с подстройкой и выбором проектных метрик
• Участвует в собраниях проекта (Daily, Sprint Planning, Sprint Review and Sprint
Retrospective meetings)

2011 г. Котлярова Л.П. 23

Обязанности Quality Specialist (специалиста по качеству):

• Собирает и анализирует отчеты по окончании проектов


• Консультирует как подстроить процесс для проекта или сервисное
обслуживание
• Участвует в реализации превентивных и корректирующих действий
(PARs/CARs - preventive and corrective action requests)
• Консультирует и верифицирует соответствие проектным планам и
процессам; высказывает свои замечания, если необходимо
• Поддерживает проектную команду в активностях, связанных с
управлением на основе количественного анализа, включая выбор
критических процессов, предоставление статистических данных и др.
• Помогает Scrum Master понять и использовать организационный план
по качеству
• Помогает Scrum Master с подстройкой и выбором проектных метрик
• Участвует в собраниях проекта (Daily, Sprint Planning, Sprint Review
and Sprint Retrospective meetings)

Котлярова Л.П. 23
Организация и планирование производства ПО 2011 г.

Технологическая цепочка процесса


Agile Scrum в деталях

2011 г. Котлярова Л.П. 24

Котлярова Л.П. 24
Организация и планирование производства ПО 2011 г.

Agile Процессы (1/6)


Подготовительный процесс

На выходе:
• План выпуска продукта
Задачи: (начальный)

• Определить • Проектный план


На входе: заинтересованных лиц • Начальный список задач
• Представление проекта • Собрать команду

• Требования высокого • Решить логистич.проблемы


уровня • Подготовить нач.список задач
• Подготовить нач.план для
релизов

2011 г. Котлярова Л.П. 25

На входе Подготовительного Процесса имеются следующие данные:

•Представление проекта
•Требования высокого уровня

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

•Определить Заинтересованных Лиц: Scrum Master должен заранее определить всех потенциальных заинтересованных лиц (stakeholders) и
определить каким образом коммуницировать с каждым из них по проектным вопросам, чтобы создать или изменить проектный план
•Собрать команду: Scrum Master отвечает для назначение ролей членам команды. После отбора специалистов в команду проводится начальное
собрание (kick-off meeting), на котором отвественный за продукт объясняет будущее и содержание проекта, проводится обзор высокоуровневых
требований и обсуждаются любые технические вопросы высокого уровня. После такого собрания Scrum Master внесет исправления в
проектный план.
•Решить логистические проблемы: Scrum Master должен зарезервировать помещение для команды
•Подготовить начальный список задач (Initial Product Backlog): Product Owner отвечает за создание product backlog items, базируясь на
требованиях, чтобы подготовить начальный список задач.
•Подготовить начальный план для выпуска продукта (Initial Release Plan): Когда все предыдущие шаги выполнены, начальный план
выпуска продукта должен быть подготовлен. Для его создания надо выполнить следующие шаги:
•Scrum Master и Product Owner определяют цель для выпуска продукта
•Сделать предварительные оценки для выполнения задач из Product Backlog
•Scrum Master должен определить возможности проектной команды, с точки зрения выполнения работ
•Product Owner должен назначить приоритеты для элементов из Product Backlog и распределить их по релизам путем отбора тех user
stories (product backlog items) из общего Product Backlog, которые способствуют цели
•Scrum Master отвечает за проведение собрания (Release Planning Meeting)
•Получить предварительную дату выпуска продукта и усилия, необходимые для этого
•Внести изменения в проектный план

Следующие проектные артефакты являются выходами подготовительной стадии:

•План выпуска продукта (начальный)


•Проектный план
•Начальный список задач (Initial Backlog Items)

Котлярова Л.П. 25
Организация и планирование производства ПО 2011 г.

Agile Процессы (2/6)


Спринт процесс

На выходе:
• Скорректированный
список задач продукта
Задачи: • Список незавершенных
• Обзор списка задач продукта задач спринта
• Провести собрание для • Сборка готового кода
На входе: планирования спринта (Product Increment)

• Список задач продукта • Описать или изменить HLD • Скорректированный план


выпуска продукта
• План выпуска продукта • Выполнить ежедневную
работу (см.комментарий для • Скорректированный
• Проектный план видов работ) проектный план
• Провести собрание по • Протокол
результатам спринта ретроспективного обзора
спринта
• Провести ретроспективный
обзор спринта • Презентация для
собрания по результатам
• Выполнить приемочные тесты
спринта
ответственного за продукт
2011 г. Котлярова Л.П. 26

На входе процесса Спринт (Sprint) имеются следующие данные:

•Список задач продукта (Product Backlog)


•План выпуска продукта
•Проектный план

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

•Review Product Backlog (Обзор списка задач продукта): Ответственный за продукт должен отвечать за переназначение приоритетов задач в списке задач продукта и разбивать
крупные задачи (требующие недели до их поставки) на более мелкие (требующие дни для поставки)
•Conduct Sprint Planning Meeting (Провести собрание, посвященное планированию спринта) : Scrum Master должен отвечать за:
•Подсчитать возможности команды для спринта
•Выбрать пункты из Product Backlog, с наибольшими приоритетами, которые должны быть разработаны во время спринта, базируясь на возможности команды
•Установить цель для спринта
•Разбить выбранные пункты из Product Backlog на задачи конкретного спринта (Sprint Backlog Items)
•Оценить сколько займет выполнение пунктов из Sprint Backlog
•Проверить план выпуска продукта и внести изменения, если необходимо.
•Описать или изменить High Level Design (проект высокого уровня) : Разработчик должен определять или изменять HLD. Этот процесс будет рассмотрен на след.слайдах более
подробно.
•Выполнить ежедневную работу (Daily Work): каждый день следующие активности должны выполняться:
• Выполнение общего рабочего процесса: Scrum Master отвечает за проведение ежедневных собраний (Daily Meetings), которые должны ограничиваться 15 минутами.
Разработчики и тестировщики должны создать список задач для Sprint Backlog of Impediment type и в конце дня скорректировать величину оставшихся усилий (Work
Remaining effort) для задач из списка Sprint Backlog Items или Ошибок (Bugs).
• Выполнение управляющего рабочего процесса: Scrum Master отвечает за устранение препятствий, которые могут быть обозначены во время ежедневных
собраний. Scrum Master, Product Owner и представитель команды обязаны участвовать в Triage Meetings (собрания «сортировки»), чтобы рассмотреть изменения Product
Backlog. Если потребуется, то Scrum Master обязан скорректировать списки задач Product и/или Sprint Backlogs.
•Выполнение рабочего процесса разработки: Разработчик будет решать, посредством разработки кода, каждую задачу из Backlog. Этот процесс будет рассмотрен
на след.слайдах более подробно.
•Выполнение рабочего процесса тестирования: Тестировщик будет тестировать каждый элемент из Backlog, определять все ли тесты выполнились успешно или
нет. Этот процесс будет рассмотрен на след.слайдах более подробно.
•Провести Conduct Sprint Review (собрание, посвященное результатам спринта): Scrum Master отвечает за подготовку презентации для этого собрания, а также демонстрацию
имеющейся сборки кода в виде Product Increment demo, провести спринт обзор и выпустить сборку кода, т.е. передать её ответственному за продукт.
•Провести ретроспективный обзор спринта (Sprint Retrospective meeting): Scrum Master обязан подготовить и провести этот обзор
•Выполнить приёмочные тесты, полученные от ответственного за код (?): Product Owner обязан проверить сборку кода и предоставить свои замечания команде. (Все изменения
требований или дефекты помещаются в список задач как Product Backlog Items)

Следующие проектные артефакты являются выходами процесса Спринт:

•Скорректированный список задач продукта (Updated Product Backlog Items)


•Список незавершенных задач спринта (Sprint Backlog Items)
•Сборка кода в виде Product Increment
•Скорректированный план выпуска продукта ( Updated Release Plan)
•Скорректированный проектный план ( Updated Project Plan)
•Протокол ретроспективного обзора спринта
•Обзор спринта – презентация для этого собрания

Котлярова Л.П. 26
Организация и планирование производства ПО 2011 г.

Sprint Planning Meeting

Scrum Sprint planning


Master 1 ЧАСТЬ
• Product Owner представляет
4 часа
Product наиболее приоритетный Product
Owner Backlog максимум
• Команда выбирает задачи, за
которые берется
• Устанавливают цель Спринта
Team
2 ЧАСТЬ
• Решают как достичь цели
4 часа
спринта (design)
Planning макс.
• Создаются задачи
• Оценка задач для спринта
делается сообща, а не только
одним Scrum Master

2011 г. Котлярова Л.П. 27

Котлярова Л.П. 27
Организация и планирование производства ПО 2011 г.

Agile Процессы (3/6)


Ежедневный рабочий процесс разработки

На выходе:
Задачи: • Новый / измененный
• Выбрать задачу или ошибку из списка задач спринта для исходный код
реализации • Новые / измененные unit
На входе:
• Если задача исследовательская, то провести исследование test cases
• Список задач продукта
и скорректировать Sprint Backlog Item • Новая сборка кода (Build)
• План выпуска продукта • Если задача для разработки или исправление ошибки:
• Скорректированный
• Проектный план • кодировать исправление или новую список незавершенных
функциональность задач спринта
• создать и запустить unit test • Скорректированный
список задач продукта
• выполнить code reviews
• интегрировать изменения и запустить локально unit
test suite
• удалить предупреждения компиляции
• добавить код на общую ветку разработки, создать
билд
• документировать детали билда
• убедиться, что билд успешен
• скорретировать конкретный Sprint Backlog Item or Bug
2011 г. Котлярова Л.П. 28

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

•Список задач продукта (Product Backlog)


•План выпуска продукта
•Проектный план

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

•Выбираются задача или найденная ошибка из Sprint Backlog для того, чтобы быть
реализованной. Задача может быть как исследовательская, так и разработческая. Если
задача исследовательская, то исследование должно быть выполнено и затем Sprint Backlog
Item должен быть скорректирован.
Если задача разработческая или это исправление ошибки: решение должно быть
реализовано в коде, проверено unit tests, рассмотрено и интегрировано с общим исходным
кодом, а затем проверено более полным набором unit tests. Также, все предупреждения
компиляции должны быть устранены. Обязательно создать сборку кода (Build), все детали
должны быть записаны и сборка должна быть протестирована. Если билд неудачен, то
задача наивысшего приоритета должна быть создана и как можно скорее реализована.
Когда разработка решения закончена, тогда Sprint backlog Item or Bug должны быть
скорректированы.

Следующие проектные артефакты являются выходами ежедневного рабочего процесса разработки:

•Новый / Измененный исходный код


•Новые / Измененные Unit Test Cases
•Новая сборка кода (build)
•Скорректированный список незавершенных задач спринта (Updated Sprint Backlog Items)
•Скорректированный список задач продукта (Updated Product Backlog Items)

Котлярова Л.П. 28
Организация и планирование производства ПО 2011 г.

Agile Процессы (4/6)


Процесс проектирования

Задачи: На выходе:
• Рассмотреть продуктовые задачи, которые будут • Измененная архитектура /
На входе: разрабатываться на данном спринте High Level Design

• Список задач продукта • Определить изменения, необходимые для их


включенных в спринт реализации в коде
• Конкретные элементы из • Улучшить системную архитектуру / дизайн
списка задач спринта
• Выявить любые проблемы в реализации изменений
• Обсудить подход и изменения для каждой
продуктовой отдельной задачи
• Согласовать предлагаемые изменения в
архитектуре/дизайне со всеми разработчиками, кого
это затрагивает
• Скорректировать задачи спринта
• Проинформировать других разработчиков и
получить согласие

2011 г. Котлярова Л.П. 29

На входе процесса проектирования (Design Process) имеются следующие данные:

•Список задач продукта включенных в спринт (Product Backlog Items Involved)


•Конкретные элементы из списка задач спринта (Sprint Backlog Items)

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

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

Следующие проектные артефакты являются выходами процесса проектирования:

•Измененная архитектура / High Level Design

Котлярова Л.П. 29
Организация и планирование производства ПО 2011 г.

Agile Процессы (5/6)


Ежедневный процесс тестирования

Задачи: На выходе:
• Инсталлировать последний имеющийся билд • Скорректированный
• Определить объем дневного системного тестирования список незавершенных
• Если объем тестирования – верификация ошибок / задач: задач спринта
На входе:
• выбрать задачу или баг для проверки, изменить поле назначения (в • Скорректированный
• Список задач продукта базе ошибок) список задач продукта
• План выпуска продукта • проверить требование или ошибку
• Скорректированный
• изменить поля в базе для проверенного элемента набор тестов для
• Проектный план
• создать тесты для проверки новой или исправленной функциональности регрессионного
• выполнить обзор тестов (test cases review)
тестирования
• Если объем тестирования – регрессионное тестирование:
• выбрать набор тестов для исполнения
• выполнить выбранные тесты
• отчитаться по найденным ошибкам
• создать отчет (Test Log Report)
• Если объем тестирования – Exploratory Test:
• скорректировать Exploratory Test Chart
• выполнить тесты (Exploratory session)
• отчитаться по найденным ошибкам
• создать тесты для проверки новой или исправленной функциональности
• выполнить обзор тестов (test cases review)

2011 г. Котлярова Л.П. 30

На входе ежедневного рабочего процесса тестирования имеются следующие данные:

•Список задач продукта (Product Backlog)


•План выпуска продукта
•Проектный план

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

Тестировщик обязан инсталлировать самый последний имеющийся билд, выбрать объем


ежедневного системного тестирования (например, верифицирование ошибок или задач,
исследовательское или регрессионное тестирование).
Если объем тестирования – это верифицирование ошибок или задач: Задача должна быть
назначена тестировщику команды. Когда задача выбрана, элемент из списка задач спринта или
ошибка должны быть проверены, а затем скорректированы. Если верификация была успешной, то
следующие поля должны быть изменены: State field = Done, Work Remaining Test field = 0 (zero), Work
Remaining field = 0 (zero). Если верификация была неуспешной, то тогда State field = In-Progress.
Тестировщик должен создать тесты (test cases) для верификации новой или исправленной
функциональности для будущего регрессионного тестирования и установить соответствие между
тестами и продуктовыми требованиями, а затем должен рассмотреть (review) тестовые случаи (test
cases).
Если объем тестирования – это регрессионное тестирование: Тестировщик обязан выбрать
набор тестов для исполнения (полный или частичный набор регрессионных тестов). Все тесты
должны быть выполнены, все найденные ошибки должны быть записаны. Результаты тестирования
должны быть представлены в отчете по тестированию (Test Log Report).
Если объем тестирования – это исследовательское тестирование (Exploratory Test):
Тестировщик обязан скорректировать график по этому виду тестирования (Exploratory Test Chart) в
соответствии с новыми требованиями, обязан выполнить тесты (Exploratory session), отчитаться по
найденным ошибкам, создать тестовые случаи для верификации новой или измененной
функциональности для будущих циклов регрессионного тестирования, и установить соответствие
между тестами и продуктовыми требованиями, а затем должен рассмотреть (review) тестовые случаи
(test cases).

Следующие проектные артефакты являются выходами ежедневного рабочего процесса тестирования:

•Скорректированный список незавершенных задач спринта (Updated Sprint Backlog Items)


•Скорректированный список задач продукта (Updated Product Backlog Items)

•Скорректированный набор тестов для регрессионного тестирования ( Updated Regression Test Suite)

Котлярова Л.П. 30
Организация и планирование производства ПО 2011 г.

Agile Процессы (6/6)


Процесс спринта для выпуска продукта (релиза)

На выходе:
• Продукт, переданный
заказчику
Задачи: • Документация,
На входе:
• Провести собрание по планированию относящаяся к продукту
• Собранный и проверенный спринта (Sprint Planning meeting) (Release Notes)
код (Product Increment) от
предыдущего спринта • Выполнить активности, связанные с • Результаты
выпуском релиза ретроспективного обзора
• Список продуктовых спринта
элементов в состоянии • Провести ретроспективный обзор спринта
«Выполнено», относящиеся к • Скорректированный план
конкретному релизу выпуска релизов

2011 г. Котлярова Л.П. 31

На входе процесса выпускающего спринта ( Release Sprint Process) имеются следующие данные:
•Собранный и проверенный код (Product Increment) от предыдущего спринта
•Список продуктовых элементов в состоянии «Выполнено», относящиеся к конкретному релизу

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

Scrum Master обязан провести Sprint Planning Meeting, во время которого следующие задачи
должны быть выполнены:
•Вычислить возможности проектной команды, с точки зрения выполнения работ для спринта
•Выбрать элементы из списка задач продукта (Product Backlog Items). Эти элементы
относятся к активностям по созданию релиза, такие как создание Release Notes,
создание инсталляционных файлов, загрузка данных, пользовательская
документация и т.п.
•Определить цель спринта
•Разбить выбранные элементы из списка задач продукта на более мелкие задачи
конкретного спринта
•Оценить задачи в списке для спринта (Sprint Backlogs Items)
•Рассмотреть план выпусков (релизов) и, если необходимо, скорректировать его
•Запланировать аудиты проекта
После собраний для планирования спринта, активности по подготовке релиза
должны быть выполнены. Члены команды должны выполнить свои обязанности,
ежедневные собрания должны проводиться, аудиты должны быть выполнены.
После релиза ретроспективный обзор спринта (postmortem of the sprint) должен быть
проведен.

Следующие проектные артефакты являются выходами Release Sprint Process:


•Продукт, переданный заказчику
•Документация, относящаяся к продукту (Release Notes)
•Результаты ретроспективного обзора спринта
•Скорректированный план выпуска релизов

Котлярова Л.П. 31
Организация и планирование производства ПО 2011 г.

Метрики

2011 г. Котлярова Л.П. 32

Котлярова Л.П. 32
Организация и планирование производства ПО 2011 г.

Agile Метрики (1/2)

Agile Training March 24, 2012

2011 г. Котлярова Л.П. 33

Here we can find some familiar metrics like

Cost of Poor Quality: Improve the collective action of prevention, appraisal and fault correction processes with
respect to total project cost from the perspective of Senior Management.

Cost of Quality: To track the amount of effort/money associated with poor quality performance. This includes costs to
correct problems discovered by the customer after release, and costs to correct faults discovered internally during the
development process. Poor quality shows up as additional rework costs; as extra test and inspection costs to make sure
rework/fixes meet specifications; and as penalties for late delivery of features or systems that do not meet customer
specified performance levels.

Productivity: To track the productivity of software development from the first project hour logged to a software
development project through M-Gate3 including overhead and prevention activities.

Defect Density Per Release: It shows the number of product backlog items of bug type per release. It shows somehow
the release health. Release will be considered a formal release. (not each sprint)

Effort Estimation Accuracy: Objectively assess the actual effort vs. the estimated effort in order to improve the effort
Estimation, Planning and Control processes.

Test Case Pass / Fail Ratio: This metric gives a measure of the number of test cases that passed the Test Cycle /
regression test cycle. It intends to provide a ratio that reflects how well the test cases are planned, designed and
executed or how well the code is developed.

Test Automation: This metric gives a measure of the number of automated test cases over the whole set of test cases. It
intends to provide a ratio that reflects how many test cases of the whole suite of test cases are automated.

Котлярова Л.П. 33
Организация и планирование производства ПО 2011 г.

Agile Метрики (2/2)

Agile Training March 24, 2012

2011 г. Котлярова Л.П. 34

And here we have the new metrics proposed to track Agile projects:

Sprint Burn Down Chart: Gives the team, a daily indication of their velocity and progress
against the work they have committed to for the current Sprint.

Deferred Ratio: Shows the number of work items deferred per sprint in relation to the total
amount of work items identified for that sprint

Staffing Effort: Shows the number of actual staff hours spent during a sprint categorized by
activity

Bug Fixing Effort Ratio: Shows the number of staff hours burnt in bug fixing during current
sprint compared with the total effort of each sprint.

Enhanced Burn Down Chart: It helps to determine the forecasted completion date taking into
account the velocity of the team and all changes into the product scope.

For a detailed description of Agile Metrics, please refer to Software Measurement Plan in SPP.

Котлярова Л.П. 34
Организация и планирование производства ПО 2011 г.

Back-Up Slides

2011 г. Котлярова Л.П. 35

Котлярова Л.П. 35
Организация и планирование производства ПО 2011 г.

• Scrum Masters, QS
– Подготовительный процесс
• Sprint & Team Capacity Guidelines [Sprint и руководящие
принципы для возможностей команды]
– Sprint process
• Ежедневные митинги
• Triage Process [процесс сортировки задач/ошибок,
установление очередности работ]
• Sprint review
• Sprint retrospective guideline
• Tracking and metrics [отслеживание и метрики]
– Выпуск продукта, релиз

2011 г. Котлярова Л.П. 36

Котлярова Л.П. 36
Организация и планирование производства ПО 2011 г.

• Developers, Scrum Masters


– Design Process (Code, Cont integration and UT)
[процесс разработки]
– Development daily work process [каждодневный
процесс разработки]
– Daily meetings (progress) [как оценивать прогресс
на ежедневных собраниях]
– Review process & Done criteria [процесс обзора и
критерии готовности]

2011 г. Котлярова Л.П. 37

Котлярова Л.П. 37
Организация и планирование производства ПО 2011 г.

• Testers, Scrum Masters


– Test Process [процесс тестирования]
– Exploratory test guidelines [руководство для
исследовательского тестирования]
– Review process & Done criteria [процесс обзора и
критерии готовности]
Scrum Masters, QS
– Quality Topics: Audit Checklists

2011 г. Котлярова Л.П. 38

Котлярова Л.П. 38
Организация и планирование производства ПО 2011 г.

• Developers, Testers, Scrum Masters


– Setting up the Environment Topics [настройка
окружения разработки]
• Product Backlog Management – EPMS – Metrics Book
integration (optional: RequisitePro – Rational Architect)
Product Owner
• The role of the Product Owner in Agile projects

2011 г. Котлярова Л.П. 39

Котлярова Л.П. 39