Интеграция SCRUM и Eventum или идеи по улучшению процесса разработки ПО
Это руководство написано для компаний которые активно используют Eventum и у которых есть желание перейти на гибкие методики разработки ПО, например на SCRUM.
Проблема: слабый график разработки ПО, не гибкий подхода к назначению приоритетов для задач, трудно оценить эффективность каждого и производительность всей команды разработчиков.
Отсутствие статистических данных по прошедшим этапам разработки, таким как: прогнозируемое время выполнения задачи, реальное время выполнения, эффективность и производительность прошлых этапов.
Цель перехода на SCRUM: повысить эффективность разработки, увеличить производительность команды и знать насколько производительна команда, что важно для оценки будущих проектов.
Как показали данные исследований различных софтверных компаний, то те компании которые перешли на современные и проверенные методологии разработки ПО повысили свою эффективность и производительность на 50% и более процентов, а некоторые достигли шести кратного увеличения производительности команд.
SCRUM является одной из таких современный и проверенных методик разработки.
Узнать что такое SCRUM и XP вы можете посетив следующие веб-ресурсы:
- Scrum and XP from the Trenches
- Тоже самое но на русском
- Wiki scrum )
- Agile manifesto
- Short intoduction into Scrum
- What is xp in short
Прежде чем читать дальше я советую ознакомиться со SCRUM на выше перечисленных ресурсах, иначе в этой статье многое будет вам не понятно.
Описывать как работать с Eventum я не буду, вы можете прочитать об этом на их официальной странице http://eventum.mysql.org/wiki/index.php/Main_Page.
Внедряем SCRUM в существующий процесс разработки
Для этого потребуются некоторые изменения:
- ведения задач в Eventum;
- подсчета времени;
- планирования этапов разработки.
Требования:
- Наличие Backlog;
- Наличие Sprintlog;
- Наличие Tasklog;
- Планирование спринта (Sprintlog);
- Ежедневные конференции;
- Sprint Information.
- Sprint report;
Backlog и Sprintlog
Backlog и Sprintlog — это отдельный Eventum project (скажем Project_Log), который будет содержать все истории для реализации.
История — это не техническое описание задачи. Истории в Backlog заносит владелец продукта. Он же меняет им приоритеты сортирую истории по важности.
Истории помеченные номером спринта владелец продукта менять уже не может.
Все истории в Project_Log будут представлять наш Backlog, при каждом планировании спринта самые важные истории помечаются на выполнение в спринте (специальным номером спринта) и таким образом мы формируем Sprintlog. Номер спринта поможет нам отличать истории текущего спринта от всех остальных.
Каждая история в backlog/sprintlog должна иметь следующие поля:
- номер спринта (поле Category или Custom field) — для указания номера спринта к которому принадлежит история, если история не принадлежит ни одному спринту, то это поле не заполняется. ;
- название (поле Summary);
- описание (поле Description)
- важность (поле Custom field);
- предварительная оценка (поле est. dev time);
- как продемонстрировать(поле Custom field или поле Description);
В Eventum есть специальная возможность создавать «произвольные поля» Custom fields, что добавлет большой гибкости этой системе.
Номер спринта указываться только тогда, когда история включается в спринт.
Предварительная оценка ставиться владельцем продукта.
Поле «как продемонстрировать» заполняется программистами.
Список историй в Backlog/Sprintlog может выглядеть следующим образом:
- Номер спринта
- Номер истории
- Статус — (Планируется, В процессе, Завершена)
- Название истории
- Важность
- Как продемонстрировать
- Предварительная оценка
- Предварительная дата завершения истории
Во время планирования спринта заполняются следующие поля:
- Номер спринта
- Предварительная дата завершения истории
scrum backlog
Tasklog
Tasklog — является еще одним проектом Eventum (например с названием Projects_task).
Tasklog содержит список технических задач, который создаются на основе историй из Sprintlog.
С помощью поля Associated issues, каждая задача в Tasklog помечается как дочерняя по отношению к истории из Sprintlog. И главное в SCRUM — задачи в Tasklog составляют программисты.
Tasklog список выглядит следующим образом:
- Номер задачи
- Статус — Открыта, Выполняется, Сделана.
- Название задачи
- Assigned — кто ответственен за выполнение
- Estimate dev time — Предварительная оценка времени
- Time spent — Потраченное время
Estimate dev time должно обязательно заполнятся при создании задачи.
Time spent должно обязательно указываться после каждого цикла работ над задачей.
Scrum task log
Планирование спринта
Планирование спринта выполняется каждый раз перед началом следующей итерации разработки, обычно каждые 2-3 недели в зависимости от длины спринта.
На планировании определяются истории которые войдут в следующий sprint и оценка трудозатрат на каждую историю. Оценка делается для того, чтоб определить сколько историй включать в спринт.
Оценку проводит вся команда. После начала спринта, в sprintlog новые задачи уже не вносятся и не убираются.
В итоге получается план работ на следующие 2-3 недели. Что является большим плюсом.
Задачи в Sprintlog беруться из Backlog по приоритету важности, чем важнее задача тем быстрее она попадет в следующий спринт.
Задачи вошедшие в спринт нужно помечать номером спринта, таким образом мы можем отделять задачи SprintLog от задач BackLog.
Каждая задача в Sprintlog имеет свои подзадачи в Tasklog, задачи из Tasklog решаются непосредственно программистами, дизайнерами, тестерами.
Ежедневные конференции
Ежедневные конференции требуются для обсуждения текущих задач.
Sprint information
Sprint info — это список всех прошедших спринтов, он соджержит:
- номер спринта
- название
- прогнозируемое время выполнения
- реальное время выполнения
- общую эффективность команды
- участников команды
Для ведения Sprint info хватит обычной wiki.
Sprint report
Sprint report — это текущее состояние дел по текущему спринту.
Scrum dashboard
В итоге
В итоге мы получаем:
- Спланированный график работ
- Каждый знает что ему делать
- Есть дата окончания спринта — следующего релиза
- По оценке предыдущих спринтов мы будем знать эффективность нашей команды и каждого ее участника в отдельности, это даст нам возможность планировать нашу работу более точно в будущем
- В конце каждого спринта каждый участник должен продемонстрировать выполненное им задание, что требует от разработчиков дополнительной ответственности за выполнения задания. Демонстрация проводится перед все командой.
© Yaroslav Vorozhko for , 2009. |
|
|
Add to
Post tags: , , ,
Комментариев нет:
Отправить комментарий