Английский против Индусского трэша

     В прошлую пятницу я был  на дне рождения одного из моих лучших друзей и по совместительству однокашника  по университету. Было выпито немало пива, текилы, съедено бесчисленное количество пиццы и суши. И вот, во время одного из  тех неприятных моментов, когда очередная башня пива выпита, а следующая еще не появилась на праздничном столе, мой друг пожаловался на то, что времени на английский не хватает. Как только он идет на урок – так обязательно и случается проблема. Система падает, заказчик звонит, босс зовет к себе и т.д. В итоге моему другу удается посещать в среднем 2 занятий в месяц вместо 8 запланированных.

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

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

     Почему я об этом вообще говорю? На недавно прошедшей конференции IT Weekend мне посчастливилось записать фрагмент доклада одного из приглашенных гостей. Помню свое недоумение, когда, зайдя и устроившись удобно в кресле, я долго не мог понять, о чем говорит докладчик из Индии, хотя всегда считал, что с английским у меня все в порядке. Не хочу звучать так же. Запись прилагается ))

     Напрашивается очевидный вывод – повысить приоритет задачи «Учить английский» в собственном бэклоге развития.

Гиперпродуктивность в Скраме

Как появилось понятие Гиперпродуктивности?

Состояние гиперпродуктивности впервые наблюдалось в Тойоте в 80-х годах. Производительность японских заводов была в 4 раза, а качество в 12 раз выше, чем у американских конкурентов. Возникло предположение, что такое же разительное отличие в производительности возможно достичь и в разработке программного обеспечения. Позже в 1993 году, взяв на вооружение принципы Тойоты, Джефф Сазерленд создал первую Скрам команду, которая смогла достичь этого состояния.

Что такое Гиперпродуктивность для Скрама?

Целью Скрама можно назвать достижение «эффекта Тойоты» с помощью спринтов длительностью 1-4 недели.

Гиперпродуктивность в Скраме – состояние команды, в котором велосити в разы (4-8) выше продуктивности традиционной команды. Более того, продуктивность такой команды может быть в несколько раз выше других Скрам команд. Следует сказать, что любая Скрам команда обязана получать двукратную производительность по сравнению с классическим водопадным процессом.

Как достичь состояния Гиперпродуктивности?

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

1. Использование фреймворка Скрама.
2.  Использование XP инженерных практик (Pair Programming, Code Review, Continuous Integration, Test-Driven Development).
3.  Постоянная эволюция продуктового инкремента, частые выходы в публичный релиз, фидбек от конечных пользователей.

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

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

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

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

Будьте максимально продуктивны )))

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

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

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

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

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

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

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

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

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

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

Бьем 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 заказчику.