Опубликован: 24.02.2017 | Доступ: свободный | Студентов: 1153 / 177 | Длительность: 10:06:00
Лекция 9:

Оценка

< Лекция 8 || Лекция 9: 12 || Лекция 10 >
Аннотация: Девятая глава будет описывать техники и методики оценки работ, выполняемых успешными Scrum-командами при работе над созданием программного продукта. Успешная оценка сроков необходимых работ и последующие обязательства по их исполнению позволят заложить прочный фундамент надежных и доверительных отношений между командой и бизнес-пользователями, заинтересованными в разработке эффективной информационной системы. При этом каждая команда должна иметь собственную систему оценки их деятельности, которая будет способствовать как увеличению ценности создаваемого продукта, так и развитию команды и ее членов. Одним из дополнительных преимуществ точной оценки выполняемых активностей является создание и пополнение статистического репозитория данных производительности команды, на основе которого будет возможно прогнозировать и управлять темпом Scrum. Именно об оценке, системе показателей и возможности прогнозировать производительность команды будет рассказано в этой главе.

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 "вписать" в любую организационную структуру и наладить тесное сосуществование различных методик управления процессной деятельностью.

< Лекция 8 || Лекция 9: 12 || Лекция 10 >
Александр Борисенко
Александр Борисенко

Мне кажется, или курс сыроват. При прочтении обнаруживается ощущения размытости, неточностей и прочего в том же роде. Например - "ЦФО - центр финансовых затрат" в пункте 2.4. Это как понимать? "О" - это расшифровывается как "затрат"? Как-то довольно много воды. Кстати, почему нет ссылок на глоссарий? Только сейчас обратил внимание, что он есть. Поначалу очень удивился почему столько английских терминов без расшифровки

Алексей Щербаков
Алексей Щербаков
Россия