2)Обоснование возможности выпуска релиза в срок.

Я считаю, что команда может уложиться в выполнении проекта в срок, связано это с удачным выбором методики планирования и учетом рисков.

Основной из причин, по которым программные проекты оказываются провальными и выходят за дедлайны- являются регулярные смены требований со стороны заказчика. Методология Scrum является одной из наиболее гибких, которая позволяет быстро пересмотреть видение проекта ,и «безболезненно» внедрять новые требования.

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

Введение приоритетности задач(в 1 билд вошли самые важные 2 компонента) позволило нам раньше отправить в тестирование самую сложную функциональность(несущую основную смысловую нагрузку) , а соответственно повысить качество выпускаемого ПО, уменьшив количество багов в финальном билде.

Также следует отметить присутствие резерва во времени, что допускает факт задержки спринта. Если же никаких эксцессов не произойдет, проект может закончится и раньше срока.

3. Описание моей роли в проекте.

Типы задач, выполняемые разработчиком:

• Исследовательские

• Разработческие

• Организационные

Обязанности разработчика:

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

• Выполнять обзоры кода

• Создавать сборки кода (билды) и хранить их в базе конфигураций проекта

• Участвовать в собраниях проекта (Daily, Sprint Planning, Sprint Review and Sprint Retrospective meetings)

• Сообщать о любых препятствиях, мешающих работе

• Отчитываться о затраченных усилиях (оставшаяся работа на конец дня)

Артефакты, которые я обязана готовить:

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

• Новые / измененные unit test cases

• Новая сборка кода (Build)

• Скорректированный список незавершенных задач спринта

• Скорректированный список задач продукта

3. Описание правил сборки кода build report

Build report- артефакт , необходимый заказчику и тестировщику для контроля попавших в билд изменений.

Что должно фиксироваться?

• Идентификатор билда, дата билда, создатель билда

• Список изменений, внесенных в предыдущий билд

• Список требований заказчика реализованных/нереализованных, вошедших/ невошедших билд

• Список уже обнаруженных ошибок

• Описание необходимых конфигураций

• Описание системных требований

Создается после каждой новой сборки билда, т.е. на любом спринте.

3. Возможные риски проекта

Риски:

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

Решение:

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

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

Решение:

• Разработчик, который должен по плану заниматься исправлением ошибок будет тратить половину времени на поиск ошибок, половину на исправление и таким образом сможет подменить своего нетрудоспособного коллегу.

• Заказчик может вносить изменения в требования не только после первой недели.

Решение:

• Договориться заранее о перенесении времени релиза на количество дней, необходимое для реализации новых требований, не оговоренных заранее.

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