Джефф Сазерленд - Софт за 30 дней. Как Scrum делает невозможное возможным

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

Со Scrum знакомят оставшиеся команды, составляющие 25–30 % общего персонала организации. Существующие практические приемы продолжают совершенствоваться и распределяться между командами, чтобы достигнуть закрепления гибкого подхода к разработке в организации. Только теперь строгие правила, в соответствии с которыми Scrum осуществляет свою деятельность, могут быть скорректированы, чтобы лучше соответствовать потребностям организации. Клиентам может быть предложено принять участие во внедрении через обучение в качестве владельцев продукта и Scrum-мастеров. Эта фаза продолжается до тех пор, пока все команды не будут вовлечены в Scrum. Механизмы Scrum по инспекции и адаптации будут способствовать дальнейшему улучшению процессов и практических методов.

К этому моменту организация уже достигнет существенной производительности, а также оценит деловые и культурные преимущества Scrum.

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

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

Сама природа Scrum – его непрекращающиеся требование к качеству программного обеспечения, предоставляемого как можно быстрее, его постоянное требование необходимости работы с конечными пользователями для обеспечения эффективного применения и его постоянные механизмы инспекции и адаптации, быстро выявляющие плохо функционирующие методы и «блокирующие элементы». Этот эффект становится все более выраженным, когда Scrum также используется как процесс по внедрению и масштабированию Scrum в организации.

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

Препятствия, как правило, встречаются в четырех областях.

1. Сам Scrum-процесс – какие препятствия стоят на пути его применения?

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

3. Инженерные методы разработки продукта – какие методы мешают оптимизации возврата инвестиций или максимизации целей организации с точки зрения перспективы продукта, какие препятствия есть в оптимизации разработки и выпуска продукта?

4. Организационные вопросы – какие системные организационные проблемы, которые явно лежат вне поля контроля команды, мешают командам быстрее поставлять программное обеспечение пользователям?

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

Экономическая выгода от применения Scrum и гибких методов наиболее легко достигается, если комплексные команды немногочисленны, работают в непосредственной близости друг от друга и в идеале состоят из 11 или меньше человек (включая владельца продукта, Scrum-мастера и команды разработки). Каждая Scrum-команда работает над специфическим продуктом или приложением, которое они могут определить, разработать, протестировать и выпустить без большой помощи извне.

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

1) масштабирование организации: комплексные Scrum-команды;

2) создание инфраструктуры для гибкости предприятия;

3) координация комплексных команд.

Каждый из этих вызовов рассмотрен ниже.

Основанный больше на философских принципах, Scrum имеет очень небольшое количество правил. Тем не менее большинство правил, которые действительно существуют, – фиксированные и относительно нерушимые. Одно из таких основных правил – команда должна состоять не более чем из 11 участников и по возможности располагаться в общем рабочем помещении. Это наиболее эффективная и продуктивная модель, так как она: а) поддерживает требование постоянного неформального общения членов команды; б) воспитывает высокий уровень корпоративного духа; в) дает возможность для взаимной приверженности целям спринта членов команды, которые действительно знают друг друга и работают вместе каждый день.

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