Agile-подход стал некой мантрой для многих руководителей IT-служб / отделов разработки в разных компаниях по всему миру. CEO, чаще всего, положительно воспринимают инициативу внедрения гибких методологий, потому что постоянно слышат, что в той или иной компании перешли на Scrum, Kanban, XP, Scrumban и сразу превратились в «инновационного лидера рынка или русский Google», как минимум.
Многие компании начинают свой путь в гибкость, выбирая Scrum. Он подкупает чистотой и простотой процессов (на первый взгляд), наличием множества успешных кейсов внедрения и большим количеством публикаций и книг.
Почему внедрение Scrum начинает буксовать
Иногда вообще заканчивается провалом. Одно из моих практических наблюдений – Scrum не работает, если в компании нет понятия продукта и владельца продукта. Это один из ключевых моментов. Если вы решили внедрить Scrum, начинать надо с определения продуктов, которые есть в компании, и их владельцев.
Далее надо обучить владельцев, чтобы они понимали зону и меру своей ответственности. В идеале – владельцы продуктов должны быть внутри блока IT. Один владелец, если он в блоке IT, может отвечать сразу за несколько продуктов, или за один большой продукт, например, сайт компании. Это в идеале, в реальности же, зачастую, приходится назначать владельцами сотрудников из бизнеса.
Часто получается так: руководитель HR-блока становится владельцем продукта «внутренний портал компании», главный бухгалтер – владельцем продуктов «MS Dynamics AX/1C» и так далее. Не могу сказать, что этот подход в корне неправильный, но он может создать множество ненужных проблем. Основные проблемы: отсутствие времени на работу с журналом пожеланий (backlog), приоритетами и дорожной картой по продукту (roadmap), непонимание системных и технических ограничений. Этого не видно на первоначальных этапах внедрения, но это становится камнем преткновения через какой-то промежуток времени.
Если нет возможности «держать» владельцев продуктов внутри IT-блока, надо назначать владельцами не руководителей функциональных блоков, а специалистов из этих блоков. Хорошие владельцы продуктов получаются из аналитиков, из менеджеров проектов. Когда есть понимание, кто за какой продукт отвечает, приходит время работы с приоритетами задач в backlog продукта и построении roadmap. Глубина roadmap, с которой стоит начинать – 1 год или даже 6 месяцев. Будем честны перед собой – на первоначальном этапе дорожные карты на более отдаленное будущее будут просто гаданием на кофейной гуще.
Идеальным вариантом для внедрения будет возможность сформировать отдельные команды под каждый продукт. Это позволит избежать конфликта за ресурсы между владельцами продуктов. Хотя объединение взаимозависимых продуктов и передача работы над ними одной команде будет приемлемым и разумным решением.
Работа с приоритетами в бэклоге и отсекание необязательных и неважных фич, до попадания в backlog продукта – это, наверное, самая важная задача владельца продукта. Он должен уметь говорить «нет» бизнесу, именно он регулирует поступление задач команде «на вход», именно он определяет ценность релизов. Это очень ответственная роль. Если владелец продукта не будет отсекать на входе непрозрачные, а иногда вообще нереализуемые и даже вредные «хотелки» бизнеса, то ценность релизов будет стремиться к нулю. Команда продукта будет находиться в подавленном состоянии, из-за отсутствия понимания ценности своей работы. Работа «на корзину» никому не добавляет мотивации.
Обучение и прояснение деталей нового рабочего процесса является важной частью успешного внедрения. Были кейсы, когда я недооценивал важность этого фактора, и это приводило к ненужным конфликтам и сложностям. Нельзя ограничиваться только обучением для команды внедрения. Недостаточно провести пару презентаций для остальных сотрудников, надо доносить изменения через все доступные корпоративные каналы коммуникаций – новости на внутреннем портале, плакаты на стенах в офисе, почтовые рассылки.
Оценка трудоемкости задач в бэклоге
Правильная оценка трудоемкости задач (фич) в бэклоге – важный фактор, влияющий на успешность работы по Scrum. По опыту могу сказать, что оценка в Story Points (единицы истории) работает хуже, чем оценка в рабочих днях или часах. Разработчики еще худо-бедно могут приспособиться и оценивать задачи в Story Points, а вот владельцы продуктов, особенно бизнес, очень настороженно относятся к таким оценкам. Бизнес привык оперировать понятными цифрами и когда им говорят, что их задача оценена в три «стори-поинта», или что их задачу оценили, как «медиум-фичу», то начинаются вопросы и сомнения. Особенно это вредно на начальных этапах внедрения, когда вес одной единицы истории плавает от спринта к спринту, что отрицательно влияет на восприятие нового подхода в компании. Не стоит отчаиваться после пары-тройки неудачных спринтов. Необходимо порядка десяти спринтов, чтобы все начало получаться и с оценкой, и с процессом реализации задач в спринтах.
Пожалуй, самое важное – Scrum относится к гибким методологиям. На него распространяются все пункты Agile-манифеста. Самый важный пункт, за которым кроется успех или неуспех внедрения, – это люди! Не забывайте, что «Люди и взаимодействие важнее процессов и инструментов». Общение между членами команды, заказчиками от бизнеса и всеми заинтересованными сторонами – это ключ к успеху. Все элементы Scrum можно и даже нужно адаптировать и модифицировать под конкретные реалии компании. Не видите необходимости проводить ретроспективы после каждого спринта – не проводите. Понимаете, что лучше помогать владельцам продуктов в категоризации задач в бэклоге, привлекая к этому процессу аналитиков и разработчиков, – делайте именно так. Ведь еще один важнейший пункт манифеста: «Готовность к изменениям важнее следования первоначальному плану».
Не бойтесь пробовать что-то новое. Не получилось со Scrum? Попробуйте Kanban, для многих небольших компаний Scrum избыточен. Экспериментируйте с длиной спринта, пробуйте различные инструменты, признавайте ошибки и начинайте новый цикл. С каждой новой командой и очередным внедрением будет получаться все лучше и лучше.
Надеюсь, эта статья будет чем-то вам полезна, поможет избежать некоторых ошибок и ваш путь к гибкости будет чуть менее тернистым.
https://www.e-xecutive.ru