У Вас Agile? Проверим?..

Автор: Александр Якима (www.enter-agile.com)

Очень радует, что гибкие методы распространяются с околозвуковой скоростью - это приближает время, когда стандартное представление о разработке будет отождествляться с гибкими методами. Однако и проблема на этом пути есть серьезная - не все Agile, что так называется. И таких случаев значительно больше, чем это может показаться на первый взгляд. Все еще на 100% уверены, что у вас Agile или есть разумные сомнения? Используйте этот простой чеклист и это поможет в первую очередь вам прояснить, что вам необходимо изменить, чтобы настоящий Agile начал по-настоящему на вас работать...

Вопрос №1: У вас итерационная разработка? Иными словами, работает ли ваша команда четкими короткими (одно-, двух- или нескольконедельными) таймбоксами?

При этом важно понимать, что итеративность - это строго постоянная величина. Их не меняют, не назначают и не отменяют как и когда попало. Если вы не можете четко ответить, что, скажем, всегда работаете одинаковыми (напр., двунедельными) итерациями, то стоит задуматься. Главное правило, от которого приводится в движение весь механизм гибкой разработки: дисциплина итераций прежде всего.

Вопрос №2: Является ли основной целью и результатом каждой итерации работающая версия продукта?

Если это не так - у вас точно не Agile. Тут все просто. Если под конец итерации у вас что угодно, только не запускающийся и нормально работающий продукт (много несинхронизированного кода в разных ветках, скриптов, отчетов о прогрессе в excel-документах, планов, диаграм архитектуры системы и т. д.), то это не Agile. Вам попросту нечем измерять действительный прогрес разработки, нет средства получения фидбека, нет осязаемого результата.

Вопрос №3: Является ли для команды принятие/непринятие итерации продакт оунером существенным и действенным показателем успешности их работы?

Если команда просто работает, даже итерационно, но команда не ставит перед собой постоянной целью получение фидбека от продакт оунера (да или нет; принята итерация или нет...) - это не Agile. Очень важно понимать, что в этом пункте не может быть исключений, например: "а у нас заказчик такой... - ему все равно". Иногда выходом является проксирование функции продакт оунера менеджером продукта, есть и другие варианты. Однако суть такова - без авторитетной приемочной роли п/о это работа на холостых оборотах, а не Agile.

Вопрос №4: Сдает ли ваша команда релиз всегда вовремя и качественно?

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

Вопрос №5: Знает ли и понимает ли ваша команда в каждый момент времени цели продукта в целом, текущего релиза в частности и, наконец, итерации?

Если нет, то эффективная доставка бизнес-ценности конечному пользователю нарушена в корне.

Обратите внимание, что мы ни разу не поднимали вопрос о том, пользуетесь ли вы карточками вместо спецификаций, стоите ли исправно на скрам-митингах, валяются ли у вас везде разноцветные маркеры - то, чего обычно "хватает", чтобы назвать себя Agile-командой. Уверен, вы уже догадались почему.

2 comments:

  1. Ничего из вышеперечисленного. Нельзя делать эджайл. Нужно быть эджайл. Как-то так.

    ReplyDelete
  2. В яблочко! Нужно "быть" и "чувствовать". Как раз потому и важно видеть те цели и преимущества, которые дает agile. Это с другой стороны дает команде энергию для должной самодисциплины. Так...

    ReplyDelete

 
Powered by Blogger