Professional Scrum Master (PSM)

Professional Scrum Master (PSM)
Professional Scrum Master (PSM)

суббота, 15 июня 2013 г.

Кто украл мой Скрам?

Перевод оригинального блог поста Эдвина Дандо.

Наверное, вы слышали об этой статистике – команды Джеффа Сазерленда стабильно получают 500%-700% увеличение в производительности. Огранизации, с которыми он работает, утраивают продуктивность в считанные месяцы. Итак, вы внедрили Скрам. Почему же у вас нет подобной  продуктивности? Кто украл ваш Скрам и вашу продуктивность?

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

Давайте подробнее поговорим об этом.

Фокус на бизнес ценность

Одна из самых главных ошибок, которые делают аджайл команды – четкое распределение ролей. Это неправильное толкование Скрама, которое выливается в следующие распространенные заблуждения:
  • Фокусирование на бизнес ценности – работа Владельца Продукта
  • Кодироваине и тестирование – работа Команды
  • Фасилитация и лидерство – работа Скрам мастера


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


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

«Неужели вы хотите сказать, что я не должен работать над всем этим сам?»



Качественная разработка в команде

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

Мы считаем, что главным вызовом в разработке программного обеспечения является необходимость изменений.

Скрам и XP – брак, заключенный на небесах и эффективные аджайл комнады должны быть очень сильны в XP практиках.
Как то раз я спросил у Джеффа Сазерленда:

«Как тебе удается получать семикратный прирост в производительности?»

Его ответ? Он был очень простым: 

«Делайте все, что мы уже обсуждали [Скрам + XP]. Вы должны понимать, что каждый раз, когда вы решаете не применять ту или иную практику означает для вас понижение возможной максимальной производительности»

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


В это входит Test Driven Development, Acceptance Test Driven Development, Рефакторинг, Continuous Integration, Continuous Deployment, Автоматизация процесса тестирования, Specification by example.