Все статьи
Как Nexus и здравый смысл вытаскивают проекты
Дата: 15.03.2021
Что делать, если от вас зависит релиз, нужно сделать интеграцию с 15 системами, работы на 9 месяцев, но дедлайн через 4? История Deutsche Telekom IT Solutions: как с помощью Nexus и здравого смысла ускорить поставку, успешно сделать все интеграции и спасти безнадежный проект.
Доклад на конференции Enterprise Agile Russia 30 ноября 2020 года.
Артемий Анцупов (ведущий конференции): Андрей нам расскажет о том, как фреймворк Nexus и здравый смысл совместно позволяют нам вытаскивать проекты. Андрей в эфире, пожалуйста.
Андрей Булов: Добрый день, дамы и господа. Меня зовут Андрей Булов, я работаю в компании Deutsche Telecom IT Solutions, ранее известной как T-Systems. Я из Петербурга. Сегодня я расскажу про то, как мы придумали Nexus, не зная, что это Nexus, и вытащили практически безнадежный проект.
Собственно, давайте пару слов обо мне, кто я такой. Я работаю в DT IT. Вообще, изначально я разработчик, Java, Python, Kotlin, пишу на всем, что пишется. В 2012 году увлекся Agile, и с тех пор прошел все, что только можно, попробовал все возможные фреймворки в Agile и Scrum, и поработал Scrum-мастером и product owner, и до сих пор веду тренинги по Scrum для Scrum-мастеров, иногда для product owners и, в принципе, для всех людей. Такой некий инжиниринг-менеджер.
Сегодня я расскажу про кейс, это такой скучный кейсовый доклад, без мемасиков, на корп-шаблоне, что-то немножко общо, потому что NDA, но я думаю, вы без труда узнаете любой Enterprise. В общем-то, 85% энтерпрайза узнаваемы здесь. Пишите в комментарии, я, к сожалению, их читать не могу, но потом мы это обсудим все.
Собственно кейс. Мы получили классный новый суперский проект с нуля от одного известного очень большого зарубежного производителя. Суть системы была в том, что это была единая точка правды для всех цен на продукты этой компании. В любой точке мира на продукт в любом временном промежутке мы должны отдать цену, то есть в будущем, в прошлом и в настоящем. Под этим была кучерявая бизнес-логика, в общем, оно должно работать очень быстро, надежно и классно.
Команда у нас была четыре человека, четыре «космонавта», на нашей стороне, я был одним из них, и, соответственно, на стороне Германии были Scrum-мастер, product owner и архитектор. Ну, и РМ, куда же без РМ, так как мы все-таки работаем в Enterprise.
Мы решили использовать некий Enterprise Agile Scrum, как я это назвал, это был скрамоподобный процесс. Несмотря на то, что мы работали в комплексном домене, для любителей Cynefin Framework, мы не изобретали чего-то нового на рынок – мы должны были сделать функциональность, которую уже делали до нас, но сделать хорошо и быстро.
Мы начали это писать. Собственно, стек был довольно распространенный, Java, маленькое внутреннее облако, Angular. Но была вишенка на тортике, Enterprise, во-первых, много, очень много корпоративных стандартов. Это безопасность, это работа с персональными данными, работа с коммерческой тайной и, наконец, работа с деньгами. Если мы ошибаемся положением точки в числе, то компания попадает на большие деньги.
Самое интересное, это 15 партнерских систем, которые льют данные в нас, это всякие-разные клиенты, это курсы валют, всякое такое, то есть такой хороший, классический Enterprise BackBone. И, конечно, работать должно быстро, потому что никто не будет ждать свою цену на веб-сайте 10 минут.
Мы разрабатывали, и разрабатывали мы довольно успешно, то есть обычная, нормальная жизнь, потихонечку пилим, все довольны, все готовятся к грядущим интеграциям. Конечно, сложно, успеваем, все здорово, но у всех есть такое знакомое чувство, что скоро должно что-то случиться, потому что мы смотрим на наш бэклог, на наш план работы, и понимаем, что некоторый функционал написан слишком широко, слишком общо, и что-то должно быть.
Конечно, это происходит. К нам приходит бизнес со стороны заказчик и говорит: «Ребята, так и так, нам нужно еще сделать столько и еще пол-столько», то есть полтора бэклога сверху. В общем-то, никто не виноват, все понимают, что это произошло из-за наших коллег слева, справа по нашему хребту, так сказать, энтерпрайзному, то есть мы будем писать их функционал, но нам от этого никуда не деться. Самое интересное, что мы это должны сделать в тот же срок, и если мы не успеваем, то мы еще ждем полгода запуска всего этого хребта, это убытки, это недополученная прибыль и…
Мы просто должны это сделать.
Менеджмент говорит: «О’кей, давайте увеличим команду на 14 человек, так получается, почти в три раза, в три-четыре раза, и мы это сделаем». Мы увеличиваем команду до 18+ человек по факту. Логично, что они не могут нормально работать в Agile-like процессе, то есть Scrum тут будет работать с трудом. У нас была мысль, конечно, сразу перейти на подобие Waterfall, на подобие PMI, составить план работы и все спокойно завершить, потому что более-менее уже понятно, что делать, scope был понятен. Но мы очень сильно привыкли к таким штукам в Agile, как transparency inspection, и не могли это потерять. Мы не могли понять в самом конце, что мы на самом деле это не успели.
Поэтому мы решили использовать, как потом выяснилось, хорошую практику Nexus, как взять людей из изначальной корневой команды, четырех человек, и поделить их на три команды. Мы получили три команды, которые независимо друг от друга пишут функционал, они самоорганизующиеся, у них есть внутри эксперты и, в общем-то, мы восхитительны. Все команды льют свой функционал на интеграционный сервер, мы прекрасны, мы практически изобрели LeSS.
Если бы все так было, конечно, доклада бы не было. По факту то, что каждая из команд написала свой функционал, залила его на интеграционный сервер и выполнила свой DoD (Definition of Done. – прим.ред.) на какую-то конкретную user story, это, к сожалению, не значит, что все работает со всем.
Какие у нас возникли проблемы? Первое, оказывается, что две истории, два куска функционала иногда могут не стыковаться. Даже если они написаны одним архитектором, но либо в разное время, либо каким-то витиеватым образом, они могут не работать вместе. Они прекрасно работают по отдельности, они написаны корректно, но не интегрируются, вот так вот мимо происходит.
Частый случай был, когда к нам приходила партнерская система, говорила: «Так и так, да, у нас есть согласованный контракт, но давайте вы у себя что-нибудь поменяете, допустим, мы вам шлем теперь не timestamp, а UTS DateTime, у вас это сделать проще, нам придется все переписывать». Или, например, интеграция в моке (mock. – прим.ред.), это самое любимое. Вроде как проверили интеграцию, все здорово, но мы интегрировались в мок, и по факту мы не знаем, работает у нас система или нет. Что делать? Вроде как работает, но не работает. Что мы попробовали с этим сделать?
Во-первых, классическое решение, дополнить Definition of Done. У нас не просто сторя сделана, закачана на интеграционный сервер, она должна работать, условно, в проде, то есть быть проверена с партнерской системой, должна работать, и прекрасно, хорошо работать под нагрузкой. К сожалению, это не сработало, потому что такое расширение Definition of Done блокирует разработку, и мы теряем начисто прозрачность, или его просто никто не будет соблюдать. Наверняка, вы такое пробовали, писать Definition of Done, где много-много-много-много всяких пунктов, но их в конце никто уже не читает.
Второе, пробовали решить проблему процесса, возвращаем на доделку. К сожалению, тоже не работает, потому что если мы фиксим задачу как багу, то мы получаем задачу на от одного часа до пяти дней в середине спринта на разработчика, и либо у нас будет бардак, либо задолбанный разработчик, либо мы просто продолбаем текущей спринт, текущий функционал в нем.
Наконец, такой более процессный подход, мы пробовали создавать задачи на интеграцию и заводить их в начало цикла, но это тоже не работает, потому что это очень долго, дорого и не очень эффективно. Оно сильно затягивает интеграции и не решает локальную проблему, то есть, по сути, тот же PMI.
Мы придумали такую штуку – слушайте, а давайте мы продумаем немножко зависимости заранее, ведь можно же как-то попробовать побить эти пользовательские истории, построить зависимости и так далее. Мы подумали-подумали, и решили – да, это хорошо. Кто это будет делать? Делать это будут, конечно, люди, которые этим и так занимаются.
Вместо трех команд у нас появилась четвертая виртуальная команда, состоящая из людей, которые занимаются интеграцией, из product owner, архитектора и, конечно же, нашего любимого менеджмента. Они и так общались до этого, менеджер ходил к каждому разработчику, спрашивал, что происходит, менеджер ходил к лидам, РО к ним ходил, QA к ним ходил, то есть было такое броуновское движение. Тут мы это сделали более официально, мы сделали виртуальную команду, которая каждое утро собирается и обсуждает проблемы интеграции и то, что нам нужно решить в течение дня. Все это началось с такого чудесного предложения.
Мы это назвали Leadership Team. Про то, что это NIT, мы узнали потом, и про то, что мы собирались на NIT Daily, мы тоже узнали сильно потом.
Что у нас из этого получилось? Получилось так, что мы изобрели Dependency Board. Мы взяли наши истории, мы поставили зависимость друг от друга, нарисовали зависимость от внешних систем, и начали это все делать на product backlog refinement с помощью этой самой команды. Там мы распиливали все предварительно между командами. Команды у нас были не полностью кроссфункциональные, это были больше такие ребята, специализирующиеся на конкретных модулях, то есть полу-модульные команды. Мы разделяли истории между ними, делали зависимости, и отдавали в команды, а потом они уже били их между собой и делали конкретные задачи, конкретные таски. Грубо говоря, для команд не поменялось практически ничего. Внутри разработчики как спокойно себе работали, так и работали, просто у них стало меньше головной боли, не нужно теперь было бегать в середине спринта, разбираться, что же происходит.
Помогло ли нам это? Да, помогло. Почти. Когда вы продумываете зависимости заранее, вы фиксите это все в процессе спринта, это работает, вы выкатываете вместе с интегрированной историей на интеграционный сервер. Но когда к вам приходит реальная нагрузка, реальные данные, либо приходят затейники в виде PO и end user, которые говорят: «О, а как же вот этот кейс, который мы не описали в истории, но он очень важен? Слушайте, мы про него забыли, если бы не посмотрел, я бы это не вспомнил». Либо ребята, которые нам присылают тестовый JSON-интерфейс, например, размером 1 мегабайт, и говорят: «Вот это мы будем слать» и вы отлаживаетесь на нем, а на реальном сервере к вам приходит 10 гигабайт, это реальный кейс. Вы думаете – ну, круто. Собственно, это можно было узнать только постфактум. Несмотря на решение части проблем в начале, мы все равно огребали в конце.
Что же делать? У нас наша структура стала выглядеть вот так, то есть у нас команда, наша Leadership-команда, которая занималась этим предварительным планированием, команда, которая занималась интеграцией, теперь стала выглядеть вот так. У нас NIT-команда, Leadership-команда стала заниматься и предварительным распилом историй, и решением проблем в самом спринте, то есть они бегали между разработчиками, разработчики бегали к ним. Наконец, они взяли на себя кусок работы, за который, по идее, команды отвечать были не должны, то есть это какая-то тонкая конечная интеграция, это связаться с какой-то партнерской системой во вторник вечером, попробовать нагрузку, это посидеть вместе в debug и так далее. Но выгружать это в команды смысла не было. С таким чудесным паттерном, когда у нас команда спокойно себе работает в агилизированном процессе, практически в Scrum, есть команда, состоящая из всех участников, которые участвуют в интеграции, помогает на каждом этапе всем командам вместе сынтегрироваться.
По большому счету, у нас получилось примерно такая картинка, как мы потом узнали, очень похоже было. Да и, собственно, все, мы сделали этот проект, мы установили такой процесс, и он у нас заработал. С помощью него мы вытащили этот проект, мы сдались вовремя, мы вышли в прод, мы были молодцы, это дело отпраздновали. Потом мы начали думать, почему у нас сработало. Что мы нарефлексировали?
Первое. Во-первых, появилась сущность, куда могут прийти люди и сообщить о нестыковке или блокере. Так разработчик должен бежать либо к соседу, либо к product owner, либо, не дай Бог, вообще куда-нибудь в Enterprise, к бизнесу, находить каких-то совершенно безумных людей, которые этим занимаются. Естественно, обычный middle или не очень опытный разработчик это делать либо не будет, либо его один раз проигнорируют, он забьет на это. Во-вторых, не всегда в команде понятно, что эта задача реально важна. Поэтому появилась эта команда, в которую все ходят и говорят: «Блокер, проблема, ахтунг, помогите».
Второе. Человеческая проблема общения, когда возникают зависимости, разработчик Василий идет к разработчику Петру, говорит: «Слушай, сделай это, пожалуйста». Петр говорит: «О’кей, сделаю, но потом, у меня сейчас свои задачи». Если Василий будет ходить к Петру в режиме дятла каждый день каждые десять минут, естественно, они разругаются, кто-то кого-то рано или поздно пошлет. Если есть специальная команда, которая решает приоритеты, и скажет Петру: «Слушай, забей на свои задачи, делай задачу Василия», все будет хорошо.
Наконец, в NIT у нас были менеджеры, это не по канонам, может быть, самого истинного Nexus, но это нам очень сильно помогло, потому что менеджмент видит наш прогресс, они смотрят, что мы стараемся, они видят наши проблемы, смотрят наши обсуждения и проникаются этой болью, и помогают нам гораздо лучше, чем если бы мы им докладывали просто какой-то статус как команды, либо они ходили бы к девелоперам.
Наконец, с точки зрения техники, на полностью проде всплывает гораздо больше, чем на простой интеграции, даже если вот оно всё заранее подготовлено.
Дальше была рефлексия. Собственно, мы начали этот процесс, мы подумали, что мы изобрели что-то крутое, мы начали его обкатывать на других процессах в командах. Собственно, какие же выводы все это показало?
Во-первых, Nexus и подобный процесс отлично себя показывает в комплексном домене. Там, где вам нужно сделать что-то, что вы уже сделали на большом масштабе, отлично заходит. Отлично работает на молодых командах, то есть когда команда ваша не сбита, она не втянулась еще в Scrum-процесс, она низкого уровня, но вам надо работать в масштабированном Agile. Понятно, что LeSS у вас там не зайдет, потому что команда слишком молода, но Nexus зайдет прекрасно, потому что вроде как есть Scrum и есть какой-то орган, который… там сидят вроде наши ребята, которые могут помочь.
Пробовали несколько раз в кризисе, работает. Самое главное, не требует орг-изменений после выхода из кризиса, просто становится спокойнее, просто из NIT могут уйти некоторые люди, и оно будет работать дальше.
Nexus можно внедрить, как мы это сделали, не говоря, что это Nexus, не зная, что это Nexus, и это можно внедрить и обосновать вообще без объяснения того, что вы делаете.
Наконец, для фанатов Meta-Scrum/Emergent, по-моему, они очень прекрасно вместе работают, мы это попробовали, оно завелось, всем советуем.
Немножко фантазий на тему, что если бы мы тогда придумали не свой нексусообразный процесс, а что-то другое. SAFe – очень тяжело. Наверное, взлетело бы, но запускать SAFe на три команды в условиях довольно жесткого давления сроков – это как ездить, простите, на карьерном экскаваторе километр в магазин: долго, дорого и тяжело.
Waterfall, Command and Control будет работать по определению медленнее. Почему-то если у людей есть сверху менеджер, который решает, и архитектор, который думает, у них немножко выключается голова, и мы получаем кучу бутылочных горлышек в виде этих людей, и оно перестает работать.
Наконец, Kanban. Kanban работает, в принципе, отлично со всем. Если бы мы использовали вместо этого процесса Kanban, нам бы не хватило вот этого чудесного ингредиента NIT или Leadership Team, без которого, в общем-то, этот успех был бы, наверное, невозможен.
В общем-то, с тех пор мы, я лично часто использую эти элементы, часто использую этот процесс и, в общем-то, всем советую этот крайне недооцененный фреймворк, который прекрасно работает в Enterprise, вне Enterprise, и вообще работает. Спасибо.
Вопрос-ответ
Артемий Анцупов (ведущий конференции): Спасибо огромное Андрею. Поступили вопросы. Спасибо, во-первых, вам огромное за выступление, спасибо огромное личное, персонально от меня, потому что я работал с фреймворком Nexus, мне он тоже понравился. Его недостаток, скажем так, в информационном поле меня тоже немножко удручает. Спасибо огромное.
Расскажи, пожалуйста, а вот сейчас сколько у вас команд, сколько вас человек живет по этому фреймворку, сколько проектов, может быть, или продуктов.
Андрей Булов: Сейчас в этом, подобном процессе живет как минимум четыре команды из тех, что я знаю, там, где я, так или иначе, принимал участие в этом, а остальные просто об этом, может быть, не знают, они используют какие-то элементы этого Nexus. Как минимум на 60 человек это работает.
Артемий Анцупов: Как минимум 60 человек, нифига себе. Слушайте, очень здорово. Скажи мне, пожалуйста, такой вопрос, ты уже ответил на еще один вопрос, да, почему не SAFe, почему не Command and Control. Ты, я помню, упоминал об этом, но все-таки поясни, пожалуйста, еще раз, а почему же не LeSS, почему у вас… Все-таки, когда такая ситуация возникает, первая мысль у многих – это именно «а давайте мы построим LeSS». С чем это было связано, какие были препятствия? Ты в what if про LeSS как-то не упомянул, можешь, пожалуйста, немножко про это рассказать?
Андрей Булов: What if про LeSS. LeSS – это очень классный фреймворк, который дает безусловные преимущества для опытных, матерых, хороших, сбитых команд. Но если у вас кризис, если у вас команды очень молодые, не сбитые либо неопытные, что часто бывает в Enterprise, мы не набираем команду «космонавтов», получается, что у вас просто он не взлетит как LeSS, не взлетит эта философия LeSS. Плюс это очень требовательно ко времени. Поэтому Nexus – это хорошее решение. Если бы у нас было больше времени, может быть, мы бы использовали LeSS, да.
Артемий Анцупов: Неопытные, ты имеешь в виду в плане инженерных практик каких-то, или в рамках самоорганизации именно?
Андрей Булов: В рамках самоорганизации, может быть, даже инженерных практик. В LeSS мы привыкли к фича-командам, мы говорим, что у нас фича-команды, которые делают все. Nexus прекрасно работает с модульными или полу-модульными командами. В некоторых случаях такой микс в Enterprise просто необходим, когда вы пишете какое-то сложное ядро.
Артемий Анцупов: Да, то же про SAFe когда говорят, да.
Андрей Булов: Да, все верно.
Артемий Анцупов: А у вас было так же, что у вас были команды полу-модульные, полу-компонентные, или у вас feature teams все-таки?
Андрей Булов: Да, были полу-модульные, полу-фича-тимы, то есть одна команда была более-менее универсальна, остальные были более специализированы.
Артемий Анцупов: Замечательно, спасибо огромное. Меня очень заинтриговал твой вопрос, внедрение без внедрения, запуск без запуска. А можешь рассказать буквально в двух словах для наших слушателей, как у вас это происходило? Может быть, кто-то захочет попробовать это после того, как услышит, насколько у вас это получилось легко и просто, или не легко и просто. Расскажи.
Андрей Булов: Все довольно прозаично. Первый этап, нужно сделать некое подобие NIT, которое вы можете назвать как угодно. Вы говорите: «Ребята, проблемы с коммуникацией, давайте общаться вместе. Но давайте это делать без девелоперов, которым это не всегда интересно, давайте это будут ключевые люди. Мы это будем делать каждый день, обсуждать наш статус». Все, вы сделали NIT.
Дальше у вас получается автоматический двухступенчатый Daily, потом у вас получается автоматически ретроспектива и, так или иначе, вы придете к двухступенчатому планированию, потому что у вас команда будет определять зависимости, если они у вас есть. Вот, вуаля, вы получили Nexus, хотите вы того или нет.
Артемий Анцупов: Действительно здорово, то есть вы просто начали с того, что вы собрали представителей, тех, кто владеет ключевой информацией, и стали ими просто ежедневно общаться на, по сути, дополнительном Daily.
Андрей Булов: Да.
Артемий Анцупов: Потрясающе. Скажи, пожалуйста, а вы использовали ли что-то вроде, я помню, что мы в Nexus когда работали, мы использовали доски зависимостей, Dependency Boards, не прямо такие, как в SAFe, конечно, более простые. Пользовались ли вы чем-то таким, какими-то визуализациями, какими-то, может быть, артефактами, которые поддерживали эту вашу кросскомандную коммуникацию?
Андрей Булов: Да, безусловно. У нас была своя самодельная доска в Jira и, конечно, Excel, без него никуда. Мы делали, но не визуализировали это в офлайне, к сожалению, к этому мы пришли сильно позже.
Артемий Анцупов: Все. Супер. Спасибо тебе огромное.
