Оценка

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 9.1.

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

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