Пару-тройку лет назад мы тоже с энтузиазмом взялись переходить на гибкие методологии разработки, а по-простому: внедрять Agile. Наняли внешних консультантов, выделили для обкатки процесса кусочек большого продукта, с воодушевлением начали быстро и качественно делать. Делали-делали, а потом поняли, что получается какая-то ерунда, а не Agile, как в том анекдоте про секретаршу и 1000 знаков. И вроде бы все молодцы, работают как раньше, люди опытные, и продукт работает, только всё как-то «не по Agile-у».
Мотивация в команде упала. Заказчики в растерянности от того, что предполагаемые «волшебные» сроки не сбываются, и вообще заявляют, что Agile не место в приличном обществе. В результате маленькая группка «Agile-трансформаторов» села и устроила мозговой штурм, почему же у нас ничего не выходит? Начали выписывать любые мешающие нам ограничения. Их оказалось очень много, и мы назвали их драконами.
В любой большой компании существует масса взаимозависимостей между процессами, продуктами и командами. И внедрение чего-либо нового — в нашем случае методологии Agile — требует разрыва мешающих связей и пересмотра многих процессов. И без ясного понимания, что именно тебе мешает и как с этим бороться, все добрые и прогрессивные начинания, скорее всего, будут обречены на провал.
Уже на той встрече, на которой мы обсуждали, что же мешает нам достичь заветного Agile, мы придумали называть преграды и помехи «драконами», которых нужно победить. И сразу прописали этапы победы над каждым из ящеров. Началось всё это два года назад, и большинство наших драконов уже повержены, хотя парочка ещё трепыхается.
Прежде всего нужно пояснить, что в нашем большом продукте помимо Agile параллельно применялся ещё и водопадный процесс разработки, который мешал нам внедряться: сначала шёл этап аналитики, затем этапы разработки и тестирования. Проблема в том, что когда аналитики освобождаются, они переключаются на другую задачу. А когда у разработчиков или тестировщиков возникают затруднения, и они обращаются к аналитикам, то у тех голова уже занята совсем другими задачами, им даже трудно вспомнить, что они делали на первом этапе. И то же самое можно было сказать про любое другое подразделение, которое в какой-то момент обращается к коллегам, выполнявшим предыдущие этапы.
По каждому из «драконов» мы заводили в Jira отдельные раздел, куда заносили относящиеся к этому дракону user story. Как только они все закрывались, дракон считался побеждённым.
Одним из самых вредных драконов в нашем случае оказались контракты с фиксированной суммой, которые мы заключали с подрядчиками. Неизменность общей суммы контракта подразумевала, что в какой-то момент поставки любых изменений в production могли быть просто заморожены. То есть все расценки были прописаны когда-то давно, а раз вы собрались внедрять какой-то там Agile, то хороший конечный результат никто не гарантирует, потому что объём работ может увеличиться, а сумма контракта — нет. Этого дракона мы и прибили в первую очередь: изменили принцип работы с подрядчиками, и начали покупать не конечный продукт или услугу, а ресурсы команд разработчиков, то есть перешли со всеми на итеративную разработку.
Второй дракон, за которого мы взялись — отсутствие процесса разработки GitFlow. Agile подразумевает постоянные итеративные изменения, а у нас вместо нормального GitFlow был огромный, неповоротливый трёх-пятимесячный релиз, и потом сразу в production. Не было ни end-to-end тестирования, ни модульного тестирования, даже не было унифицированных тестовых данных. Всё прогонялось вручную, поэтому этап тестирования тянулся непозволительно долго. Сразу три дракона!
Начался трудный этап ломки привычного «водопада». Провели обучение по GitFlow, внедрили оптимальные для текущей схемы релизов правила ведения веток, а затем перевели на новый процесс разработчиков и службу поддержки. В результате сегодня у нас несколько разных команд ведут несколько веток разработки, создают фичи, и в основную ветку мы вливаем только ту функциональность, что нужна в данный момент. Здесь мы попутно прибили ещё пару драконов: внедрили процедуру автотестирования, подготовили тестовые данные для регрессионных автотестов, начали применять модульное тестирование. Так что вместо огромных трёхмесячных релизов мы теперь можем хоть каждый день отправлять функциональность в созданную в production мастер-ветку, прогоняя код через автотестирование. Правда, нельзя сказать, что проблема с автотестированием решена полностью, ведь здесь есть такой критерий, как степень покрытия. Но мы стремимся к совершенству.
Пришлось сразиться с драконом под названием «технический долг». Пожалуй, победа над ним далась нам труднее всего. До этого мы вообще не понимали, что это за долг и как с ним работать. Раньше люди думали, что можно накосячить, а потом поддержка когда-нибудь исправит. Теперь нет, извини, ты должен нести за свой код ответственность. Пришлось определить правила работы с техническим долгом, разработать чек-лист для рецензирования кода, отладить процессы работы с бэклогом технического долга и рецензирования кода в командах.
Среди поголовья драконов затесалось и неумение делиться знаниями и навыками с коллегами. Кто-то что-то сделал — и побежал дальше. Мало внимания уделялось созданию подробной документации, да хотя бы просто передаче сакральных знаний «из уст в уста». Для борьбы с этим драконом мы внедрили процессы обмена опытом между специалистами внутри подразделений, наладили в Agile-команде процесс еженедельного рецензирования кода, запустили регулярные мероприятия по комплексному обучению и развитию специалистов.
А вот драконов «прозрачность» и “CI/CD” мы до сих пор никак не победим. Хотя ситуация гораздо лучше, чем два года назад, победа близка.
Что подразумевается под прозрачностью? Например, владелец продукта получает задание от заказчика и приносит команде. Обратно от команды он приносит заказчику сроки, понимание, реализацию. Этакое передаточное звено в отсутствие проектного менеджера. И до сих пор заказчики плохо понимают, как управлять, скажем, сроками.
При этом команда раньше не всегда понимала бизнес-ценности продукта, чего хотят добиться заказчики. Исполнители и заказчики почти не общались. При этом у заказчиков от сроков зависят KPI, успешность достижения каких-то цели, а исполнители совершенно не понимали ценность и роль поставляемого ими кода в проекте. Особенно если команд несколько, и они работают параллельно. Мы пытаемся победить этого дракона с помощью всевозможных синхронизационных мероприятий, почаще устраиваем встречи между исполнителями и заказчиками. Это помогает мотивировать команды, но дракон ещё дышит. А всё вместе это называется «Обеспечение прозрачности как сверху, так и снизу».
Что касается CI/CD, то мы настроили уведомления о любых проблемах при тестировании, ввели категории релизов и для каждой из них разработали чек-листы, реализовали возможность развернуть любую ветку кода в любом окружении, полностью автоматизировали выкатывание в production.
А что с Agile?
С ним всё прекрасно, он работает, и сейчас мы масштабируем на всю компанию, взяв за основу SAFe. У нас уже появляются кросс-продуктовые команды, что намного повышает сложность, и в том числе из-за этого возникают новые драконы, которых приходится дружно душить. У нас даже устоялось внутреннее корпоративное название для встреч, на которых обсуждаются различные трудности и способы их преодоления — «убивать драконов». Термин прижился и в тех командах, которые не работают по Agile. Всё, что мешает работать, начали называть драконами, подразумевая, что с ними надо бороться. Был курьёзный случай, когда один из сотрудников так и записал в своём рабочем отчёте: убивал драконов. То есть присутствовал на обсуждении текущей ситуации и дальнейших шагов. Его начальник прочитал, «хорошо, молодец», но, когда отчёт пошёл через юристов-финансистов-методологов, те пришли к начальнику и спросили, всё ли у нас в порядке, если мы в рабочее время мочим драконов.
Пришлось рассказывать о нелёгких буднях борцов с крылатыми гадами.
