1. Формирование спринтов.

Одна из основных задач планирования спринта – определение его длины. Какая же длина оптимальна?

Короткие спринты – удобны. Они позволяют компании быть максимально “гибкой”, а значит готовой часто корректировать свои планы. Короткий спринт = короткий цикл обратной связи = частые релизы = быстрые отзывы от клиентов = меньше времени тратится на работу в неправильном направлении = быстрое обучение, совершенствование и т.д.

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

Эксперементальным образом было доказано, что оптимальным является спринт, длинною в 3 недели. Однако, в условиях данной задачи, такое допущение невозможно. В связи с тем, что объем необходимых девелоперских затрат относительно высок в связи со сложностью проекта, длина спринта была установлена как 1,5 недели . Данное условие, ко всему прочему, гарантирует нам полунедельный остаток до релиза, который может учтен как способ предупреждения рисков. Итого, 5-недельный проект был разделен на 3 спринта, длинной в 1,5 недели. Опишем подробнее каждый из спринтов: 1 спринт (1,5 недели)

Обзор списка задач:

• Проведение собрания по планированию спринта (Sprint Planning meeting).

Необходимо сформировать Sprint Backlog, определяющий набор задач, которые надо выполнить, чтобы достигнуть цели конкретного спринта; распределить роли членов команды на данном спринте.

• Описать или изменить HLD

• Проведение ежедневных собраний (Daily Meeting).

Целью собраний являются : обсуждение проблем, попытка совместного принятия решения по проблемам, понимание Scrum-manager-ом и остальными членами команды текущего положения процесса разработки, обсуждение подхода и изменения для каждой

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

архитектуре/дизайне со всеми разработчиками, кого

это затрагивает

• Проведение собрания по результатам спринта (Sprint Review).

Обзор результатов конкретного «спринта».

• Проведение ретроспективного обзора спринта (Sprint Retrospective).

Команда и Scrum Master обсуждают что удалось и что надо улучшить в след. «спринте».

Основные элементы Sprint BackLog:

1. Разработка 1-ого компонента ПО(разработчик A)

2. Разработка unit-tests по 1 компоненту(разработчик С)

3. Разработка 2-ого компонента(разработчик Б)

4. Разработка unit-tests для 2-ого компонента(разработчик С)

5. Разработка unit-tests для интеграции вышеуказанных компонент(разработчик С)

6. Выполнить code reviews(разработчик A,Б)

7. Создать билд(разработчик A)

8. Задокументировать билд(разработчик Б,A,C)

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

Описывая данный спринт, следует отметить тот факт, что через неделю поступают новые требования от заказчика, при этом скрам-мастером редактируется Project Backlog, однако данные требования игнорируются в текущем спринте, становясь задаче спринта 2.

Спринт 2.(1,5 недели)

Обзор списка задач:

• Проведение собрания по планированию спринта (Sprint Planning meeting).

Необходимо сформировать Sprint Backlog, распределить роли

• Выполнение ежедневной работы

• Проведение ежедневных собраний (Daily Meeting).

• Проведение собрания по результатам спринта (Sprint Review).

• Проведение ретроспективного обзора спринта (Sprint Retrospective).

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

Основные элементы Sprint BackLog:

1. Разработка новых изменений внесенных заказчиком в требования на этапе 1-ого спринта (разработчик A)

2. Формирование unit-tests по новой функциональности (разработчик А)

3. Баг-фиксинг первого билда.( разработчик Б)

4. Код-ревью и рефакторинг( разработчик A и разработчик Б)

5. Формирование билда(разработчик A)

6. Документирование билда(разработчик А)

7. Формирование тестов уровня верификации ошибок/задач ( тестировщик C):

• проверить требование или ошибку

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

• выполнить обзор тестов (test cases review)

8. Формирование тестов регрессионного тестирования ( тестировщик С):

• выбрать набор тестов для исполнения

• выполнить выбранные тесты

• отчитаться по найденным ошибкам

• создать отчет (Test Log Report)

9. Формирование Exploratory Tests (тестировщик С)::

• выполнить тесты (Exploratory session)

• отчитаться по найденным ошибкам

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

• выполнить обзор тестов (test cases review)

Отличительной чертой данного спринта является совмещение процесса тестирования с разработкой. Планирование также усложняется невозможностью разработчика Б присутствовать на работе в течение 4 дней. Исходя из этого было сформированы следующие роли: член команды С стал полноправным тестировщиком, вся нагрузка по имплементации новых требований легла на плечи разработчика А, разработчик Б же по выздоровлению занимается багфиксингом первого билда.

Спринт 3 (1,5 недели)

Обзор списка задач:

• Проведение собрания по планированию спринта (Sprint Planning meeting).

Необходимо сформировать Sprint Backlog, распределить роли

• Выполнение ежедневной работы

• Проведение ежедневных собраний (Daily Meeting).

• Проведение собрания по результатам спринта (Sprint Review).

• Проведение ретроспективного обзора спринта (Sprint Retrospective).

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

Основные элементы Sprint BackLog:

1. Разработка 3-го компонента(разработчик А,Б)

2. Разработка unit-test-ов(разработчики А,Б)

3. Формирование тестов уровня верификации ошибок/задач 2-ого билда ( тестировщик C)

4. Багфиксинг 2-ого билда(разработчик Б)

5. Билд 3-го релиза(разработчик А)

6. Формирование тестов уровня верификации ошибок/задач 3-ого релиза ( тестировщик C)

7. Багфиксинг 3-го релиза(разработчки А,Б)

8. Модификация тестов регрессионного тестирования в соотвествии с внедернием 3-ей компоненты (тестирощик С)

9. Модификация Exploratory Tests в соотвествии с внедрением 3-ей компоненты (тестировщик С)

10. Билд 4-ого релиза(финальный) (разработчик А)

11. Документирование Билда (разработчик Б)

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

Остаточные 0.5 недели.

Формируют запас. Защита от рисков.