[55].
• От ценности к полезности и воздействию
Оказывается, ценность часто путают со стоимостью.
Чтобы избежать подобного рода путаницы, можно внести коррективы в терминологию и использовать понятие, распространенное в экономике: полезность46. Полезность – это степень благосостояния или удовлетворения, получаемого от потребления или приобретения товара или услуги [56]. Это понятие шире: не все продукты предназначены для обеспечения финансовой ценности, но все они предназначены для использования. Так, например, обстоит дело с программным обеспечением с открытым исходным кодом.
Impact mapping (глава 15) подсказывает, что следует обратить внимание на воздействие в отношении участников процесса. Вместо того, чтобы опираться на сомнительные оценки, лучше строить гипотезы и как можно раньше их проверять.
Рисунок 18.7 – Тонкая грань между ценностью и полезностью
• В заключение
В Scrum нет определенного индикатора продуктивности, основанного на скорости команды или бизнес-ценности.
Скорость команды в основном используется для более точного прогнозирования, а бизнес-ценность – для расстановки приоритетов.
18.5 Отсутствие индикаторов оценки уровня Agile
Организации, бывает, задаются вопросом: стали ли они Agile? Или, по сравнению с другими, на каком они сейчас уровне Agility?
Иногда сравнивают уровень Agility между разными командами внутри одной организации. Некоторые оценивают применяемые командой практики. Вызывают специалиста – он измеряет внедрение правильных практик, создает графики и получает индикаторы, и таким образом определяет уровень Agility.
Но такой подход не имеет ничего общего со Scrum. Как мы узнали из главы 14 «Контекстуализация Scrum», каждый случай индивидуален. Мы не будем рассматривать никакие индикаторы для мониторинга практик. В духе Agility, скорее, оценка удовлетворенности людей и достигнутых результатов.
Удовлетворенность разработчиков команды отслеживается при помощи ежедневного индикатора настроения. Можно даже привлечь к участию заинтересованные стороны.
В центре нашего обсуждения продуктивности были результаты, и я не думаю, что советовать индикаторы оценки уровня Agility будет хорошей идеей.
Но я совершенно точно рекомендую найти свой путь к достижению Agility. Мы подробнее об этом поговорим в главе 22 «Закрепление Agile-практик».
18.6 Антипаттерны
Ситуация. Традиционная практика управления проектами, заключающаяся в оценке продолжительности выполнения задачи перед началом работы, подсчете реально затраченных часов и анализа разницы, используется командой и после внедрения Scrum.
Последствия. Измерение затраченного времени требует, собственно, времени. Оно ненадежно и приводит к мысли, что цель проекта – в оценивании, а не в создании продукта. Оно способствует узконаправленности в ущерб кроссфункциональности и вредит духу команды.
Наконец, оно не особо помогает. Если даже мы и наблюдаем расхождение между оценкой и фактически затраченными часами, не можем сказать, является это следствием неправильного оценивания, некомпетентности или неверного определения работы.
Как сделать лучше? В Scrum не ведется подсчет часов, потраченных на задачу или историю. Важен сам факт их завершения.
Я часто слышу: зачем вообще делать оценку, если в итоге мы не считаем времени, проведенного за выполнением задачи? Оценка помогает при планировании. Можно делать оценку и без измерения затраченного времени. В Scrum именно так все и происходит. Нас интересует оставшаяся работа, а не подсчет часов. Именно по мере изменения количества оставшейся работы можно принимать решения, касающиеся планирования, – например, корректировать цель спринта, добавлять или убирать истории. Если команда впервые работает в Scrum-формате, скорее всего, некоторые участники с большой неохотой производят оценку. Они боятся, что их могут упрекнуть в качестве оценки, их индивидуальной производительности. Эта тенденция – совершенно естественная: воспринимать оценку как обязательство – уменьшается, если прекратить считать затраченные часы и акцентировать внимание на завершении задач. Может помочь и практика коллективного оценивания.
Ситуация. Команда использует затраченные усилия для калибровки спринта: она оценивает истории на этапе планирования спринта, чтобы определить, сколько влезет в один спринт.
Последствия. Команда тратит время. Скорость команды становится инструментом контроля.
Как сделать лучше? Я не рекомендую практику калибрования скорости команды во время спринта и советую делать больший упор на приверженность цели (см. главу 9 «Планирование спринта»).
Points: оценка усилий или сложности?
На основании чего проводить оценку? Одни считают, что следует подсчитывать вложенные усилия, другие – сложность задачи.
Лучше избегать оценивания на основе приложенных усилий. Мало что можно сказать об усилиях на момент попадания истории в лоток доработки. Подсчет усилий потребует их частого пересмотра, особенно при планировании или даже во время спринта.
После участия в огромном количестве сессий по покеру планирования я могу смело утверждать, что участники чаще всего очень хорошо осознают разницу между относительной трудностью и усилием.
Время, которое требуется для завершения истории (усилие), зависит от технического долга и состава «пчелиного роя», о которых еще ничего не известно на момент оценивания – то есть, вероятно, задолго до реализации. Вот почему оценивание относится только к восприятию сложности одной истории по сравнению с другими. Встает вопрос о повторной оценке, если технический долг увеличивается.
В предыдущем издании я говорил об усилиях, но не о размере. Я изменил мнение после многократного опыта, подкрепленного чтением книги «Exploring Scrum» [Роастхорн, Exploring]. В ней Дэн Роастхорн развил концепцию Рона Джеффриса об относительной сложности.
Оценка размера, основанная на относительной сложности, включает в себя объем информации, которую нужно обработать для одной истории. История может быть простой, но состоять из множества фрагментов. Это не просто техническая сложность. Речь обо всем, что необходимо сделать для завершения истории.
Ситуация. Узнав об индикаторах, бывший менеджер проекта, а ныне Scrum-мастер, с большим рвением составляет всевозможные графики и представляет их руководству.
Последствия. Он тратит много времени за составлением графиков. Некоторые индикаторы предназначены для команды и совершенно бесполезны для заинтересованных сторон – например, burndown-график спринта.
Как сделать лучше? Недостаточно просто составлять графики, нужно понимать, для кого какой индикатор предназначен. Гениальность – в простоте.
Использование небольшого количества самых простых индикаторов способствует прозрачности и позволяет Scrum-мастеру не тратить времени на построение графиков, а затем их объяснение – особенно тем, кто привык к традиционному управлению проектами.
Рисунок 18.8 – Измерение и индикатор
Чтобы идти дальше
Книги
‣ Норман Балларжон, «Petit cours d’autodéfense intellectuelle», издания Lux, 2006. Книга, чтобы научиться считать и правильно толковать индикаторы.
‣ Dan Rawsthorne, Doug Shimp, «Exploring Scrum, The Fundamentals», CreateSpace Independent Publishing Platform, 2011
Онлайн-ресурсы
‣ Избранные статьи, переведенные веб-сообществом Les Traducteurs Agiles; https://www.les-traducteurs-agiles.org/livre-scrum-5ed/
‣ Блог Scrum, Agilité & Rock’n roll: http://www.aubryconseil.com/pages/Livre-Scrum
19Объединение инженерных практик и Scrum
Scrum стал чрезвычайно популярным и бесспорно успешным среди разработчиков программного обеспечения. Но некоторым командам по-прежнему не удается создавать качественные продукты. Речь о тех командах, что внедрили Scrum, позабыв об инженерных практиках.
В сети регулярно появляются колкие, но справедливые комментарии об их важности – например, этот пост @pierreroth64 в Твиттере:
В ином случае это гарантированное кровопролитие и несправедливо ужасная реклама Scrum.
Scrum не сосредоточен на инженерных практиках разработки ПО, их применение совершенно добровольно, ведь Scrum может использоваться и в других областях.
Но для программного обеспечения их применение вызвано самими критериями завершенности, и команда замотивирована ими пользоваться для достижения результата.
Было бы ошибкой полагать, что эти практики являются необязательными и что качество продукта не является целью Scrum. Код должен быть максимально качественным. Scrum несовместим с принципом быстро, но плохо.
Цель этой главы – объединить Scrum с практиками разработки программного обеспечения. Мы обсудим самые распространенные из них и посмотрим, как они вписываются в Scrum-фреймворк.
19.1 Практики, относящиеся к коду
Мы коснемся только тех практик, что появились в Экстремальном Программировании (XP). Однако старые методы разработки – управление версиями, отслеживание правил кодирования, просмотр кода и т. д. – также необходимы для обеспечения качества разработки ПО.
Непрерывная интеграция – это практика разработки программного обеспечения, при которой участники команды часто интегрируют свою работу. Обычно каждый человек проводит интеграцию ежедневно, что означает несколько интеграций в день.