Продолжаем про нюансы гибкой разработки (Agile), которые случаются на практике. Как понять, правильно ли внедрен Agile, какая практика годится для какой задачи и отрасли, кто в компании должен переводить работу на «Agile-рельсы»? Своим опытом с редакцией блога Mail.Ru Cloud Solutions продолжает делиться Agile-коуч ScrumTrek Василий Савунов.
В прошлый раз Василий рассказал, что такое Agile, какие он включает методологии и какие вокруг него сформировались стереотипы. Теперь поговорим о его внедрении.
О компаниях, использующих Agile
— Есть ли «отраслевые предпочтения» в гибких методологиях?
Как показывает исследование Agile Russia, которое мы проводим второй год подряд, в сфере разработки ПО преимущественно используется Scrum, в финансовых организациях — Канбан, а в телеком-индустрии — и то, и другое.
Как человек, который непосредственно анализировал собранные данные, и работавший со многими из респондентов, я считаю, что такое положение вещей обусловлено двумя причинами:
- Скорость изменений в IT значительно выше, чем в финансах. Поэтому там предпочтителен Scrum как подход, позволяющий за счёт быстрых экспериментов гибко управлять приоритетами и менять направление в зависимости от изменений внешней среды и условий «на входе». Финансы более консервативны.
- Стоимость ошибки в финансах гораздо выше, чем в IT-разработке. Поэтому в них больше ценится Канбан, основанный на математике, а не на экспериментах, и позволяющий посредством небольших, но постоянных изменений улучшать рабочий процесс в целом.
Телекому Канбан тоже подходит. Хотя бы потому, что вектор развития отрасли — цифровизация. Однако пока мало кто понимает, как конкретно она должна выглядеть. Кроме того, в телекоме «быстрая» часть работы (разработка ПО) соседствует с «медленной» (поддержка и развитие аппаратной инфраструктуры). Поэтому наряду с экспериментами, которые проводятся по Scrum, имеет смысл эволюционно ускорять текущие процессы с применением Канбана.
Методики гибкой разработки, принятые в разных отраслях. Суммы не равны 100 %, потому что можно было выбирать более одного пункта. Изображение/ScrumTrek
— А как дела у мобильных разработчиков? Есть ли у Agile специфика в мобильной разработке?
С моей точки зрения, основная трудность при разработке мобильных приложений — выявление требований к приложению, потому что бывает сложно идентифицировать заинтересованных лиц. Эти трудности преодолимы, если использовать customer development для исследования потребностей клиента и Scrum для быстрой проверки продуктовых гипотез.
CustDev — один из элементов методологии Lean Startup, которая, в свою очередь, является одним из Agile-подходов при создании продуктов.
В целом Agile отлично сочетается с мобильной разработкой: она требует быстрой реакции, вовлечения и слаженной работы разных специалистов, возможности быстро предоставить результат и при необходимости изменить его.
Кроме Scrum здесь можно использовать и ориентированные непосредственно на мобильную разработку подходы. Например, Mobile-D базируется на XP, Crystal и RUP — подходах достаточно древних и хорошо отработанных. Главное отличие Mobile-D от Scrum: наличие четких фаз и главенствующий акцент на инженерной стороне развития продукта. Если Scrum уделяет больше внимания управлению и поставке продукта, то Mobile-D сосредоточен на процессе производства и включает практики XP, существенно улучшающие качество конечного продукта. В то же время сказывается влияние RUP, поэтому процесс довольно формализованный.
Другой, наиболее современный подход к мобильной разработке — SLeSS, совмещающий Scrum и Lean Six Sigma. Сперва он реализует постановку рабочего процесса по Scrum, а затем применяет подходы Lean Six Sigma для статистического управления качеством. Мне кажется, SLeSS сочетает в себе необходимую гибкость с механизмами обоснованного принятия решений на основе статистики.
В то же время, Scrum Guide изначально не запрещает включать в рабочий процесс Scrum какие-то другие подходы и инструменты, которые могут быть полезными для разработки продукта. Поэтому всё вышесказанное можно реализовать и в рамках «классического» Scrum.
— Насколько гибкие методологии поддаются модификации под частные условия?
Здесь надо рассматривать по отдельности Scrum и Канбан.
Scrum — это фреймворк, то есть каркас, все элементы которого обязательны: и мероприятия, и роли, и артефакты. Ни один нельзя выбросить. Зато нету жестких требований к тому, как именно эти элементы претворять в жизнь — делайте, как вам удобно. И Scrum не запрещает добавлять новые элементы: встречи, артефакты, роли, которые вам нужны для работы и помогают ускорять процесс.
Канбан — набор инструментов и метрик. Он не даёт жёстких установок про то, какие именно инструменты и в какой комбинации применять, поскольку рассчитан на долгое эволюционное изменение существующей системы. Но в то же время успех Канбана определяется сбором данных о рабочем процессе и их регулярным анализом. Если этого не делать, со временем всё заглохнет и дальнейших улучшений не будет. Но ничего страшного: как говорил Эдвард Деминг, вы не обязаны меняться, выживание — дело добровольное.
— Какие типичные ошибки при адаптации Scrum совершает бизнес?
Главная ошибка при реализации гибких методологий — применение инструментов без понимания того, зачем конкретно их нужно использовать.
Например, в больших организациях при внедрении Scrum зачастую просто переименовывают проектного менеджера во владельца продукта, а проектную команду — в Scrum-команду и начинают требовать выдать готовый результат за две недели. Но это не работает, и по очень простой причине: не выполнены условия, при которых Scrum может работать.
- Проектного менеджера хоть и окрестили Владельцем Продукта, однако он не получил необходимых полномочий и поэтому не вправе формировать видение продукта или менять приоритеты реализации. Как и раньше, он вынужден согласовывать каждый свой шаг с руководством и зажат в рамки требований по срокам и объёму работ. А значит, скорость принятия решений осталась прежней. Никакого ускорения или адаптации под меняющиеся условия.
- Проектную команду хоть и назвали Scrum-командой, но люди, включённые в неё, по-прежнему могут числиться каждый в своём отделе и подчиняются непосредственно своим линейным руководителям. Соответственно, каждый из участников команды прежде всего делает то, что ему поручит его линейный руководитель, а не Владелец Продукта. Как следствие, задачи по продукту будут всегда ниже по приоритету, а значит, скорость реализации продукта, под который «собрали» Scrum-команду, никак не повысится.
- Скорее всего, как и прежде, участники команды будут заняты и в других проектах. В то время как Scrum прямо оговаривает: участники команды должны быть выделены в Scrum-команду на 100 % своего рабочего времени, и заниматься только тем продуктом, которые ведет их Владелец Продукта. Если люди «поделены на проценты» между проектами/продуктами, то они будут переключаться между ними, что резко снизит как вовлеченность, так и эффективность работы над каждым конкретным проектом/продуктом.
Негативных последствий у такого неумелого «внедрения» множество, а начинаются они с попытки воспроизвести механику, но не суть Scrum. Основные ошибки в реализации Scrum я подробно описал в своём докладе «Стоп-сигналы для Agile» на конференции CodeFest 2017.
— Как оценить, насколько грамотно гибкие методологии внедрены в компании?
Существует тест Scrum Open, однако он служит скорее для проверки теоретических знаний. Что происходит на практике, он понять не даёт. С учётом того, что основа Scrum — это командная работа, а его приоритетом является скорость поставки продукта и ценность для потребителя, правильнее всего проводить опросы 360. Так надёжнее устанавливать степень зрелости команды и удовлетворенность заказчика.
Мы используем собственную методику, которую воплотили в сервисе ScrumTrek Diagnostic Tool. Работает она так. Команде и заинтересованным лицам вне её задаётся ряд вопросов о том, как они оценивают уровень командного взаимодействия, планирование своей работы, ценность поставляемого заказчику результата, взаимодействие с другими командами и так далее. По каждому параметру высчитывается медиана мнений и строится комплексная круговая диаграмма — Радар, который отображает взгляд как изнутри команды, так и снаружи.
Радар ScrumTrek. Смотрим на разброс оценок
Радар ScrumTrek. Смотрим на медианы
Схема содержит много полезной информации.
- Атомарные оценки отдельных людей и их средние интересны сами по себе, тут пояснения не нужны.
- Разброс оценок в команде — интересная вещь. Когда он очень большой, есть повод договориться о том, что мы как команда подразумеваем под тем или иным аспектом нашей работы. Что мы имеем в виду под «ценностью для клиента», например? А «скорость поставки»? Большой разброс свидетельствует о том, что в команде не сформирована единая позиция по ряду вопросов.
Маленький разброс говорит о консенсусе и хорошем взаимодействии внутри команды.
- Оценки разбиты по категориям. Можно заметить, что с культурой всё хорошо, а вот производительность кое-где проседает. Понятно, куда «копать».
- Отличие между оценкой внутри и вне команды — это один из самых важных показателей, он показывает расхождения между ожиданиями заказчиков и других заинтересованных лиц от команды и тем, как команда сама себя воспринимает. Agile — про тесное взаимодействие бизнеса и тех, кто реализует продукт, поэтому эти расхождения — отличный повод «сверить часы» между этими двумя областями и договориться о том, как перестроить работу команды.
После сбора данных обязательно проводится анализ диаграммы с привлечением всей команды и заинтересованных лиц. Всё, чтобы показать им, как выглядит работа команды с разных сторон, и переработать результаты анализа в конкретные шаги по улучшению работы.
О командах, внедряющих Scrum
— От кого в компании должна исходить инициатива внедрения методологий гибкой разработки?
Внедрение Scrum всегда идёт от бизнес-цели. Поэтому первым об ускорении должен задуматься заказчик — либо внутренний, либо внешний. Потом нужно проработать концепцию продукта, чтобы его можно было делать итеративно. И только затем формировать команду. Scrum ради Scrum не работает. Более того, он может оказаться слишком дорогим для решения конкретных задач.
Кто будет «проводником Agile» в компании, вопрос без единственно верного ответа. Я видел, как «зачинщиком» изменений становился технический директор. Были случаи, когда инициатива исходила от бизнеса, и даже видел, как такая инициатива зарождалась «снизу». Всё зависит от энергии и мотивированности человека, от того, сумеет ли он встроить своё видение разработки с использованием гибких подходов в бизнес-контекст продукта или подразделения.
Идеально, когда инициатива исходит от топ-менеджмента. Подвижки в эту сторону на российском рынке заметны.
— Какие новые роли и функции возникают в организации или команде с внедрением гибких методологий? Какие из них обязательны, какие опциональны?
В случае со Scrum это роли Scrum-мастера, владельца продукта и команды разработки. Все они обязательны. Команда разработки тоже считается «ролью», так как объединяет в себе не только разработчиков, но и всех, кто нужен, чтобы продукт в принципе появился: аналитиков, дизайнеров и так далее.
У Scrum-мастера и владельца продукта могут быть помощники, берущие на себя часть их обязанностей, притом что ответственность за результат остаётся за Scrum-мастером или владельцем продукта.
Владелец продукта — зачастую человек от бизнеса. Но не обязательно: скажем, если мы создаём какое-то инженерное решение для производства, эту роль может исполнять главный инженер. В конечном счёте это человек, который лучше всех понимает, для какого потребителя мы делаем продукт, какие проблемы тот решает в первую очередь, как должны выстраиваться приоритеты при его создании. Очень важно, чтобы владелец продукта имел полномочия самостоятельно определять состав продукта на основании данных с рынка и от потребителя. У него должно быть право говорить «нет» заинтересованным лицам, с которыми он взаимодействует. Это нужно, чтобы приоритеты были согласованны, а решения принимались оперативно.
Scrum-мастер — человек, чья задача — создание сильной, сплочённой, ответственной, а в идеале самоорганизованной команды. Что важно, это не тимлид, то есть — не руководитель. Scrum-мастер не имеет права давать руководящие указания или напрямую вмешиваться в разработку продукта. Он — организатор, фасилитатор, коуч и Agile-практик. По моему опыту, лучшие Scrum-мастера получаются из проектных менеджеров — при условии, что они прошли обучение и сумели перейти от директивного формата общения к коучинговому.
Пример. Приходит подчиненный к руководителю, и говорит: «Я не могу выбрать из двух вариантов реализации какой-то наилучший. Реши ты!»
Если использовать коучинговый подход, то руководитель начнет задавать вопросы: почему именно эти два варианта ты выбрал? А из чего ты исходил? В чем для тебя трудность в выборе между ними? Кто тебе может помочь еще? И так далее. Через вопросы руководитель-коуч помогает человеку исследовать возможные варианты. В итоге человек уже сам понимает, как ему лучше поступить, и руководителю останется только договориться о сроках, когда подчиненный придет и расскажет, что у него получилось.
Следующий шаг за делегированием — визирование. В визирующем подходе сотрудник или команда выходят на такой уровень зрелости и ответственности, что руководитель дает только верхнеуровневую постановку задачи с точки зрения бизнеса. Сотрудник или команда самостоятельно рассматривает варианты решений, оценивает сроки, выявляет риски. Руководитель просто визирует всё это, возможно — добавляет что-то с точки зрения своей экспертизы и вносит какие-то коррективы. Затем договариваются о временных вехах, когда нужно будет показать результаты. Дальше сотрудник или команда несет всю ответственность за реализацию и демонстрацию результатов. В визирующем подходе руководитель выступает только как куратор и помощник для сотрудника или команды в рамках реализации ими бизнес-задачи.
Кстати, о коучинговом стиле общения. Ещё бывает Agile-коуч. Его задача — настроить рабочий процесс, обучить людей и дать им инструменты для повседневной деятельности в рамках Agile. В том числе инструменты разрешения конфликтов. Всё остальное вне сферы его компетенции. В идеале Agile-коуч должен так наладить работу команды или даже отдела, чтобы всё работало само, и Agile-коуч стал не нужен.
Переходный период всегда сопряжён с дискомфортом. Agile-коуч призван помочь команде пройти этот период с минимальными трениями и выработать новые — удобные и эффективные — приёмы работы.
При масштабировании могут вводиться дополнительные роли, как описано, например, во фреймворке SAFe, но в их основе всё равно лежит круг полномочий и принципы работы Scrum-мастера или владельца продукта: просто появляются уровни иерархии относительно продукта.
— Как разграничиваются функции владельца продукта и Scrum-мастера «в идеальном мире»?
На одной чаше весов — интересы бизнеса, которые представляет владелец продукта, на другой — жизнеспособность и эффективность команды, за которую отвечает Scrum-мастер. Чтобы команда быстро достигала результатов, система должна пребывать в балансе. Если «пережмёт» владелец продукта, команда будет работать ночами и в выходные, и вскоре он окажется перед кучкой демотивированных, невовлечённых людей вместо слаженной команды. Если одеяло перетянет на себя Scrum-мастер, разработка будет вестись ни шатко, ни валко, с постоянными спорами и гораздо дольше нужного.
Владелец продукта: Так! Нам надо будет сделать воооот такую фичу! Вы в прошлый спринт отлично поработали, так что, я думаю, вы всё успеете!
Scrum-мастер: Но в прошлый спринт фичу подобной сложности команда сделала на пределе сил, пришлось выходить в выходные, и кое-кто работал по ночам. Еще один такой спринт — и люди начнут заболевать, выгорать и, может быть, начнется исход. Давай не будем до этого доводить?
Владелец продукта: Неужели всё так серьезно? Если да — давай с командой обсудим, что можно сделать за спринт, не выжигая людей. В этой фиче есть часть, которую надо будет сделать обязательно, она не выглядит сильно сложной.
Scrum-мастер: Давай обсудим с командой. Ты знаешь, что только она может сказать, «сложная» это задача или нет.
Владелец продукта: Давай.
— Какие методологии и управленческие модели стоит освоить тем, кто собирается браться за одну из ранее описанных ролей?
По части бизнес-компетенций всё «по классике», как с обычным менеджментом, за исключением необходимости определять приоритеты по этапам и теснее взаимодействовать с командой.
Владельцу продукта стоит освоить Lean Startup, customer development и другие современные подходы к созданию продуктов.
Для Scrum-мастера набор компетенций шире: фасилитация, конфликтология, групповая динамика, коучинг и, конечно, практика Agile. Это, скорее, навыки из области психологии, поэтому чувствуется их недостаток при обучении менеджеров.
— Действительно ли коллективное владение кодом снижает зависимость компании от «звёздных» разработчиков? Не падает ли их мотивация?
Коллективное владение кодом осуществимо и без гибких методологий. Достаточно договорённостей о code review и других формальных правил, а разработчики могут действовать атомарно.
Зачастую компания сама провоцирует «звёздное» поведение инженеров: на первый взгляд, ей выгоднее раскошелиться на суперспециалиста и поручить ему целое направление при полной его ответственности за результат, чем собирать команду середнячков, системно снижать риски вследствие ошибок, повышать их профессионализм.
Это дилемма: или краткосрочный, или долгосрочный успех. Кажется, что наём «звезды» — благо для бизнеса. Но что будет через три года, через пять, через семь лет после того, как такой профи присоединился к компании? Он станет незаменимым. И как минимум с тремя негативными последствиями.
Во-первых, у такого человека почти нет свободного времени, и компании, по большому счёту, это безразлично. Её логика: «Мы тебе платим огромную зарплату не для того, чтобы ты отдыхал». Попадая в подобную ситуацию, люди быстро выгорают, впадают в цинизм и стараются извлечь максимум выгод из своего положения.
Во-вторых, незаменимый сотрудник начинает заправлять приоритетами компании. Вместо того чтобы воплощать замысел бизнеса, он может самостоятельно принимать решения о том, что нужно, а что не нужно делать. И рычагов влияния на него нет: за несколько лет он узнал о продукте и системе всё, и ужас в том, что, как правило, больше него не знает никто. Такие специалисты будут тщательно оберегать свои знания, свою экспертизу как страховку от увольнения или понижения зарплаты.
В-третьих, достижения такого человека невозможно «масштабировать». Если вы задумали расширять команду разработки, будьте готовы к большой текучке: новичков будут отторгать, махровым цветом расцветёт «дедовщина», так как «старичкам» окажется невыгодно делиться опытом и знаниями. Ускорить разработку тоже едва ли удастся: всё упрётся в производительность отдельно взятого и незаменимого Васи Пупкина, которого всё устраивает, и который не собирается ничего менять.
— Что предпринять, чтобы всё-таки перейти к командному подходу?
- Принять риск того, что мы неизбежно потеряем часть текущей команды «звёзд»: не все согласятся с новым подходом. Это неизбежно.
- Изменить структуру поощрений. Например, ввести бонусы за написание документации или за обучение новых сотрудников, чтобы постепенно это стало обыденной практикой.
- Среди «звёзд» найти тех, кто хочет расти, и помочь им освоить навыки менеджмента, фасилитации, коучинга. Открыть им новые горизонты. Не все на это согласятся. Зато те, кто согласится, будут лучшими приверженцами новых принципов работы.
- Размывать культуру «дедовщины». В том числе вырывать «звёзд» из их привычной среды, например формируя новые команды по принципу «четыре-пять новичков на одного старичка». Плюс в такой команде нужно назначать умного и умелого Scrum-мастера, который даст понять «старичку», что ему ничто не угрожает, и в то же время настроит «новичков» на то, чтобы они с уважением относились к тем, кто знает больше них. И хорошо, если такая команда будет сидеть не в том месте, где раньше работал «старичок».
Помните, мы имеем дело с трансформацией корпоративной культуры, а это задача архисложная. Как сказал Питер Друкер, «культура ест стратегию на завтрак». Сколь бы совершенную формализованную стратегию вы ни предложили, её не удастся воплотить в жизнь, если у людей «не принято» соответствующее поведение. Чтобы лучше разобраться в вопросе, советую прочесть книгу Даниэль Браун и Итске Крамер «Корпоративное племя. Чему антрополог может научить топ-менеджера».
Материал подготовила команда Mail.Ru Cloud Solutions.
Автор: pxeno
