На прошедшей недавно конференции Agile Base Camp | Crew Drill я умудрился выступить сразу с двумя сессиями: практической игрой-симуляцией Канбан процесса и докладом о том, почему коллективные оценки, все-таки работают для Agile команд.

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

Уже успел добавить звук, поэтому те, кто не попал, но очень хотел, могут послушать слайд-каст. Конечно, эффект не тот, что от присутствия в зале, хотя общее представление о сути можно получить.

[slideshare id=13099042&doc=2012-05-25abcout-120527231108-phpapp01]

Попробую обобщить доклад до нескольких строк и выделить основные тезисы.

Виноваты традиционные подходы к оценке и то, как мы строим планы на их основе. Почему и как в реальности это проявляется, я рассказал на очень жизненных примерах.

Что делать с проблемой оценок?

• Планирование на разных уровнях
• Планирование с разным уровнем точности
• Исполнение требований по порядку (бизнес-приоритету)
• Ставить буфер в конце цикла, а не локально в каждую задачу/требование

Все это, можно сказать, общеизвестные тезисы, которые не раз уже упоминались, и все же о которых нужно постоянно рассказывать и напоминать.

Если же говорить про оценки, то мы можем наблюдать следующие интересные эффекты:

• Коллективные оценки оказываются точнее. Поэтому стоит оценивать вместе, привлекая кросс-функциональных специалистов
• Мы все равно оцениваем сравнением. И через сравнение же можем прогнозировать/планировать
• Единицы измерения не важны. Это я доказал в виде простой формулы

Если единицы не важны, а нужны все-таки цифры, то стоит внимательней присмотреться к популярным способам оценки: Идеальное время и Пункты (Story Points). Подробнее о каждом мы уже писали на сайте, и также я рассказал в докладе. Каждый тип оценки имеет свои плюсы и минусы. Поэтому лучше всего использовать ПУНКТЫ для Бэклога Продукта и ИДЕАЛЬНЫЕ ЧАСЫ для плана спринта (итерации).

И главное, не усложняйте свои подходы к оценкам. Дополнительное время, потраченное на “уточнение оценок”, по сути менее эффективно, чем время, которое вы потратили на разработку первых требований. Ведь опыт вы можете получить, только делая что-то, и этот опыт позволяет больше узнать о возможных рисках или погрешностях и тем самым уточнить оценки.

Приятного прослушивания!

Ну, а если вы подпишитесь на наш RSS, то точно не пропустите рассказ о практическом навыке построения Канбан процесса.