Опубликован: 24.02.2017 | Доступ: свободный | Студентов: 1086 / 164 | Длительность: 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. Это как понимать? "О" - это расшифровывается как "затрат"? Как-то довольно много воды. Кстати, почему нет ссылок на глоссарий? Только сейчас обратил внимание, что он есть. Поначалу очень удивился почему столько английских терминов без расшифровки

Дмитрий Марушко
Дмитрий Марушко
Беларусь, Минск
Александр Юрченко
Александр Юрченко
Россия, г. Москва