Posts Tagged ‘agile’

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

Posted in Development on June 3rd, 2009 by Yaroslav Vorozhko – Be the first to comment

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

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

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

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

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

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

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

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

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

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

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

Scrum dashboard

В итоге

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

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

Часть 1. Введение в исскуство Unit Тестирования на PHP

Posted in Development on January 15th, 2008 by Yaroslav Vorozhko – Be the first to comment

Автор: padraic
Оригинал: An Introduction to the Art of Unit Testing in PHP
Перевод: Ярослав Ворожко

unit_testing

 

Введение

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

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

Как только блочное тестирование стало популярным, то это стало стандартом для таких приложений как Swiftmailer, Zend Framework и Symfony – все они используют блочное тестирование для проверки исходного кода.

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

От себя добавлю:

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