Организация и планирование проекта по методологии разработки ПО Scrum,роль Developer

Санкт-Петербургский государственный политехнический университет

Институт международных образовательных программ

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

КУРСОВАЯ РАБОТА

Организация и планирование проекта по методологии разработки ПО Scrum,

роль Developer.

Выполнил: студент гр. 4084/11

Преподаватель:

2013

Условие задания

Вводная информация для задания.

1) Вы участвуете в проекте, который разрабатывает программное обеспечение на платформе Windows, используя метод разработки Scrum.

Ваша роль в проекте: Developer (разработчик).

Проектная команда состоит из 3-х человек, включая вас.

2) Программный продукт.

Ваша группа создает новый программный продукт, состоящий из 3-х компонент, причем невозможно сделать сборку продукта (build) для демонстрации свойств продукта, пока не будут готовы хотя бы 2 компоненты.

Известно, что заказчик представит 2 новых требования через 1 неделю и их реализация потребуют не менее 1 недели.

Заказчик очень хочет получить готовый продукт через 5 недель.

Ответственный за продукт и Scrum Master соглашаются с вашими оценками задач, настаивают только на дате релиза, которую нельзя переносить.

Известно, что через 2 недели после начала работы второй разработчик вашего проекта должен пройти плановое медицинское обследование и не сможет участвовать в проекте в течение 4-х дней.

Задачи третьего участника перечислите по своему усмотрению.

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

Пункты задания.

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

2. Как вы считаете, сумеет ли вашу группа выпустить релиз продукта в срок? Обоснуйте ваш ответ.

3. Напишите список ваших обязанностей в проекте; перечислите артефакты, которые вы обязаны готовить. Задачи какого типа вы будете выполнять в данном проекте (разработческие, исследовательские, другие)?

4. Подготовьте шаблон для 1 проектного артефакта (описание правил сборки кода - build report), укажите цель этого артефакта в Scrum разработке, в какие моменты жизненного цикла разработки ПО он изменяется, какой информацией вы будете его наполнять для вашего проекта.

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

6. Какие метрики будут собираться и анализироваться в вашем проекте? Опишите когда и как вы будете анализировать эти метрики, какие действия предпринимать по результатам анализа.

7. Сформулируйте предложения по улучшению работы в проекте (по результатам работы всего проекта или отдельного спринта). Когда вы выскажите эти предложения и кому?

Организация спринтов

Длительность спринтов

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

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

Подготовка артефакта Product Backlog (резерв проекта)

Резерв проекта  — это список требований к функциональности, упорядоченный по их степени важности, подлежащих реализации. Элементы этого списка называются «пожеланиями пользователя» (user story) или элементами резерва (backlog items). Резерв проекта открыт для редактирования для всех участников скрам процесса.

Wikipedia.

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

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

·  Все 3 компоненты примерно равнозначны по сложности их реализации.

·  Мы не знаем, какие конкретно новые требования предъявит нам заказчик в начале 2й недели работы над проектов, но знаем, каких конкретно компонент они будут касаться. (Модель такой ситуации: заказчик – генеральный директор открытого акционерного общества. На предыдущем заседании акционеров была подтверждена необходимость реализации заказанного проекта. На следующем, запланированном на конец первой недели, будет принято решение о двух ключевых особенностях двух компонент проекта). Соответственно к утру следующего рабочего дня (т.е. начало второй недели) после проведения заседания мы будем знать, что конкретно мы должны реализовывать. Но какие компоненты будут затронуты изменениями, мы знаем заранее.

·  Пусть для определенности первоначально у нас есть по 3 пользовательских истории для каждой компоненты. Они составляют базовую функциональность, не очень сложные в реализации, поэтому мы назначим им стоимость в 1 очко. Дополнительные требования, появляющиеся в начале второй недели, составляют ключевую функциональность, сложны в реализации, им мы назначим стоимость в 4 очка. Стоимость объединения компонент – 2 очка.