Professional Scrum Master (PSM)

Professional Scrum Master (PSM)
Professional Scrum Master (PSM)

воскресенье, 23 сентября 2012 г.

Метрика Счастья












      Недавно я набрел на интересную, на мой взгляд, метрику - Метрику Счастья. Первым применение этой метрики описал Генрик Книберг в своем блоге. Ее можно довольно успешно использовать как индикатор Здоровья проекта, и компании в целом. 
      Метрика довольно проста в использовании. Необходимо постоянно отслеживать Индекс Счастья (может колебаться от 1 до 5). Это можно заниматься , к примеру, на каждой ретроспективе. Как вариант, можно просить людей обновлять свой Индекс Счастья раз в месяц в Гугл документе.

      Интересная закономерность, найденная Книбергом, показывает, что:  

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

…И так далее, и снова по кругу.

      Метрика Счастья постоянно отслеживается в команде, и если у кого-то индекс падает ниже 3 - это тревожный сигнал, который требует немедленного реагирования. Мы считаем это препятствием (Impediment) и выносим его на ретроспективу. Книберг использует эту метрику как ведущую в своей компании Crisp.

      Джефф Сазерленд применил Метрику Счастья в компании ScrumInc и утверждает, что благодаря этому прирост Велосити составил 500%, а Net Revenue - 200%. Сазерленд предлагает отслеживать 2 Индекса Счастья – для проекта и для компании одновременно.

      Интересное дополнение – изменение индекса можно визуализировать и отображать на графике, будет видно, как Счастье прибывает и убывает со временем.

Будьте Счастливы!

вторник, 18 сентября 2012 г.

Бьем Backlog по-новому


В течение долгого времени вопрос о еденицах измерения User Story и Tasks мог застать врасплох разве что новичка в Agile. Действительно, ответ кажется очевидным: в Backlog живут User Story, и оцениваем мы их в Story Points. Далее, User Stories разбиваются на таски, которые оцениваются в часах. Best practice было разбиение таким образом, чтобы на каждую таску затрачивалось не более 8 часов.

Данную концепцию можно найти в классической книге Майка Кона "Agile Estimating and Planning" 

Джефф Сазерленд в своем блоге описывает три подхода в оценке.
  1. Оцениваем User Story в Story Points и не используем таски.
  2. Оцениваем User Story и таски в Story Points.
  3. Оцениваем User Story в Story Points, таски - в часах (старый подход).
Сазерленд утверждает, что первый подход характерен только для гиперпродуктивных команд.

Они способны бить Backlog на User Story примерно одного размера - не более 8 часов работы. Следовательно, нет необходимости в дальнейшем создании тасок. Burndown Chart ведется на уровне историй. В нем горят Story Points.  

Это очень удобно, ведь используя старый подход и сжигая часы на Burndown Chart, мы не совсем точно отслеживаем прогресс команды. Задачи выполняются, график сгорает, но настоящего Value команда еще не принесла, пока не сгорят все задачи из каждой User Story.

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