Agile для корпораций

Agile-методология стала стандартом де-факто разработки программного обеспечения, однако в регулируемых отраслях, таких как финансы, медицина и пр., по-прежнему используют традиционные подходы. Причины — боязнь неудачи, сопротивление переменам, архаичные требования регуляторов [1], нехватка финансирования, отсутствие инноваций, технический долг и др. Проблемы крупных организаций во многом связаны со сложившейся корпоративной культурой и консерватизмом руководства [2]. В отличие от стартапов, которые быстро внедряют DevOps, непрерывную интеграцию и развертывание и другие современные концепции, корпорации обычно воздерживаются от масштабных изменений. Социологи утверждают, что сопротивление переменам в таких организациях — результат прочно укоренившихся приобретенных предрасположенностей, индивидуальных и коллективных [3]. Однако компании, неспособные адаптироваться и осваивать новые разработки, просто не выживут в долгосрочной перспективе. Иначе говоря, отказ от Agile в современных условиях — фатальная ошибка. Разберем проблемы, с которыми сталкиваются команды разработки на крупных предприятиях при внедрении agile-методик, а также возможные пути их преодоления.

Люди склонны сопротивляться переменам. Когда в организации происходят масштабные изменения, им оказывают сопротивление как отдельные сотрудники, так и коллективы в целом [3]. Решая задачи привычными способами, работники не видят оснований менять подходы, и их не убеждают свидетельства в пользу эффективности новшеств. В традиционных командах действует жесткое разделение обязанностей между разработчиками, специалистами по анализу требований, системными аналитиками, инженерами контроля качества, руководителями разработки и др. Участники группы, не являющиеся разработчиками, не обучались программированию и хотят сохранить должности, особенно с учетом различий в уровнях оплаты труда разработчика, аналитика и архитектора. В некоторых группах уверены, что для внедрения Agile достаточно ведения «пользовательских историй» (user story) и ежедневных «стоячих совещаний» (daily standup). При этом руководитель проекта составляет его план с вехами, запланированными на конкретные сроки, а ход работы документируется на графике, вывешенном на стене кабинета, — эта необходимость обосновывается требованиями руководства и бизнес-партнеров. Казалось бы, подобные команды на самом деле не особенно стремятся переходить на Agile, но это не всегда так: масштабные изменения в больших организациях невозможно провести в короткие сроки с учетом того, сколько поставлено на карту.

Обучение

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

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

Поддержка со стороны бизнеса

Внедрение Agile в организации, практикующей каскадную разработку, неизбежно сопровождается конфликтами. Владельцы бизнеса привыкли устанавливать твердую дату выпуска, а инженеры ПО — формулировать требования клиентов. Руководство рассчитывает на то, что очередной проект будет запущен в эксплуатацию в четко определенный срок. Если же отдел ИТ сообщает бизнесу, что продукт или функция будут разрабатываться и выпускаться в инкрементальном режиме, в этом видят препятствие для осуществления планов компании. Чтобы адаптироваться к принципам Agile, придется менять не только процесс разработки, но и роли, обязанности и образ действий участников. Единственный способ заручиться поддержкой представителей бизнеса — объяснять, в чем преимущество новшества именно для них. И служба ИТ, и бизнес-отделы прекрасно знакомы с рисками проектов разработки ПО. В числе типичных проблем традиционного цикла — срыв проектов, неспособность реализовать изменения требований, плохо организованный обмен информацией, непонимание требований бизнеса и др. При переходе на Agile понимание того, что бизнесу нужен работоспособный продукт, подстегивает желание работать на результат. Можно объяснить бизнесу концепцию минимально жизнеспособного продукта и рассказать о возможности реализовать дополнительные функции в последующих итерациях. Когда бюджет проекта зафиксирован, можно разрабатывать столько функций, сколько он позволяет.

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

Scrum-мастер

Традиционная система субординации крупного предприятия не вполне совместима с манифестом Agile, согласно которому участники команды разработки равноправны. Еще одна сложность — убедить руководителей в необходимости перейти от командно-административного стиля управления к принципу наставничества и лидерства. Scrum-мастер отвечает за проведение agile-совещаний и планирование спринта. Администрация может воспринимать его как менеджера и назначить всех руководителей команд разработки Scrum-мастерами, не учитывая реальных требований к человеку на этой позиции, который должен выполнять роль лидера и тренера для команды. Если у него нет нужных навыков, может пострадать самоорганизация коллектива. Становясь Scrum-мастером, экс-менеджер пытается руководить в старом стиле, но командно-административный подход в Scrum-команде неприменим.

Проблемы

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

Слишком много совещаний

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

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

Проверяемые критерии приемки

Формулировка измеримого критерия приемки — часть процедуры создания пользовательской истории, и с этим могут возникнуть сложности. Допустим, представители бизнеса привыкли взаимодействовать с командой разработки по электронной почте или путем открытия запросов на обслуживание, но опыта формулировки проверяемых критериев приемки у них нет. В случае простых функций это нетрудно, но с более сложными возникают проблемы, и для согласования критерия приемки с бизнесом может потребоваться длительная переписка по электронной почте. У бизнеса может быть лишь общее представление о желаемом, конкретные же предложения по реализации вынуждены подавать разработчики, а поток вопросов от них о требованиях может вызывать раздражение. Можно попытаться решить проблему путем сосредоточения на самих требованиях, а не на способах их выполнения. Скажем, вместо «отобразить ход конкурса путем подсветки другим цветом» можно написать: «отобразить ход конкурса с помощью индикатора выполнения». Разработчики также могут для начала сами подготовить ряд примеров критериев приемки, чтобы показать представителям бизнеса, как их лучше формулировать.

Те, кто придерживается каскадной модели, привыкли работать с электронными таблицами, текстовыми документами и сообщениями электронной почты. Чтобы переучиться на инструменты Agile, потребуется терпение, в них может быть немало недоработок, связанных с неинтуитивным интерфейсом, медлительностью сайтов, несовместимостью браузеров и др. Но, осваивая новые инструменты, можно научиться обходить проблемы популярных agile-средств.

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

Внеплановые запросы

Содержать команду разработки, которая занимается только одним конкретным проектом, могут позволить себе не все предприятия. Разработчики постоянно получают внеплановые запросы, что отвлекает их от основной задачи. Чтобы избежать этого, можно ввести правило, согласно которому все запросы включаются в список требований (бэклог), где им назначаются приоритеты. Если запрос срочный и подождать до окончания спринта нельзя, организуется внеочередное совещание, где обсуждается, у какого элемента спринта можно понизить приоритет, чтобы выполнить такой запрос. При этом обязанность приоритизации внеплановых запросов можно возложить на бизнес-партнеров. В результате преимущества Agile проявят себя во всей красе: участники команды смогут уделять все время и силы основной задаче, а продуктивность увеличится в разы.

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

Объединенная Scrum-команда

В сервисно ориентированных архитектурах обычно взаимодействуют несколько систем, обменивающихся данными, — например, центральная система оперативной обработки транзакций, хранилище данных и децентрализованные приложения, которые вызывают другие сервисы. На крупных предприятиях переход на Agile может быть очень постепенным: владельцы децентрализованного приложения могут работать в режиме Agile, а остальные отделы — практиковать старую каскадную схему. Но если бизнес требует добавить или изменить функцию приложения, разрабатываемого по принципу Agile, для этого может понадобиться доступ к другим сервисам, у которых еще нет соответствующих API. Как следствие, бизнес-партнерам приходится понижать приоритет запроса к agile-группе в ожидании реализации нужного API, что приводит к нарушению графика поставки. В этом случае о методах Agile уже речи не идет — создания API приходится ждать недели или месяцы. По мере роста числа команд, освоивших Agile, они тоже начинают жаловаться. Можно решить проблему на уровне всей организации, прибегнув к принципу «скрам над скрамом» (Scrum of scrums), когда несколько команд взаимодействуют как одна большая. Scrum-мастера всех команд раз в неделю совещаются, перечисляя рабочие элементы, ожидаемые от других команд. При этом достигается договоренность о взаимном выполнении таких запросов, создается общекорпоративный бэклог, доступный всем заинтересованным. В ходе общих совещаний этот перечень обсуждается и пользовательским историям, требующим взаимодействия нескольких отделов, назначается приоритет.

Тайное голосование

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

***

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

Литература

1. H. Mehrfard, A. Hamou-Lhadj. The impact of regulatory compliance on agile software processes with a focus on the FDA guidelines for medical device software // Int. J. Inf. Syst. Model. Design. — 2011. — Vol. 2. — P. 67–81. doi: 10.4018/jismd.2011040104.

2. D. A. Smet. Getting agile right in your organization. 2018. URL: www.mckinsey.com/businessfunctions/organization/our-insights/the-organizationblog/getting-agile-right-in-your-organization (дата обращения: 20.05.2020).

3. B. Shimoni. What is resistance to change? A habitus-oriented approach // Acad. Manage. Perspectives. — 2017. — Vol. 31, N. 4. — P. 257–270. doi:10.5465/amp.2016.0073.

Картхик Моханарангам ( karthik.mohanarangam@gmail.com ) — руководитель технических инициатив, Amazon.