company_banner

Все дело в Agile — 2: особенности внедрения гибкой разработки



    Продолжаем про нюансы гибкой разработки (Agile), которые случаются на практике. Как понять, правильно ли внедрен Agile, какая практика годится для какой задачи и отрасли, кто в компании должен переводить работу на «Agile-рельсы»? Своим опытом с редакцией блога Mail.Ru Cloud Solutions продолжает делиться Agile-коуч ScrumTrek Василий Савунов.

    В прошлый раз Василий рассказал, что такое Agile, какие он включает методологии и какие вокруг него сформировались стереотипы. Теперь поговорим о его внедрении.

    О компаниях, использующих Agile


    — Есть ли «отраслевые предпочтения» в гибких методологиях?

    Как показывает исследование Agile Russia, которое мы проводим второй год подряд, в сфере разработки ПО преимущественно используется Scrum, в финансовых организациях — Канбан, а в телеком-индустрии — и то, и другое.

    Как человек, который непосредственно анализировал собранные данные, и работавший со многими из респондентов, я считаю, что такое положение вещей обусловлено двумя причинами:

    • Скорость изменений в IT значительно выше, чем в финансах. Поэтому там предпочтителен Scrum как подход, позволяющий за счёт быстрых экспериментов гибко управлять приоритетами и менять направление в зависимости от изменений внешней среды и условий «на входе». Финансы более консервативны.
    • Стоимость ошибки в финансах гораздо выше, чем в IT-разработке. Поэтому в них больше ценится Канбан, основанный на математике, а не на экспериментах, и позволяющий посредством небольших, но постоянных изменений улучшать рабочий процесс в целом.

    Телекому Канбан тоже подходит. Хотя бы потому, что вектор развития отрасли — цифровизация. Однако пока мало кто понимает, как конкретно она должна выглядеть. Кроме того, в телекоме «быстрая» часть работы (разработка ПО) соседствует с «медленной» (поддержка и развитие аппаратной инфраструктуры). Поэтому наряду с экспериментами, которые проводятся по Scrum, имеет смысл эволюционно ускорять текущие процессы с применением Канбана.


    Методики гибкой разработки, принятые в разных отраслях. Суммы не равны 100 %, потому что можно было выбирать более одного пункта. Изображение/ScrumTrek

    — А как дела у мобильных разработчиков? Есть ли у Agile специфика в мобильной разработке?

    С моей точки зрения, основная трудность при разработке мобильных приложений — выявление требований к приложению, потому что бывает сложно идентифицировать заинтересованных лиц. Эти трудности преодолимы, если использовать customer development для исследования потребностей клиента и Scrum для быстрой проверки продуктовых гипотез.

    Customer development
    Customer development, custdev, кастдев, развитие клиента (интересно, а так вообще кто-то говорит?) — это подход к созданию продукта через постоянное тестирование на реальном рынке и улучшение по результатам этих экспериментов. Это сближает кастдев с научным методом, делает создание продукта «научно обоснованным».

    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-мастера или владельца продукта: просто появляются уровни иерархии относительно продукта.

    SAFe
    SAFe, или Scaled Agile Framework — фреймворк для применения Agile в крупных командах по разработке ПО. В самой простой реализации подход предполагает два уровня: командный и программный (Team и Program соответственно), по мере усложнения оргструктуры и продукта к ним добавляются Portfolio и Large Solution. Работа по SAFe опирается на такую сущность, как ART (Agile Release Train) — «поезд релиза». Она, как правило, объединяет несколько команд и заинтересованных лиц в структуру, на протяжении длительного времени сообща создающую продукт или часть продукта, которая представляет ценность для заказчика.

    — Как разграничиваются функции владельца продукта и Scrum-мастера «в идеальном мире»?

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

    Пример
    Чтобы это не было абстрактным, вот выдуманный микродиалог внутри команды. Посмотрите, что говорит каждый из своей роли:

    Владелец продукта: Так! Нам надо будет сделать воооот такую фичу! Вы в прошлый спринт отлично поработали, так что, я думаю, вы всё успеете!

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

    Владелец продукта: Неужели всё так серьезно? Если да — давай с командой обсудим, что можно сделать за спринт, не выжигая людей. В этой фиче есть часть, которую надо будет сделать обязательно, она не выглядит сильно сложной.

    Scrum-мастер: Давай обсудим с командой. Ты знаешь, что только она может сказать, «сложная» это задача или нет.

    Владелец продукта: Давай.

    — Какие методологии и управленческие модели стоит освоить тем, кто собирается браться за одну из ранее описанных ролей?

    По части бизнес-компетенций всё «по классике», как с обычным менеджментом, за исключением необходимости определять приоритеты по этапам и теснее взаимодействовать с командой.

    Владельцу продукта стоит освоить Lean Startup, customer development и другие современные подходы к созданию продуктов.

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

    — Действительно ли коллективное владение кодом снижает зависимость компании от «звёздных» разработчиков? Не падает ли их мотивация?

    Коллективное владение кодом осуществимо и без гибких методологий. Достаточно договорённостей о code review и других формальных правил, а разработчики могут действовать атомарно.

    Зачастую компания сама провоцирует «звёздное» поведение инженеров: на первый взгляд, ей выгоднее раскошелиться на суперспециалиста и поручить ему целое направление при полной его ответственности за результат, чем собирать команду середнячков, системно снижать риски вследствие ошибок, повышать их профессионализм.

    Это дилемма: или краткосрочный, или долгосрочный успех. Кажется, что наём «звезды» — благо для бизнеса. Но что будет через три года, через пять, через семь лет после того, как такой профи присоединился к компании? Он станет незаменимым. И как минимум с тремя негативными последствиями.

    Во-первых, у такого человека почти нет свободного времени, и компании, по большому счёту, это безразлично. Её логика: «Мы тебе платим огромную зарплату не для того, чтобы ты отдыхал». Попадая в подобную ситуацию, люди быстро выгорают, впадают в цинизм и стараются извлечь максимум выгод из своего положения.

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

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

    — Что предпринять, чтобы всё-таки перейти к командному подходу?

    • Принять риск того, что мы неизбежно потеряем часть текущей команды «звёзд»: не все согласятся с новым подходом. Это неизбежно.
    • Изменить структуру поощрений. Например, ввести бонусы за написание документации или за обучение новых сотрудников, чтобы постепенно это стало обыденной практикой.
    • Среди «звёзд» найти тех, кто хочет расти, и помочь им освоить навыки менеджмента, фасилитации, коучинга. Открыть им новые горизонты. Не все на это согласятся. Зато те, кто согласится, будут лучшими приверженцами новых принципов работы.
    • Размывать культуру «дедовщины». В том числе вырывать «звёзд» из их привычной среды, например формируя новые команды по принципу «четыре-пять новичков на одного старичка». Плюс в такой команде нужно назначать умного и умелого Scrum-мастера, который даст понять «старичку», что ему ничто не угрожает, и в то же время настроит «новичков» на то, чтобы они с уважением относились к тем, кто знает больше них. И хорошо, если такая команда будет сидеть не в том месте, где раньше работал «старичок».

    Помните, мы имеем дело с трансформацией корпоративной культуры, а это задача архисложная. Как сказал Питер Друкер, «культура ест стратегию на завтрак». Сколь бы совершенную формализованную стратегию вы ни предложили, её не удастся воплотить в жизнь, если у людей «не принято» соответствующее поведение. Чтобы лучше разобраться в вопросе, советую прочесть книгу Даниэль Браун и Итске Крамер «Корпоративное племя. Чему антрополог может научить топ-менеджера».

    Материал подготовила команда Mail.Ru Cloud Solutions.
    • +17
    • 5,5k
    • 3

    Mail.Ru Group

    866,00

    Строим Интернет

    Поделиться публикацией
    Комментарии 3
      0
      Как-то пробовал проанализировать попарные противоречия на своем проекте, который работает по SAFe. Много пар параметров проанализировал. Основным тормозом оказалась параноидальная система безопасности, которая даже не дает работникам получить полное понимание контекста (по agile). Чем больше и устойчивее бизнес, там больше они вкладывают в безопасность и тем сильнее она тормозит благие начинания.
        0
        Не знаю, насчет в целом. Но по РФ сложилось впечатление, что привычка притаскивать в ИБ различных силовиков превращает ИБ в ИБД. В итоге куча дырявых инструкций, которые тормозят всех и останавливают только откровенных наглых лохов, но практически бесполезны против тех, кто хоть чуть чуть разбирается в вопросе.
          0
          Не знаю, как у вас, но у нас паранойя довольно продвинутая — слежка за почтой,
          слежка за установленным софтом,
          расшифровка ssl,
          слежка за действиями в базе данных и т.п.

          Большинство фильтров срабатывает автоматически. Приходят или уведомления по почте в случае незначительных оплошностей… или сразу прилетает начальнику, а он по цепочке спускает вниз.

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое