Как «продать» Аджайл разным людям в организации

Как «продать» Аджайл разным людям в организации

Agile и Scrum тренинги и сертификации 2019

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

«Продаем» разработчикам

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

Сопротивление

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

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

Микроменеджмент

Удивительно много разработчиков видит Аджайл-процесс как попытку микроменеджмента. Подходы типа Скрама и XP сокращают и увеличивают частоту циклов в проектах, так что разработчики контактируют с менеджерами чаще, но в более короткие промежутки. В более традиционной модели менеджер может не общаться с разработчиком целую неделю, но для Аджайл-процесса ежедневный контакт нормален.

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

Переход при тяжеловесности процесса

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

Медленный переход с тяжеловесного планирования на Аджайл тоже может облегчить дело для команды. Многие команды, переходя на Скрам, поначалу бывают ошарашены внезапной свободой от диаграммы Ганта, которая направляла бы все действия. Мы помогли таким командам с переходом, выделив несколько типов спринтов:

  • прототипирование,
  • взятие требований,
  • анализ дизайна,
  • имплементация,
  • стабилизация.

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

Распределенная разработка

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

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

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

Нужны настоящие таланты

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

Хотя разница между программистами в продуктивности может превышать известное соотношение 10:1, продуктивность в разработке, ориентированной на поставку, важнее всего. Различия продуктивности не так важны на проектах, где программисты выполняют много нерелевантных действий. Но когда разработчики полностью включаются в Аджайл, они должны двигаться быстро. Медленная работа одного будет тормозить всех.

Слишком старательные команды

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

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

Тестировщики и другие не-кодеры

Написание исходного кода — главная активность в любом процессе разработки, но в Аджайл-процессе оно особенно важно: без него и разработка — не разработка.

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

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

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

Стоит убеждать тестировщиков не делать такого, особенно на ранних стадиях проекта. Во-первых, если тестировщик знает о программировании достаточно и вам нужен программист, наймите тестировщика как программиста. Во-вторых, тесты, написанные для других, могут быть полезными, но все равно потеряют часть преимуществ «белого ящика», которые есть у самописных юнит-тестов.

 

Agile и Scrum тренинги и сертификации 2019

 

«Продаем» аппер-менеджменту

Эту группу людей волнуют обычно вопросы четырех типов:

  • Как мы можем обещать заказчикам новые фичи?
  • Как отслеживать продвижение?
  • Как Аджайл-процесс отразится на других группах людей (не разработчиках)?
  • Когда именно заканчивается проект?

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

Обещания заказчикам

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

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

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

Отслеживание продвижения

Планирование привлекает многих менеджеров потому, что в нем легко почувствовать законченность задачи, держа в руках необходимые документы.

Чтобы убедить менеджеров, что в Аджайле тоже есть возможность следить за выполнением задач, мы обычно создаем один-два статус-отчета, которые построены на выдуманных данных о некой организации, переходящей на Аджайл. Они отражают циклы по две недели-месяцу.

Типовой отчет по Скрам-процессу включает список ключевых дат, комментарий о состоянии проекта в 2-5 абзацев и список ключевых рисков. Лица, принимающие решения, с которыми нам приходилось работать, обычно вполне удовлетворяются таким документом.

Влияние на другие группы

Некоторые из вышестоящих менеджеров волнуются, что Аджайл-процесс может оказаться полезным для разработчиков, но не всегда — для других отделов. Это волнение становится нездоровым, когда процессы в других отделах отрицательно влияют на труд разработчиков. Например, у одного нашего клиента разработчики хотели использовать Скрам, а группа менеджеров продукта настаивала на принципе водопада. СЕО компании не видел проблемы в том, чтобы каждая из этих групп работала по своей стратегии. В результате разработчики получили подробную спецификацию в 2000 страниц, которую нужно было отприоритезировать и разбить на месячные отрезки работы.

Группе разработчиков нужно было угадывать приоритеты по спискам задач от продактов на 3-4 месяца. Впрочем, как только группа освоила Скрам, она стала выполнять требования раньше, чем другие группы успевали их писать.

При переходе на Аджайл менеджменту стоит понимать и согласовывать то, как Аджайл-процесс повлияет на другие группы. Если этого понимания и согласованности нет, усилия могут оказаться напрасными.

Окончание проектов

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

Работать здесь можно так же, как и в случае с отслеживанием продвижения и статус-отчетом, только добавить бюджетирование и стратегическое планирование. Например, мы оценили, что один коммерческий проект займет от 9 до 15 месяцев — довольно неточная оценка, ведь мы не знали точно, какие фичи должны быть в готовой системе. Однако независимо от того, сколько финтифлюшек понадобилось бы клиенту, мы были уверены, что подходящий исходный релиз состоится через девять месяцев. Так что мы убедили менеджеров профинансировать эти девять месяцев с оговоркой, что обсудим дополнительное финансирование в конце этого периода.

 

Agile и Scrum тренинги и сертификации 2019

 

«Продаем» HR-специалистам

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

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

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

 

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

 

Переведено и адаптировано командой BrainRain по статье Майка Кона и Дорис Форд Introducing an Agile Process to an Organization

 

Также рекомендуем:

Аджайл методология: работа по Аджайлу в нетехнических командах

Организации на пути к Agile: Management 3.0

How to convince your boss and make them say “Yes!” to Chaos Engineering?

 

Всего комментариев: 0

Оставить комментарий

Ваш email не будет опубликован.

Будь в курсе! Подпишись на scrum-новости