2. 2
2
Scrum
Scrum (схватка вокруг мяча из терминологии игры регби).
Scrum – модель жизненного цикла и метод управления
проектами по разработке ПО.
Особенностью метода является вовлеченность абсолютно
всех его участников с назначением особых ролей для
каждого. Те, кто непосредственно заинтересованы в
конечном продукте, не просто распределяют обязанности и
контролируют процесс выполнения, они постоянно
находятся с командой и «работают» с ней.
3. 3
3
Scrum. Терминология
Владелец продукта (Product owner) – это тот человек,
который непосредственно заинтересован в качественном
конечном продукте. Он имеет четкое представление о том,
как должен выглядеть продукт и какие шаги должны быть
предприняты для реализации проекта по разработке
продукта. Он распределяет задачи для команды и работает
с ней, но сам находиться на стороне заказчика.
Scrum-мастер (Scrum master) – руководитель проекта.
Руководит разработкой и следит за соблюдением принципов
Scrum.
Scrum-команда (team)– команда разработчиков ПО,
которые знают и понимают принципы Scrum.
4. 4
4
Scrum. Терминология
Спринт – временной отрезок, выбранный для
выполнения определенного количества работ.
Рекомендованное время – 2-4 недели, но все
определяется индивидуально командой и один раз.
Бэклог (backlog) – полный перечень всех работ, которые
необходимо выполнить.
Бэклог делится на два вида.
5. 5
5
Scrum. Терминология
Product-бэклог – это список всех требований и
соответствующих работ, которые нужно сделать по
проекту, которые непосредственно приведут команду к
конечной цели.
Когда в Backlog’e нет требований, проект считается
завершенным.
Все требования описаны по единому шаблону, который
называют User Story (пользовательская история).
Требования составлены так, что очевидно и понятно,
какую ценность они представляют для пользователя
Требования отсортированы по приоритетам, которые
пересматриваются каждый спринт.
6. 6
6
Scrum. Терминология
Спринт-бэклог (Sprint Backlog) – те требования и
соответствующие работы из product-бэклога, которые
команда определила и согласовала с владельцем
продукта на ближайший спринт, а также установила
конкретные временные рамки.
В течение спринта, новые требования не могут
появится в Sprint backlog.
Все требования должны быть разделены на задачи и
оценены. Задачи, должны быть представлены на
Kanban-доске.
Sprint Backlog – это обязательство команды: что они
должны выполнить за время спринта.
7. 7
7
Scrum. Терминология
Канбан-доска должна состоять как минимум из трех колонок:
«сделать» (to-do), «в процессе» (in progress), «сделано»(done).
При разработке по SCRUM канбан-доска может включать следующие
колонки в соответствии со статусом задач: обсуждается (backlog),
согласовано (ready), кодируется (coding), тестируется (testing),
подтверждается (approval) и сделано (done). На доску в
соответствующий столбец прикрепляются канбан-карточки
8. 8
8
Scrum. Терминология
Цель спринта (Sprint Goal) - это краткое описание того,
ради чего выполняется данный спринт. Цель спринта
помогает команде принимать обоснованные решения.
Этот артефакт необходим для того, чтобы команда
проекта могла самостоятельно принимать решение в
случае появления альтернативных путей решения задачи.
Чтобы решения команды были осознанными, владелец
продукта определяет цель спринта.
Диаграмма сгорания (Sprint Burndown Chart).
Показывает прогресс насколько команда продвинулась
вперед. В качестве “сгорающих” элементов выступают
человеко-часы или идеальные единицы (Story Points).
Диаграмма обновляется каждый раз, когда завершается
какая-либо задача.
10. 10
10
Scrum. Процессы
Планирование спринта (Sprint Planning Meeting) –
совещание всей Scrum-команды, владельца продукта и
Scrum-мастера.
Владелец продукта определяет цель спринта и конечные
задачи, которые должны быть выполнены по истечению
срока спринта;
Команда выбирает требования из Product Backlog и
формирует Sprint Backlog;
Команда декомпозирует требования на задачи (tasks);
Каждая задача проходит оценку в трудозатратах или
универсальных единицах по методу Planning Poker;
Итоговый список задач утверждается всеми участниками и
не может быть изменен в течение спринта;
Во время встречи Владелец продукта отвечает на вопросы
команды.
11. 11
11
Scrum. Процессы
Ежедневная встреча команды (Daily Meeting):
проходит ежедневно и только в одно и то же время;
встреча проходит только стоя;
поэтому длительность встречи не более 15 минут;
чтобы успеть каждый должен ответить всего на 3 вопроса:
что я делал вчера, чем я занимаюсь сегодня, какие есть
проблемы?
На ежедневной встрече команда обменивается опытом. Также
становится понятно, кто и над какими задачами будет сегодня
трудиться. Важно, чтобы команда делала это самостоятельно.
Scrum Master следит за ходом встречи, побуждает участников
высказываться полностью и слушать говорящего.
Встречу команды эффективно проводить напротив Kanban
доски, на которой отражены все задачи спринта.
12. 12
12
Scrum. Процессы
Cдача спринта владельцу продукта (Product Owner
Sprint Review)
По завершению каждого спринта команда обязана
провести демонстрацию полученного результата.
Ценность Scrum для обычного заказчика во многом
состоит в том, что результат работ (плохой или хороший)
будет продемонстрирован в любом случае. Это знает и
команда и владелец продукта и другие заинтересованные
лица. Если команда не проводит демонстрацию (иное
название Sprint Review), то это дискредитирует все
преимущества гибких процессов.
13. 13
13
Scrum. Процессы
Повестка встречи Sprint Review:
команда зачитывает требования из Sprint Backlog;
по каждому критерию приемки происходит
демонстрация полученных результатов;
каждый вопрос со стороны владельца продукта
записывается, чтобы иметь возможность ответить на
них позже;
каждое новое требование владельца продукта
выписывается, чтобы позже включить его в Product
Backlog.
На встрече могут присутствовать любые сотрудники
организации или просто заинтересованные лица, но
право голоса должны иметь только участники Scrum
процесса (Produt Owner, Team, Scrum Master).
14. 14
14
Scrum. Процессы
Ретроспективное совещание (Retrospective)
Необходимо для обмена опытом внутри команды.
Совещание проводится после Sprint Review.
На совещании присутствует вся команда и Scrum Master
(Владелец продукта присутствует, если считает нужным).
Методика проведения встречи варьируется в зависимости
от проекта, его команды и просто традиций в коллективе.
15. 15
15
Scrum. Процессы
В любом случае, должны быть озвучены ответы на
следующие вопросы:
1. Какие решения должна принять команда, чтобы
сделать процесс более предсказуемым?
2. Какие проблемы мешают команде выполнять взятые
на себя обязательства?
3. Как улучшить взаимодействие с Владелецом
продукта?
4. Какие ошибки совершает команда и почему.
Решения должны быть записаны на отдельной доске.
После всеобщего голосования решения принимаются к
исполнению со следующего спринта. Scrum Master
контролирует ход встречи и следит за её регламентом.
16. 16
16
Scrum. Процессы
Груминг беклога (Grooming)
Беклог продкута отправляется в «парикмахерскую» для
того, чтобы команда и владелец продукта могли:
1. Добавить, убрать или разбить элементы беклога
продукта.
2. Уточнить или дать новые оценки.
3. Изменить порядок следования элементов беклога
продукта.
4. Обсудить и прояснить требования.
18. 18
18
Модель быстрой разработки приложений
RAD
RAD (Rapid Application Development) модель
относится к итерационной стратегии.
В RAD-модели компоненты или функции
разрабатываются параллельно несколькими
высококвалифицированными командами, будто
несколько мини-проектов. Временные рамки одного
цикла жестко ограничены. Созданные модули затем
интегрируются в один рабочий прототип.
19. 19
19
Модель быстрой разработки приложений RAD
Условия, позволяющие создать систему за 60 - 90 дней,
причем без ущерба качеству, включают в себя:
1. Полностью определенные требования;
2. Обязательность вовлечения пользователей в процесс разраб
отки;
3. Ограниченность проектной области, возможность
декомпозиции будущего ПО на отдельные модули;
4. Высокий уровень фактора повторного использования
компонент использование мощных инструментальных
средств разработки;
5. Тестирование и развитие проекта, осуществляется одноврем
енно с разработкой;
6. Команде, работающей над проектом, знакома предметная
область, и она обладает достаточными навыками в
использовании средств разработки и имеет высокую степень
мотивации при выполнении данного проекта.
20. 20
20
Модель быстрой разработки приложений RAD
7. Модель применима для относительно небольших
проектов, разрабатываемых под конкретного
заказчика;
8. Неприменима для построения сложных расчетных
программ, требующих написания большого объема
уникального кода;
9. Неприменима для разработки приложений, от которых
зависит безопасность людей, так как итеративный
подход предполагает, что первые несколько версий,
скорее всего не будут полностью работоспособны, что
в данном случае исключается.
