в облаке
Попробовать

Это трудоемкость, а не сложность

17.04.2015 08:01

Клиент спросил меня: «Когда твоя команда закончит проект?» Это, наверное, миллиардный раз, когда мне задали этот вопрос в сфере гибкого управления проектами в том или ином виде. И ни разу меня не спрашивали: «Насколько усердно твоя команда планирует работать над этим проектом?» Клиенты, руководство, заказчики, ключевые фигуры проекта - всем важно, сколько времени он займет. Их не волнует, сколько усилий мы думаем приложить, разве что в той степени, в какой это влияет на график или влечет риск затрат.

Я упомянул это, потому что обнаружил, что слишком много команд полагает, что единицы истории (Story Points) нужно считать, исходя из сложности пользовательской истории или функции, а не из трудоемкости их разработки. Такие команды часто переименовывают «единицы истории» в «единицы сложности». Наверное, так лучше звучит. Более внушительно, возможно. Но это неправильно. Единицы истории основаны не на сложности разработки той или иной функции, а на трудоемкости этой разработки.

На лекции несколько лет назад мне дали превосходный пример. Предположим, команда состоит из маленького ребенка и нейрохирурга. Перед ними в ТЗ стоят две задачи: облизать 1000 печатей и выполнить простую операцию на головном мозге - разрез и готово. Выбранные задачи предположительно равны по времени. Если вы не согласны, подставьте в пример нужное число печатей. Несмотря на очевидно разную сложность, обеим задачам надо присвоить одинаковое число единиц истории, потому что мы ожидаем, что обе займут одинаковое время.

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

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

 

Об авторе: Майк Коун, основатель Mountain Goat Software, специализируется на помощи компаниям во внедрении и улучшении их Agile-процессов и техник, с целью создания чрезвычайно высокопроизводительных команд. Он автор книг «User Stories Applied for Agile Software Development, Agile Estimating and Planning (Пользовательские истории в гибкой разработке, оценке и планировании)» и «Succeeding with Agile (Как преуспеть в Agile)». Майк - один из основателей «Альянса Agile» и «Альянса Скрам». Кроме того, он основатель сайта тренингов по Agile, FrontRowAgile.com.

Оригинал: http://www.mountaingoatsoftware.com/blog/its-effort-not-complexity

Перевод: Александра Родсет

Сертифицированные курсы

Андрей Плетенев. Онлайн курс Agile. SCRUM. Курс включает более 20 уроков с практическими заданиями, которые индивидуально проверяются и комментируются тренером.

 

Еще интересные статьи на эту тему: