Мастерство программирования

Интеграция SCRUM и Eventum или идеи по улучшению процесса разработки ПО

Это руководство написано для компаний которые активно используют Eventum и у которых есть желание перейти на гибкие методики разработки ПО, например на SCRUM.

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

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

Цель перехода на SCRUM: повысить эффективность разработки, увеличить производительность команды и знать насколько производительна команда, что важно для оценки будущих проектов.

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

SCRUM является одной из таких современный и проверенных методик разработки.

Узнать что такое SCRUM и XP вы можете посетив следующие веб-ресурсы:

• Scrum and XP from the Trenches http://www.infoq.com/minibooks/scrum-xp-from-the-trenches
• Тоже самое но на русском http://scrum.org.ua/scrum-i-xp-zametki-s-peredovoj/
• Wiki scrum http://en.wikipedia.org/wiki/Scrum_(development)
• Agile manifesto http://agilemanifesto.org/
• Short intoduction into Scrum http://www.mountaingoatsoftware.com/scrum
• What is xp in short http://www.xprogramming.com/xpmag/whatisxp.htm

Прежде чем читать дальше я советую ознакомиться со 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

В итоге

В итоге мы получаем:

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

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

Карл Вигерс. Разработка требований к программному обеспечению

Точно также для проекта по рарзаботке ПО следует определить его рамки и ограничения. Вам необходимо указать, что может делать система, а что не может.

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

Объем первоночальной версии ProductSearch

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

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

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

Read more »

Образ проекта обеспечивает основу для принятия решений в течении жизненного цикла продукта.

Карл Вигерс. Разработка требований к программному обеспечению

Положение об образе проекта

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

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

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

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

Основные функции

• Поиск продуктов;
• Сравнение двух и более продуктов;
• Возможность проследить история изменения цены продукта;
• Возможность создать и просмотреть отзывы о продукте;
• Выбор лучшего поставщика продукта по параметру цена-качество;
• Регистрация поставщиков;
• Добавление потока продуктов поставщиками;
• Аналитические отчеты для поставщиков.