Agile – это культура компании

Принципы и ценности Agile воплощены в различных методиках, каждая из которых делает акцент на определенных проблемах разработки ПО и пытается их преодолеть. Тщательно выбирая, настраивая, модифицируя и комбинируя эти методики, организация может многого добиться. Так, опираясь на две agile-методики (FDD и Kanban), наша компания смогла качественно улучшить работу подразделений, занятых созданием и развитием продуктов линейки Avanpost (IDM, PKI, Web SSO), а также управление потоком относительно небольших разработок, необходимых для внедрения и эксплуатации упомянутых продуктов.

Методика FDD (feature-driven development) ориентирована на создание сложного функционала. Я считаю, что именно она предпочтительна для разработки продуктов с длительным жизненным циклом, а также при внесении больших изменений (например, при выпуске мажорных релизов продукта) и в тех случаях, когда создаваемая программная система имеет настолько сложную архитектуру, что, не проработав ее тщательно на начальном этапе, разработчик обязательно получит множество практически неустранимых проблем на более поздних этапах цикла.

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

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

Kanban ориентирован на сокращение количества задач, которые имеют определенных статус, например, находящихся в работе.

Внедрение Kanban в команде проектной разработки мы начали в 2014 году. Мы хотели решить несколько проблем: повысить прозрачность работы команды (и каждого из ее членов), найти лекарство от «зависших» задач и обеспечить преемственность кода. На время кризиса, сопровождавшегося снижением числа внедрений и изменением обычной технологии работы, проект был приостановлен. В начале 2016 года он возобновился, а полный переход к гибкой методологии разработки во всех командах (включая разработку продуктов по методике FDD) произошел в 2016 году.

С помощью Kanban-доски (сначала физической, потом виртуальной) мы решили преодолеть несколько неприятных проблем, связанных со значительно выросшим числом внедрений нашей IDM-системы. В «Аванпосте» разработчики не закреплены за проектами внедрения, которые они обслуживают. Число одновременно выполняемых проектов превышает (зачастую значительно) количество разработчиков в группе. За ресурсы этой небольшой группы проектных разработчиков конкурируют проектные менеджеры (PM’ы). Проектные разработчики подчиняются мне. И раньше, чтобы продвинуть свои запросы, PM’ы постоянно пытались сами договариваться со мной и обращались через свое начальство или через генерального директора. Мне это не нравилось, и я активно искал решение.

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

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

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

Другое следствие прозрачности заключается в том, что теперь все видят, кто и как работает. И я как руководитель подразделения, и PM’ы, и сами разработчики. Видят, например, что за один и тот же период Вася передал на тестирование пять задач, а Петя — только одну. Это подталкивает самих разработчиков и выявляет проблемы с мотивацией. Если Петю не волнует, что другой человек сделал основную часть работы, то это повод для разговора. Напротив, устойчивые высокие показатели открывают возможности профессионального роста. Например, в «Аванпосте» карта развития сотрудника предусматривает возможность перехода из проектной группы разработчиков в продуктовую, где решаются существенно более сложные и интересные задачи.

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

В компании «Аванпост» подразделение разработки разделено на команды, развивающие основные продукты, и команду, работающую над задачами интеграции и кастомизации, которые поступают от заказчиков и интеграторов. Команда проектной разработки в силу специфики рабочего процесса использует Kanban. Продуктовые же команды работают по agile-методике,  близкой к FDD. Переход к Agile в продуктовой разработке параллельно с внедрением непрерывной интеграции (от сборки версии до развертывания и передачи в эксплуатацию) и автоматизированного тестирования позволил увеличить скорость выпуска релизов и соответственно реагирования на потребности пользователей и изменения рынка.

Приведу пример. Одна из самых сложных и важных задач при разработке нового мажорного релиза Avanpost IDM 6.0 заключалась в изменении архитектуры системы. До начала проекта архитектура IDM-системы была близка к микросервисам. Система состояла из ядра и целого ряда компонент, отвечавших за обработку заявок, отчетов, кадровую синхронизацию, подготовку кадровых данных и др. Это было удобно в плане управления командой разработчиков и не создавало никаких проблем, пока продукт был строго ограничен функциональностью IDM. Однако согласно долгосрочной стратегии компании главным направлением развития этого продукта становится движение в сторону систем класса IGA. В отличие от классического IDM, эффективная реализация функций IGA требует более глубокого взаимодействия сервисов. Это ведет к укрупнению и усложнению как самих сервисов, так и команд, отвечающих за их разработку. FDD справляется с обеими задачами.

При этом возникает тонкий эффект, меняющий наше отношение к методике SCRUM. Пока продукт развивался в сторону микросервисной архитектуры, на каждый сервис выделялась команда из двух (реже трех) разработчиков высокой квалификации. Переход к новой архитектуре, усложнение сервисов и их взаимодействия потребовал укрупнения этих команд и включения в их состав специалистов средней квалификации (мидлов). Побочным эффектом этого шага стало появление проблем коммуникации, которых раньше не было. Два примерно равных по квалификации разработчика, хотя и работали по схеме «ведущий – ведомый», хорошо понимали друг друга и легко договаривались. И такая работа была им интересна. А теперь они не хотят систематически контролировать мидлов. В результате разработчик средней квалификации за неделю может сделать не совсем то, что считает наиболее важным ведущий специалист. Простоя нет, но меняется траектория или темпы развития продукта. В этой ситуации SCRUM с ее проработанной системой разноплановых коммуникаций, вероятно, была бы весьма полезна.

Мы собираемся внедрить SCRUM еще и потому, что эта методика хорошо подходит для добавления функций в ПО с проработанной и стабильной архитектурой системы и моделью предметной области. Именно это требуется при выпуске промежуточных версий продуктов, и эти версии мы будем готовить, управляя разработкой по методике SCRUM. А к FDD будем возвращаться при создании мажорных релизов Avanpost IDM, PKI и Web SSO. Это, в частности, позволит оптимизировать расходы на разработку: FDD дороже SCRUM (за счет наличия аналитических этапов), и применение SCRUM на длинных отрезках жизненного цикла системы значительно снизит себестоимость ее развития. Таким образом, мы получим оптимальное сочетание трех весьма разных agile-методик: Kanban, FDD и SCRUM.

Я хотел бы обратить внимание еще на один момент – простоту модификации agile-методик. У нас, например, используются модифицированные варианты Kanban и FDD. Вносить такие изменения нетрудно, это позволяет экспериментировать, добиваясь максимального приспособления методик к особенностям организаций-пользователей.

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

Другой риск – организационный – связан с неготовностью организации к Agile. Даже в «Аванпосте», несмотря на хорошую подготовку проекта, внедрение Kanban вполне могло провалиться. Сначала менеджеры проектов внедрения были настроены против этой методики, ведь Kanban не устанавливает конечный срок выполнения задачи. Как же тогда можно что-то планировать? Но потом они оценили выгоду ускорения работы над задачами и полной прозрачности. А изменение произошло действительно радикальное: в 2014 году мы имели нескончаемую очередь задач, теперь же она всегда компактна, а иногда и пуста, хотя поток задач за этот период значительно усилился!

Есть риски, связанные с конкретными методиками. Так, SCRUM диктует многое в плане организации работ. Внедрить эту методику можно только при готовности бизнеса и заказчиков. Без этого переход или не состоится, или ничего не даст. Обязательно нужно добиться взаимодействия со смежными подразделениями (это важно не только для SCRUM) и работать с заказчиками, например, постараться постепенно повышать долю их требований, предоставляемых в формате пользовательских историй. К сожалению, это не всегда возможно: бывает, что у заказчика вообще нет человека, который может объяснить причину появления того или иного пункта ТЗ. Тогда приходится решать задачу, не понимая точно, зачем она нужна. В этой ситуации может быть полезным внесение таких изменений не в основной продукт, а в кастомную ветку, которая или постепенно обрастает большим числом специфических черт, или со временем будет отсечена, когда специфические черты будут перенесены в основной продукт или заменены функциями последнего.

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

Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!