Майк Кон - Agile - оценка и планирование проектов

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

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

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

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

Командам не следует подсчитывать или отслеживать индивидуальную скорость.

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

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

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

Частое предоставление информации о планах важно из-за частоты обновления agile-плана. Например, даже если команда осуществляет скользящее опережающее планирование (как описано в главе 18 «Планирование проекта с участием нескольких команд»), ее план релиза может показывать только то, что будет разрабатываться в следующих нескольких итерациях. Пользовательские истории, которые будут разрабатываться в оставшейся части релиза, могут отражаться в его плане, но без определения очередности их выполнения за горизонтом опережающего плана и как широкие темы.

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

Честное информирование важно, если команда-разработчик и команда-клиент хотят доверять друг другу. Если разработчики узнаю́т, например, что владелец продукта устанавливает для них необоснованные сроки, то они перестают доверять ему. Аналогичным образом доверие исчезает, когда разработчики дают оценки, которые, насколько известно владельцу продукта, нереалистичны. Как-то я имел дело с командой, члены которой говорили, что руководство завышает для них объем работы, действуя по принципу «если сделают 80 %, то уже хорошо». Руководство опиралось на теорию о том, что оно в любом случае получит не более 80 % от запрашиваемого, а потому нужно запрашивать больше.

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