Записаться

9.1. PERT - оценка сроков

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

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

• Научная обоснованность применения.
• Необходимость наличия статистического репозитория данных по выполнению в альтернативных процессах/проектах.
• Возможность оперативного использования и получения результата.
• Наличие определенного инструментария.
• Прочие.

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

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

PERT (Program Evaluation and Review Technique) - техника проверки и оценки трудоемкости выполняемых работ.

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

• Срок разработки. Под сроком разработки понимается дата к которой необходимо подготовить необходимый программный продукт, его функциональность или отдельную задачу. Срок разработок в реалиях сегодняшнего рынка производства программных продуктов во многом предопределяет качество выполняемых работ и их объем. Когда же мы говорим о гибких процессах разработки программного обеспечения, то оценка сроков работ отходит на второй план, уступая место объему работ и их качеству. Срок разработки замещается понятием спринтов. Заказчик, увидев на демо "работоспособный" результат, готовый к применению, сам определяет, сколько еще спринтов понадобится, чтобы достичь желаемого им качества.
• Качество разработки. Способность поддержать заданное качество программного продукта - качество только самоорганизованных Scrum-команд. Качество программного продукта, заданное командой, зависит от множества различных факторов, но определяется квалификацией членов команды. Однако необходимо помнить, что заказчик, повышая требования к качеству, будет платить за это увеличением сроков работ (количества спринтов).
• Объем выполненных работ. Эта характеристика напрямую связана с показателями качества разрабатываемой информационной системы. Чем выше уровень требуемого качества, тем больший объем работ необходимо реализовать для достижения заданных показателей, а соответственно, больше времени потратить на то, чтобы достичь реализации конечного продукта.

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

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

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

На практике подтверждено, что наиболее точная оценка лежит в рамках относительной погрешности ±5%. Этот допуск является вполне приемлемым для работы по Scrum, но "попасть" в него необходимо как можно более точно. Для этого предлагается к использованию методика PERT, адекватность и обоснованность которой подтверждены не только теоретически, но и на массиве конкретных практических примеров. Метод PERT часто в литературе называют еще и "методом трех точек".

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

• оптимистичная (a);
• ожидаемая (m);
• пессимистичная (b).

И в каждой группе вычисляется среднее значение, отражающее групповую оценку планируемых работ, выраженную в абстрактной или конкретной величине. После того как оценки получены, выполняется их усреднение по достаточно простой формуле (рис. 9.1).

Рис. 9.1.

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

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

9.2. Переход от оценки к обязательствам

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

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

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

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

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

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

• объем работы, которую предстоит выполнить;
• факторы, влияющие на темп выполнения командой работы, и, как следствие, динамика выполнения задач в спринте.

Первоначально при внедрении Scrum практикуется оценка в виде диапазона, затем, по мере зрелости, команда будет в состоянии перейти к точечной оценке, которая будет использоваться в качестве обязательства.

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

Альтернативная ситуация, когда перед командой сразу ставится ответственность по реализации определенного объема к заданной дате, более рискованна и в отдаленной перспективе не принесет желаемых результатов.

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

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

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

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

9.3. Сбалансированная система показателей Scrum-команды

Вариант комплексного взгляда на процессы современной компании привел к созданию сбалансированной системы показателей (ССП).

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

Цель ССП состоит в анализе не столько финансовых метрик функционирования предприятия, сколько в рассмотрении четырех процессных направлений (финансы, клиенты, процессы, обучение и рост), в совокупности представляющих основу деятельности каждого предприятия.

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

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

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

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

• Операционное совершенство:
  • Создание продукта с максимальной производительностью.
• Ориентация на пользователя:
  • Фокус на разработке приоритетных функций.
• Экономическая ценность:
  • Обеспечение ценности в форме экономии затрат, повышения доходов и т. д.
• Ориентация на будущее:
  • Создание новых продуктов также способствует росту и повышению квалификации членов команды.

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

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

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

Следует указать три основных преимущества, которые дает сбор показателей:

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

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

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

9.4. Наработанная статистика результатов - фундамент прогнозирования и побед

Высокая скорость работы команды должна сложиться в соответствии с историческими предпосылками работы команды.

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

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

Для того чтобы задать скорость работы для вновь сформированной команды и заложить основу фундамента оценки, целесообразно собрать фокус-группу из специалистов, обладающих схожим опытом работы с теми, кто включен в Scrum-команду, и задействовать их в оценивании тех задач, которые нужно выполнить. Это поможет направить работу команды в нужное русло. При этом, когда пройдет несколько спринтов, результаты постепенно будут увеличиваться. Таким образом можно преодолеть проблему "втягивания" команды в Scrum.

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

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

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

9.5. Краткие выводы

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

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

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