Джефф Сазерленд - Софт за 30 дней. Как Scrum делает невозможное возможным

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

Таблица 7.1. Опросник

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

Если менеджер согласен с большинством этих утверждений, он, вероятно, сможет использовать Scrum. Это означает, что он не будет полагаться на традиционные методы, которые могут отвлечь команду, снизить ее креативность, инициативу и продуктивность. Он не станет от имени команды принимать обязательства относительно того, сколько они смогут сделать и к какой дате, а затем пытаться убедить команду, что эти обязательства достижимы. Менеджер не будет распределять задачи, рассказывая команде, как ей выполнять свою работу, или подталкивать членов команды работать так, чтобы исполнить обязательства, взятые на себя менеджером. Короче говоря, дилемма в том, что сейчас вы знаете одно, а должны действовать по-другому. Дилемма в том, чтобы меняться с помощью интеллектуального понимания своих действий день за днем.

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

Эти показатели объединены на общей инструментальной панели студии, которая отслеживает историю проектов и отражает тенденции. Эти показатели используются и для оценки затрат и прибыли студии, и для оценки финансирования ее необходимого развития. Руководство организации может использовать совокупные показатели для определения общей рентабельности инвестиций (ROI) студии и решить, должно ли быть применение студии расширено или сжато. Рисунок 7.2 показывает первичные показатели на инструментальной панели студии. Каждый может иметь много подчиненных показателей.

Рис. 7.2. Инструментальная панель проекта

1. Продуктивность – это количество единиц бизнес-функционала, которое разработано на определенное количество денег (например, на 100 тысяч долларов инвестиций). Продуктивность также называют скоростью. Это показатель не ценности, а только количества произведенного функционала. Изначально произвольная единица функционала определяется и измеряется. Размер измеряется в функциональных точках, объективной и абстрактной системе измерений для программного обеспечения [8]. Функциональные точки универсальны и могут быть применены везде в пределах системы, продукта или для любой другой системы. Весь другой функционал определяется относительно базовой единицы. Эта система измерений (измерение размера единицы функционала в функциональных точках) становится стандартным показателем студии. Базовая единица требует периодической калибровки, чтобы гарантировать ее соответствие.

2. Качество измеряется в дефектах по отношению к стандартному размеру единицы работы в студии. Scrum-команда разрабатывает инкременты функционала программного обеспечения. Когда владелец продукта хочет реализовать этот функционал, количество дефектов подсчитывается со дня, когда единица функционала передается владельцу продукта, до трех месяцев его использования.

3. Ценность – мера того, насколько ценен созданный функционал для организации. Это мера эффективности (в процентах) от каждого доллара, потраченного на разработку программного обеспечения, которая создает ценность для организации. Показатель ценности не включает рыночную ценность. Рыночная ценность отражает показатель ROI, о котором мы не станем говорить в рамках этой книги. В среднем в общем уровне затрат на создание ценности в организации на разработку программного обеспечения затрачивается меньше 10 % от каждого доллара. Значительный процент расходуется на поддержание и сохранение существующих систем. Также большое количество средств идет на разработку функционала, который используется не очень часто. Б о льшая часть денег тратится на создание программного обеспечения, которое могло быть полезным где угодно, но не в пределах организации, которая за него платит.