Я работаю с большими компаниями, которые пытаются применить Agile, начиная со Scrum. Хотя каждая организация находится в своем секторе, использует разные технологии и имеет свою культуру управления, у всех была одна общая болезнь — своего рода «гигантизм». В этой статье содержится список общих проблем гибкости в больших организациях и исследуется возможность избежать симптома «гигантизма».
На первый взгляд проблемы организации будут выглядеть как «слишком много задач» или «не достаточно ресурсов», или «нестабильная ситуация на рынке». При ближайшем рассмотрении, ключевые причины окажутся дурными привычками, сформировавшимися «рефлексами» и заблуждениями.
Одна из очень известных компаний, которая была примером успешного применения Scrum в 1997 году, обратилась за помощью в Danube Technologies, Inc. в 2009 году, потому что «рынок» показал, что они оказались менее гибкими, чем конкуренты. Начинания по внедрению Scrum, которые начались 1997 году, по-видимому, не могли выдержать десятилетие сосуществования с проблемами, присущими крупным предприятиям. К сожалению, большинство попыток внедрить Scrum в крупных организациях не приводит к долговременным преобразованиям. Препятствия для внедрения Scrum обычно также мешают достижению успеха в бизнесе в целом, а устоявшиеся организации обычно неохотно избавляются от них.
В Руководстве PMBOK написано:
Чтобы разрешить этот парадокс, давайте рассмотрим определение «ресурса».
Когда работа представляет собой разработку нового продукта, соответствующие ресурсы неосязаемы: понимание задачи, обучение, межличностное общение и инновации. Scrum-команды пытаются максимизировать их, создавая состояния индивидуального и группового «потока». Как утверждает психолог Mihaly Csikszentmihalyi: «[в потоке] вы полностью погружены в задачу, и вы используете все свои навыки на предельном уровне».
Члены Команды Разработки (Development Team) Scrum интенсивно взаимодействуют друг с другом, чтобы создавать продукты в соответствии с целями, которые они постоянно обсуждают с Владельцем Продукта (Product Owner). Владелец Продукта отвечает за принятие бизнес-решений в команде. Результаты работы демонстрируются в конце каждого Спринта (Sprint) фиксированной длительности (например, каждые две недели). Во время Спринта члены команды развивают заинтересованность в общих целях и учатся управлять друг-другом для их достижения. Даже при идеальных условиях (в том числе, говоря о помещении, где работает команда) команде требуется принять участие в нескольких спринтах, чтобы достичь успеха, и около года, чтобы реализовать свой потенциал полностью. Широко известно описание этого органического процесса — «формирование, штурм, нормирование, выполнение» модели Брюса Такмана. (Bruce Tuckman, “forming, storming, norming, performing”).
Наивно рассуждать о людях, как о ресурсах. Новые члены в команде не будут гарантировать увеличение понятия «ресурса команды», и могут даже уменьшить его. После года работы по Scrum один из моих клиентов сказал мне: «После того, как команда сформирована, лучше потерять одного члена команды, чем добавить нового». Совсем другое, если Scrum команда сама пришла к решению о найме нового сотрудника, тогда добавление нового члена команды будет хорошим решением. Но, даже при возможности команды самостоятельно нанимать сотрудников, нецелесообразно увеличивать размер команды больше семи человек.
В некоторых случаях увеличение команд может привести к ускорению работы, если это происходит с учетом того, что это нематериальные, неисчисляемые ресурсы.
Scrum‐команды это кроссфункциональные команды, которые стараются создать тщательно протестированный инкремент продукта каждый спринт, постепенно наращивая функциональность. Самая популярная книга по Scrum использует фразу “потенциально “Готового” к выпуску Инкремента продукта” (“potentially shippable product increment”) 18 раз. Несмотря на это, я встречаю людей, которые утверждают, что «практикуют Scrum», используя при этом «аналитические спринты» или «спринты проектирования» в начале проекта, откладывая интеграцию и тестирование на потом, и привлекая разные команды для выполнения каждой части работы. Привычки, приобретённые из Водопадной Модели Управления Проектами, скрывают риски до тех пор, пока не становится слишком поздно что-то делать.
В Scrum, в течение каждого Спринта требуется сочетание разных мероприятий, присущих разработке. Мы получаем гибкость благодаря непрерывному анализу требований, непрерывному проектированию, непрерывной интеграции и непрерывному тестированию, все члены команды вместе.
Команды, созданные для работы над одним компонентом, сокращают возможности бизнеса по переориентации возможностей продукта, увеличивают количество узких мест в коммуникации с менеджерами и владельцами продукта и привносят дополнительные интеграционные риски.
Такие команды были бы эффективными, если бы разработка нового продукта была бы столь же предсказуемой, как производство. На практике, приоритеты меняются, а оценки оказываются неверными. Поэтому трудно привлечь нужных людей в нужное время, чтобы вести разработку, которая может влиять на несколько компонентов.
Противоположностью Компонентной Команды является Функциональная Команда, ориентированная на разработку новых возможностей продукта (feature team). Функциональная Команда охватывает как компоненты, так и дисциплины, и, таким образом, способна реализовывать функциональные задачи для бизнеса в тонких, полностью протестированных «вертикальных срезах» продукта. Такой подход призван заменить концепции прошлого века, основываясь на концепциях автономности команд, самоорганизованности и ответственности. Бэклог продукта Функциональных Команд основан на нуждах бизнеса, а не на зависимостях от технологий. Если вы до сих пор используете Диаграммы Гантта, скорее всего у вас пока не организованы Функциональные Команды.
Создание Функциональных Команд связано с затратами: разработчики будут должны освоить новые навыки, что замедлит их в начале. К счастью, большинство разработчиков любят осваивать новые навыки. Методы, такие как назначение технического «хранителя компонент» (“component guardian”) для каждой области могут помочь защитить архитектурную целостность, поскольку команды учатся. Как и при любой масштабной разработке, непрерывная интеграция (автоматические тесты, выполняемые гораздо чаще, чем один раз в день) имеет решающее значение для предотвращения необнаруженных дефектов общей работоспособности продукта.
После того, как организация научится управлять Функциональными Командами, следующим шагом может быть — создание Функциональных Команд Общего Назначения (general purpose feature teams) с минимальными зависимостями от функциональных областей. Этот процесс может потребовать годы непрерывного обучения внутри организации.
В типичных крупных организациях тратятся миллионы долларов из-за ненужного переключения между задачами. Командам не хватает сфокусированности и месяцев стабильности в отношении состава команды, чтобы достичь состояния самоорганизации, необходимого для высокой производительности и качества. Некоторые люди постоянно оказываются на нескольких «критических путях» одновременно, что серьезно ограничивает всеобщую производительность. Для эффективного масштабирования эти люди должны стать наставниками, а не исполнителями задач. Чтобы увеличить их влияние, они должны отказаться от некоторого контроля.
Традиционные методы управления, которые усиливают специализацию, только усугубят проблему. Работу следует давать Scrum-команде во время встречи для Планирования Спринта (Sprint Planning Meeting). Когда менеджер не берет это во внимание, назначая задачи на конкретных исполнителей, у специалистов не оказывается возможности наставлять и обучать других важным навыкам. На одной из встреч для Планирования Спринта я столкнулся с тем, что первый вопрос, который был задан, был: «Кто у нас будет работать на этом Спринте?». Люди, которых постоянно дергают, не будут заниматься обучением остальных, хоть это и ожидается от Scrum-команд. И организации закапываются в эти проблемы каждый день все больше и больше.
На более высоких должностях еще больше проблем, связанных с многозадачностью, отвлечением внимания, беспокойства и неспособностью получения контроля над происходящем. Владелец Продукта, на том же самой встрече, пришла раздраженная, с опозданием на час, и снова убежала через 10 минут. И мне сказали, что так происходит постоянно.
А после обеда, руководитель не смог посветить себя встрече с 60 своими сотрудниками потому, что он параллельно пытался решать другую проблему посредствам сервисов в своем телефоне. Случайный наблюдатель этих сцен не мог бы предположить, что эти бешеные рабы, управляемые событиями, были ответственны за стратегию дальнейшего развития.
Эффективная горизонтальная коммуникация между Scrum-командами помогает Владельцам Продуктов спокойно сосредоточиться на таких обязанностях, как определение приоритетов работы и определение окончательных требований.
При разработке продукта, скорость обнаружения новых задач, которые необходимо сделать, обычно опережает скорость самой разработки. Чтобы справляться с этим, Владелец Продукта должен проводить Уточняющие Встречи (Refinement Meetings) для пересмотра, приоретизации и уточнения задач в Бэклоге Продукта каждый Спринт. Когда в Бэклоге появляются слишком большие задачи («epics»), необходимо находить их ключевые аспекты и делить их на маленькие подзадачи (обычно называемые «User Stories»). Владелец Продукта управляет объемом работ, решая, какие задачи войдут в Релиз, с учетом данных о скорости разработки и объеме работ, выполняемом в течение Спринта.
Проблемы управления организацией, в конечном итоге, видны в исходном коде. И «технический долг» становится причиной проблем в продукте и высокой стоимости изменений. В идеале, регрессионные тесты можно автоматизировать с помощью того же языка программирования, что используется при разработке продукта, без использования проприетарных инструментов, которые только усиливают зависимость от специфичных знаний. Навыки, такие как Test Driven Development (TDD), доказали свою ценность в 20-м веке. В 21-м веке от любого разработчика ожидается навыки владение гибкими методологиями. И команды, которые этими навыками еще не обладают, должны пытаться работать с «вертикальными срезами задач», пока они не научатся.
Scrum выделяет по одному человеку на команду (ScrumMaster), чтобы уделять основное внимание выявлению и преодолению таких препятствий. Это требует смелости, воображения и поддержки со стороны руководства. Слишком мало Scrum-мастеров уделяют должное внимание таким проблемам, а руководство часто не поддерживает тех, кто это делает.
«Слишком много задач» или «недостаточно ресурсов», или «нестабильная ситуация на рынке» не является хорошим оправданием, чтобы не внедрять Гибкие методологии, специально предназначенные для решения этих проблем. И люди, ответственные за изменения, должны быть лучше подготовлены к преодолению Препятствий для внедрения Гибких методологий, осознавая, что ключевые причины проблем в сохранении дурных привычек, сформировавшихся «рефлексах» и заблуждениях.
Текст оригинальной статьи: 7 Obstacles to Enterprise Agility
Автор: Michael James
Перевод: Daniel Chernyshev
Переведено с согласия автора.
На первый взгляд проблемы организации будут выглядеть как «слишком много задач» или «не достаточно ресурсов», или «нестабильная ситуация на рынке». При ближайшем рассмотрении, ключевые причины окажутся дурными привычками, сформировавшимися «рефлексами» и заблуждениями.
Одна из очень известных компаний, которая была примером успешного применения Scrum в 1997 году, обратилась за помощью в Danube Technologies, Inc. в 2009 году, потому что «рынок» показал, что они оказались менее гибкими, чем конкуренты. Начинания по внедрению Scrum, которые начались 1997 году, по-видимому, не могли выдержать десятилетие сосуществования с проблемами, присущими крупным предприятиям. К сожалению, большинство попыток внедрить Scrum в крупных организациях не приводит к долговременным преобразованиям. Препятствия для внедрения Scrum обычно также мешают достижению успеха в бизнесе в целом, а устоявшиеся организации обычно неохотно избавляются от них.
Препятствие #1: Наивный менеджмент ресурсов
В Руководстве PMBOK написано:
«зачастую возникает необходимость увеличения бюджета, чтобы добавить дополнительные ресурсы для выполнения того же объема работ в более сжатые сроки»В отношении программного обеспечения, Фред Брукс (в книге «Мифический человеко-месяц») дает утверждение, которое противоречит предыдущему:
«Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше»
Чтобы разрешить этот парадокс, давайте рассмотрим определение «ресурса».
Когда работа представляет собой разработку нового продукта, соответствующие ресурсы неосязаемы: понимание задачи, обучение, межличностное общение и инновации. Scrum-команды пытаются максимизировать их, создавая состояния индивидуального и группового «потока». Как утверждает психолог Mihaly Csikszentmihalyi: «[в потоке] вы полностью погружены в задачу, и вы используете все свои навыки на предельном уровне».
Члены Команды Разработки (Development Team) Scrum интенсивно взаимодействуют друг с другом, чтобы создавать продукты в соответствии с целями, которые они постоянно обсуждают с Владельцем Продукта (Product Owner). Владелец Продукта отвечает за принятие бизнес-решений в команде. Результаты работы демонстрируются в конце каждого Спринта (Sprint) фиксированной длительности (например, каждые две недели). Во время Спринта члены команды развивают заинтересованность в общих целях и учатся управлять друг-другом для их достижения. Даже при идеальных условиях (в том числе, говоря о помещении, где работает команда) команде требуется принять участие в нескольких спринтах, чтобы достичь успеха, и около года, чтобы реализовать свой потенциал полностью. Широко известно описание этого органического процесса — «формирование, штурм, нормирование, выполнение» модели Брюса Такмана. (Bruce Tuckman, “forming, storming, norming, performing”).
Наивно рассуждать о людях, как о ресурсах. Новые члены в команде не будут гарантировать увеличение понятия «ресурса команды», и могут даже уменьшить его. После года работы по Scrum один из моих клиентов сказал мне: «После того, как команда сформирована, лучше потерять одного члена команды, чем добавить нового». Совсем другое, если Scrum команда сама пришла к решению о найме нового сотрудника, тогда добавление нового члена команды будет хорошим решением. Но, даже при возможности команды самостоятельно нанимать сотрудников, нецелесообразно увеличивать размер команды больше семи человек.
В некоторых случаях увеличение команд может привести к ускорению работы, если это происходит с учетом того, что это нематериальные, неисчисляемые ресурсы.
Препятствие #2: Команды, организованные по функциональной принадлежности
Scrum‐команды это кроссфункциональные команды, которые стараются создать тщательно протестированный инкремент продукта каждый спринт, постепенно наращивая функциональность. Самая популярная книга по Scrum использует фразу “потенциально “Готового” к выпуску Инкремента продукта” (“potentially shippable product increment”) 18 раз. Несмотря на это, я встречаю людей, которые утверждают, что «практикуют Scrum», используя при этом «аналитические спринты» или «спринты проектирования» в начале проекта, откладывая интеграцию и тестирование на потом, и привлекая разные команды для выполнения каждой части работы. Привычки, приобретённые из Водопадной Модели Управления Проектами, скрывают риски до тех пор, пока не становится слишком поздно что-то делать.
В Scrum, в течение каждого Спринта требуется сочетание разных мероприятий, присущих разработке. Мы получаем гибкость благодаря непрерывному анализу требований, непрерывному проектированию, непрерывной интеграции и непрерывному тестированию, все члены команды вместе.
Препятствие #3: Команды, организованные по архитектурно-компонентной принадлежности
Команды, созданные для работы над одним компонентом, сокращают возможности бизнеса по переориентации возможностей продукта, увеличивают количество узких мест в коммуникации с менеджерами и владельцами продукта и привносят дополнительные интеграционные риски.
Такие команды были бы эффективными, если бы разработка нового продукта была бы столь же предсказуемой, как производство. На практике, приоритеты меняются, а оценки оказываются неверными. Поэтому трудно привлечь нужных людей в нужное время, чтобы вести разработку, которая может влиять на несколько компонентов.
Противоположностью Компонентной Команды является Функциональная Команда, ориентированная на разработку новых возможностей продукта (feature team). Функциональная Команда охватывает как компоненты, так и дисциплины, и, таким образом, способна реализовывать функциональные задачи для бизнеса в тонких, полностью протестированных «вертикальных срезах» продукта. Такой подход призван заменить концепции прошлого века, основываясь на концепциях автономности команд, самоорганизованности и ответственности. Бэклог продукта Функциональных Команд основан на нуждах бизнеса, а не на зависимостях от технологий. Если вы до сих пор используете Диаграммы Гантта, скорее всего у вас пока не организованы Функциональные Команды.
Создание Функциональных Команд связано с затратами: разработчики будут должны освоить новые навыки, что замедлит их в начале. К счастью, большинство разработчиков любят осваивать новые навыки. Методы, такие как назначение технического «хранителя компонент» (“component guardian”) для каждой области могут помочь защитить архитектурную целостность, поскольку команды учатся. Как и при любой масштабной разработке, непрерывная интеграция (автоматические тесты, выполняемые гораздо чаще, чем один раз в день) имеет решающее значение для предотвращения необнаруженных дефектов общей работоспособности продукта.
После того, как организация научится управлять Функциональными Командами, следующим шагом может быть — создание Функциональных Команд Общего Назначения (general purpose feature teams) с минимальными зависимостями от функциональных областей. Этот процесс может потребовать годы непрерывного обучения внутри организации.
Препятствие #4: Отвлечение внимания
В типичных крупных организациях тратятся миллионы долларов из-за ненужного переключения между задачами. Командам не хватает сфокусированности и месяцев стабильности в отношении состава команды, чтобы достичь состояния самоорганизации, необходимого для высокой производительности и качества. Некоторые люди постоянно оказываются на нескольких «критических путях» одновременно, что серьезно ограничивает всеобщую производительность. Для эффективного масштабирования эти люди должны стать наставниками, а не исполнителями задач. Чтобы увеличить их влияние, они должны отказаться от некоторого контроля.
Традиционные методы управления, которые усиливают специализацию, только усугубят проблему. Работу следует давать Scrum-команде во время встречи для Планирования Спринта (Sprint Planning Meeting). Когда менеджер не берет это во внимание, назначая задачи на конкретных исполнителей, у специалистов не оказывается возможности наставлять и обучать других важным навыкам. На одной из встреч для Планирования Спринта я столкнулся с тем, что первый вопрос, который был задан, был: «Кто у нас будет работать на этом Спринте?». Люди, которых постоянно дергают, не будут заниматься обучением остальных, хоть это и ожидается от Scrum-команд. И организации закапываются в эти проблемы каждый день все больше и больше.
На более высоких должностях еще больше проблем, связанных с многозадачностью, отвлечением внимания, беспокойства и неспособностью получения контроля над происходящем. Владелец Продукта, на том же самой встрече, пришла раздраженная, с опозданием на час, и снова убежала через 10 минут. И мне сказали, что так происходит постоянно.
А после обеда, руководитель не смог посветить себя встрече с 60 своими сотрудниками потому, что он параллельно пытался решать другую проблему посредствам сервисов в своем телефоне. Случайный наблюдатель этих сцен не мог бы предположить, что эти бешеные рабы, управляемые событиями, были ответственны за стратегию дальнейшего развития.
Эффективная горизонтальная коммуникация между Scrum-командами помогает Владельцам Продуктов спокойно сосредоточиться на таких обязанностях, как определение приоритетов работы и определение окончательных требований.
Препятствие #5: Нежелание непрерывно пересматривать, приоритезировать и детализировать Бэклог Продукта
При разработке продукта, скорость обнаружения новых задач, которые необходимо сделать, обычно опережает скорость самой разработки. Чтобы справляться с этим, Владелец Продукта должен проводить Уточняющие Встречи (Refinement Meetings) для пересмотра, приоретизации и уточнения задач в Бэклоге Продукта каждый Спринт. Когда в Бэклоге появляются слишком большие задачи («epics»), необходимо находить их ключевые аспекты и делить их на маленькие подзадачи (обычно называемые «User Stories»). Владелец Продукта управляет объемом работ, решая, какие задачи войдут в Релиз, с учетом данных о скорости разработки и объеме работ, выполняемом в течение Спринта.
Препятствие #6: «Технический Долг»
Проблемы управления организацией, в конечном итоге, видны в исходном коде. И «технический долг» становится причиной проблем в продукте и высокой стоимости изменений. В идеале, регрессионные тесты можно автоматизировать с помощью того же языка программирования, что используется при разработке продукта, без использования проприетарных инструментов, которые только усиливают зависимость от специфичных знаний. Навыки, такие как Test Driven Development (TDD), доказали свою ценность в 20-м веке. В 21-м веке от любого разработчика ожидается навыки владение гибкими методологиями. И команды, которые этими навыками еще не обладают, должны пытаться работать с «вертикальными срезами задач», пока они не научатся.
Препятствие #7: Нежелание меняться
Scrum выделяет по одному человеку на команду (ScrumMaster), чтобы уделять основное внимание выявлению и преодолению таких препятствий. Это требует смелости, воображения и поддержки со стороны руководства. Слишком мало Scrum-мастеров уделяют должное внимание таким проблемам, а руководство часто не поддерживает тех, кто это делает.
«Слишком много задач» или «недостаточно ресурсов», или «нестабильная ситуация на рынке» не является хорошим оправданием, чтобы не внедрять Гибкие методологии, специально предназначенные для решения этих проблем. И люди, ответственные за изменения, должны быть лучше подготовлены к преодолению Препятствий для внедрения Гибких методологий, осознавая, что ключевые причины проблем в сохранении дурных привычек, сформировавшихся «рефлексах» и заблуждениях.
Текст оригинальной статьи: 7 Obstacles to Enterprise Agility
Автор: Michael James
Перевод: Daniel Chernyshev
Переведено с согласия автора.
