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

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

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

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

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

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

Скорость внедрения Scrum напрямую связана со следующим:

• степенью необходимых изменений внутри организации;

• срочностью в улучшении разработки и выпуска программного обеспечения в пределах организации;

• эффективностью руководства в рамках организации.

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

Руководитель – это Scrum-мастер изменений в организации.

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

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

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

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