Измерение скорости разработки по фазам

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

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

Для 100% кросс-функциональной команды, где разработчик = тестировщик = аналитик, это наверное не так важно - если анализ требований будет не успевать, остальные накинутся и помогут. Но много ли таких команд вы знаете?

(далее рассуждаем, приняв эффективность аналитической деятельности 1 разработчика меньше эффективности такой же деятельности 1 аналитика)

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

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

А burndown продолжает показывать, что все в норме!

Вот здесь и поможет еще один показатель, требуемая скорость разработки по фазам - если у нас осталось работ, например на анализ, больше чем физически доступно времени аналитиков, то загорится красная лампочка и нам придется вовремя обратить на нее внимание.

Вот например в DEVPROM такой показатель измеряется и всегда доступен команде рядом с burndown графиком.

Снова в блог и немного новостей

Давно что-то не получалось писать, хочется наконец это исправить :)

Из прошедшего за последнее время:

• Сменил место работы, чему несказанно рад - теперь руковожу проектами в замечательной компании Rapidsoft. Постоянное движение, ребята давно смотрят в сторону гибких методологий - в общем, работать одно удовольствие!


• В феврале читал двухдневный тренинг по Test Driven Development в Одессе для одной небольшой распределенной команды - долго не мог найти подходящие слова, чтобы написать о нем.. так и не написал в итоге :)
  
  Скажу только пару слов - замечательная команда, отличные ребята и супер организация тренинга (пить кофе по утрам на балконе особняка с видом на море это конечно незабываемо).
  
  А вообще, далеко не каждому по силам удаленно собрать такую мощную и слаженную команду.


• После тренинга полетел в Сибирь, Шерегеш, где неожиданно оказалось -35-25 и были совершенно пустынные склоны и лес - кататься одно удовольствие, главное пуховик потолще надеть.


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

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

  
  

Из грядущего - 9 апреля вечером буду рассказывать и показывать на мастер-классе все прелести управления требованиями в DEVPROM.

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

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