Перевод
оригинального блог поста
Эдвина Дандо.
Наверное, вы слышали об этой
статистике – команды Джеффа Сазерленда стабильно получают 500%-700% увеличение
в производительности. Огранизации, с которыми он работает, утраивают продуктивность
в считанные месяцы. Итак, вы внедрили Скрам. Почему же у вас нет подобной продуктивности? Кто украл ваш Скрам и вашу
продуктивность?
Когда вы работаете с
высокопроизводительной Аджайл командой, то замечаете, что происходят, на первый
взгляд, незаметные, но глубокие по своей сути изменения. Вы замечаете в первую
очередь не то как команда четко придерживается правил фреймворка, с которым
работает, а то как она фокусируется на том, чтобы доставить бизнес ценность. В
своей практике я встречал два ключевых патерна:
- Команда фокусируется на том, чтобы доставлять бизнес ценность.
- Команда делает это с использованием высококачественных инженерных практик.
Давайте подробнее поговорим об этом.
Фокус на бизнес ценность
Одна из самых главных ошибок,
которые делают аджайл команды – четкое распределение ролей. Это неправильное
толкование Скрама, которое выливается в следующие распространенные заблуждения:
- Фокусирование на бизнес ценности – работа Владельца Продукта
- Кодироваине и тестирование – работа Команды
- Фасилитация и лидерство – работа Скрам мастера
Подобный линейный стиль мышления неправильный и ведет нас
к искаженному пониманию тех идей, которые были изложены Такеуши
и Нонака.
Скрам – простой, но, тем ни менее, сильный фреймворк,
базирущийся на определенных принципах. Настоящая ценность Скрама заключается в
двух равнозначных по своей важности вещах: фокусе на бизнес ценности и том,
что не приносит реальной ценности. И это касается всех в Скрам команде. Вера в
то, что это исключительная прерогатива Владельца Продукта – большая ошибка.
Мы часто замечали в нашей
практике, что Владелец Продукта очень расстраивается при мысли о том, что
доставка бизнес ценности не является его исключительной обязанностью. Он (Владелец
Продукта) на самом деле обеспокоен тем, что Беклог Продукта растет и что его
верхушку команда должна «хорошенько прогруммить и понять». Когда
мы советуем больше работать на стратегическом уровне, фокусируясь на
формировании стратегии продукта, его дорожной карты, видения и большего вовлечения
команды в процесс формирования Беклога Продукта, это вызывает у многих искренне
удивление.
«Неужели вы хотите сказать, что я не должен работать над всем этим сам?»
Качественная разработка в команде
Второе распространенное
заблуждение – чтобы получить желаемые плюшки
Скрама, необходимо и достаточно лишь его правильно внедрить. Я не согласен с
этим. Правильным образом внедренный Скрам лишь обнажит все те дисфункции,
которые присутствуют в вашей организации/проекте. Вы можете протестовать,
жаловаться, срываться, но правда заключается в том, что вы либо решите основную
проблему, либо примите ее и будете с ней дальше жить.
Мы считаем, что главным вызовом в
разработке программного обеспечения является необходимость изменений.
Скрам и XP – брак, заключенный на
небесах и эффективные аджайл комнады должны быть очень сильны в XP практиках.
Как то раз я спросил у Джеффа
Сазерленда:
«Как
тебе удается получать семикратный прирост в производительности?»
Его ответ? Он был очень простым:
«Делайте все, что мы уже обсуждали [Скрам + XP]. Вы должны
понимать, что каждый раз, когда вы решаете не применять ту или иную практику
означает для вас понижение возможной максимальной производительности»
Попросту говоря, из моего опыта следует, что значительные приросты в
производительности команды могут быть следствиями: улучшения инженерных практик
и постоянном фокусе на доставке бизнес ценности.
В это входит Test
Driven Development, Acceptance Test Driven Development, Рефакторинг, Continuous Integration, Continuous
Deployment, Автоматизация процесса тестирования, Specification by example.
