Все о SCRUM. Изучение, разработка, интеграция

Но такой подход не имеет ничего общего со Scrum. Как мы узнали из главы 14 «Контекстуализация Scrum», каждый случай индивидуален. Мы не будем рассматривать никакие индикаторы для мониторинга практик. В духе Agility, скорее, оценка удовлетворенности людей и достигнутых результатов.

Удовлетворенность разработчиков команды отслеживается при помощи ежедневного индикатора настроения. Можно даже привлечь к участию заинтересованные стороны.

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

Но я совершенно точно рекомендую найти свой путь к достижению Agility. Мы подробнее об этом поговорим в главе 22 «Закрепление Agile-практик».

18.6 Антипаттерны

18.6.1 Измерение затраченного времени

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

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

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

Как сделать лучше? В Scrum не ведется подсчет часов, потраченных на задачу или историю. Важен сам факт их завершения.

Я часто слышу: зачем вообще делать оценку, если в итоге мы не считаем времени, проведенного за выполнением задачи? Оценка помогает при планировании. Можно делать оценку и без измерения затраченного времени. В Scrum именно так все и происходит. Нас интересует оставшаяся работа, а не подсчет часов. Именно по мере изменения количества оставшейся работы можно принимать решения, касающиеся планирования, – например, корректировать цель спринта, добавлять или убирать истории. Если команда впервые работает в Scrum-формате, скорее всего, некоторые участники с большой неохотой производят оценку. Они боятся, что их могут упрекнуть в качестве оценки, их индивидуальной производительности. Эта тенденция – совершенно естественная: воспринимать оценку как обязательство – уменьшается, если прекратить считать затраченные часы и акцентировать внимание на завершении задач. Может помочь и практика коллективного оценивания.

18.6.2 Оценка усилий

Ситуация. Команда использует затраченные усилия для калибровки спринта: она оценивает истории на этапе планирования спринта, чтобы определить, сколько влезет в один спринт.

Последствия. Команда тратит время. Скорость команды становится инструментом контроля.

Как сделать лучше? Я не рекомендую практику калибрования скорости команды во время спринта и советую делать больший упор на приверженность цели (см. главу 9 «Планирование спринта»).

Points: оценка усилий или сложности?

На основании чего проводить оценку? Одни считают, что следует подсчитывать вложенные усилия, другие – сложность задачи.

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

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