[ERP-системы, Agile] Как мы замиксовали Agile для внедрения новой ERP-платформы
Автор
Сообщение
news_bot ®
Стаж: 6 лет 8 месяцев
Сообщений: 27286
Привет, Хабр! Мы – Антон Кузнецов и Ксения Краснова, Agile coach и руководитель Программы проектов в компании «Северсталь». Расскажем, как мы применили гибкие подходы для внедрения новой ERP-системы S/4HANAНачнем сначала: что значит ERP для «Северстали»?ERP – большая и сложная система, в которой учитываются производственные операции, ресурсы, финансы и активы компании. Она позволяет автоматизировать работу большого предприятия и сделать любой процесс (от документооборота до продажи нескольких сотен тонн металла) проще, быстрее и удобнее.
В «Северстали» ERP – это «сердце» компании. В ней работают 20 тысяч пользователей, и без ERPтрудно представить работу такой огромной металлургической корпорации. «Северсталь» – это не просто заводы, рабочие и тяжелый физический труд. Мы повышаем эффективность работы за счет цифровых технологий, активно применяем Data Science, роботизируем и цифровизируем процессы. «Северсталь» уже давно не просто металлургическая, а цифровая компания. И вот, мы плавно подошли к следующему вопросу:Зачем мы вообще начали менять текущую ERP на S/4HANA?Компания динамично развивается и использует новые технологии. И понятно, зачем: это позволит автоматизировать все, что можно автоматизировать, сократить влияние человеческого фактора, увеличить скорость работы производства и, как следствие, повысить удовлетворенность клиентов, а вслед за ней и прибыль. 
Причина №1: Сейчас компания использует систему SAP ECC 6.0. Развитие этой системы уже остановлено, а поддержка SAP ECC будет полностью прекращена с 2027 года. Тогда почему мы поставили себе срок перехода на S/4HANA в 2021 году, а не ближе к 2027? Чем раньше – тем лучше не только из-за того, что к 2027 мы точно успеем отладить и стабилизировать систему, но и потому что специалисты S/4HANA находятся в дефиците. Чем больше затягивается переход, тем ожесточеннее борьба за кадры. К тому же, другие системы, стоящие вокруг ERP, уже развиваются на базе S/4HANA. Оставаться и дальше на ECC 6.0 – значит постоянно тратить время на костыли и интеграцию. Еще один важный момент, связанный с текущей системой: доработки, которые нужны для реализации новой бизнес-стратегии «Северстали», скорее всего, сломают действующую систему или, как минимум, сильно её замедлят.Причина №2: «Быстрее! Выше! Сильнее!» – это про «Северсталь». Мы хотим снизить количество кастомного (нестандартного) кода и улучшить time-to-market (время от начала разработки до внедрения продукта). К 2022 году мы планируем снизить time-to-market в 2-3 раза по отношению к 2019-му. По этим причинам в 2019 году мы начали работу над проектом по замене текущей системы на систему SAP S/4HANA. Внедрение S/4HANA – это не просто внедрение новой ИТ-системы. Это глобальное изменение важных процессов компании. Если вспомнить о том, что ERP – это сердце компании, речь идёт ни много ни мало о трансплантации сердца на ходу.Почему нам не подходит Waterfall? Ощутили всю серьезность ситуации и степень ответственности? Представили масштабы проекта? А теперь, еще пара вводных для полной картины:1. Изменения в процессах и структуре компании непрерывные и динамичные;2. Платформа монолитная: меняя что-то в одном месте, легко можно сломать что-нибудь в другом;3. Развитие текущей ERP нельзя останавливать (мы заморозим работу всей компании), но при этом необходимо переосмыслить множество процессов и «с нуля» создать новую систему. Обычно, когда говоришь о модернизации такого большого и глубоко интегрированного механизма, то представляешь процесс в виде Waterfall: прежде чем начать разработку, надо всё спроектировать, учесть все зависимости, попытаться предусмотреть риски и написать документ, который по объему будет не меньше, чем «Война и мир». 
В общем, фаза анализа по составлению документации и требований в классическом подходе на наших объемах заняла бы 6-8 месяцев. Пока бы мы тратили столько времени на составление плана и детализацию ожиданий от S/4HANA, все процессы компании, которая динамично развивается, могли измениться. В конечном итоге, наш поезд никуда бы не поехал, так как направление общего движения за это время изменилось, рельсы нужно перекладывать. Получается замкнутый круг: мы работаем и выпускаем документацию, к этому моменту она устаревает, мы пишем новую, и так до бесконечности. Перед нами встала задача: как сделать так, чтобы ничего не потерять и выпустить продукт, который удовлетворит конечного пользователя, и при этом учесть постоянное развитие и изменения в процессах? Посмотрели чужой опыт, запросили у консультантов методики и варианты, но так и не нашли ответа на вопрос, чье кунг-фу сильнее. Поэтому решили из всего многообразия известных подходов выбрать только то, что подходит именно нам. За основу взяли SAFe, немного Nexus, ну и как же без любимого SCRUM.Как мы в итоге выстроили работу проекта?Следует упомянуть, что проект состоит из трех фаз: 1. Концептуальное проектирование;2. Разработка и тестирование;3. Внедрение и завершение работ.Сейчас мы только перешли к третьей фазе, а в рамках этой статьи подробнее поговорим именно про фазу «Разработка и тестирование». Концептуальное проектирование осуществлялось по классической модели Waterfall, так как дизайн методологии разрабатывался в рамках этой фазы. А вот разработку и тестирование мы полностью проходили уже с использованием нашего Agile-mix.Ключевая идея такая: разработка и тестирование разбиваются на инкрементные циклы продолжительностью три месяца. Каждый инкремент состоит из четырех трёхнедельных спринтов. Три из них отведены непосредственно на разработку и тестирование. Четвертый спринт направлен на то, чтобы выпустить общий для всех команд результат по проекту и подготовиться к следующему инкременту. В конце каждого инкремента полученные результаты проделанной работы мы демонстрируем заказчикам проекта – владельцам сквозных процессов. Еще не запутались? Ниже на схеме отражены все фазы.
Фазы проекта внедрения S/4HANA А сейчас давайте глубже окунемся во все тонкости организации нашей внутрикомандной работы.Команды: разделять и особо не властвоватьПринцип формирования и структура команд проекта S/4HANA строится следующим образом: · 10 команд функционального внедрения, где каждая команда отвечает за определенное функциональное направление (например, ремонты, продажи и т.д.);· 3 платформенные: команда миграции данных, команда интеграции со смежными системами и команда сопровождающих сервисов. Все они автономны с точки зрения ресурсов и компетенций и выстроены таким образом, чтобы поставлять функциональный объем направления от начала и до конца (end-to-end). Немного о принципе формирования функциональных команд: мы опирались не только на модули системы, но и на организационную структуру предприятия. Таким образом, функциональные команды сформированы исходя из бизнес-процессов компании. Мы не придумывали экзотических ролейВладелец продукта отвечает за формирование видения и управление бэклогом. Он направляет команду, сверяется с потребностями бизнеса и выравнивается с другими владельцами продукта. Очевидно, что такой человек должен быть гуру в своем функциональном направлении. Функциональный архитектор занимается постановкой технической задачи. Он определяет, как требование должно работать в системе и как разрабатываемая функциональность влияет на смежные команды. Архитектор разработки отвечает за разработку. Он бережет чистоту кода и прозрачность архитектуры, а реализацией требований занимаются, естественно, разработчики.В командах есть тест-менеджер, который отвечает за проверку качества разрабатываемых решений, а также за подготовку материалов и контроль автоматизации тестирования. Scrum-мастер заботится о следовании методологии и атмосфере в команде. В командах нет выделенного скрам-мастера, и кто-то обычно совмещает эту роль с другой (например, с ролью функционального архитектора).Чем мы руководствовались, когда формировали команды? Здесь работают три основных принципа: ставка на внутренние компетенции, самоформирование и функциональное подчинение.Ставка на внутренние компетенцииМы приняли принципиальное решение максимально подключать к проекту внутренних сотрудников, а не приглашенных экспертов. Они не только лучше знают «внутреннюю кухню» компании, но среди них есть те, кто участвовал в прошлом внедрении системы. Эти люди уже «нюхнули пороха» с предыдущим внедрением ERP и, преисполненные опытом, могут спрогнозировать ошибки. Еще нам важно, чтобы все компетенции и знания, полученные в ходе реализации проекта, оставались и в дальнейшем внутри компании. СамоформированиеКаждая команда сама решает, каких людей им не хватает, и может самостоятельно подбирать и нанимать к себе сотрудников. Это помогает избегать длительных процедур поиска и согласования кандидатов и, в то же время подбирать в команду тех людей, которые подходят и по духу, и по компетенциям. Функциональное подчинениеВсех ключевых участников мы вывели из подразделений и полностью переключили на наш проект, чтобы их не отвлекали на другие задачи. Так все могут полностью сфокусироваться на целях и задачах проекта. При этом мы не пересаживали членов команды из своих отделов. Таким образом, не потребовалось переделывать организационную структуру сейчас и не потребуется после завершения проекта: все сотрудники вернутся к своим обычным задачам, но уже будут иметь навыки и компетенции в работе с новой системой S/4HANA. Церемонии, ритуалы и немного магииКаждая команда проводит регулярные встречи или, как принято говорить в среде Agile, — церемонии. На них команды упорядочивают бэклог, планируют следующие спринты и инкременты, выравниваются относительно планов и определяют блокираторы, которые стоят на пути к достижению цели. Внутрикомандные мероприятия — это то, чему мы уделили особое внимание. Перед стартом фазы «Разработка и тестирование» мы провели серию установочных тренингов, где рассказывали командам, как и зачем проводить церемонии. Далее команда методологов помогала командам настроить внутренние процессы, в том числе ключевые Scrum-встречи. Мы заранее предупредили команды, что этот подход не высечен в камне, и впереди нас ждет первый «тренировочный» инкремент. Если команды посчитают, что им что-то не подходит, то мы сможем поменять процессы. Нельзя сказать, что новую методологию все приняли с восторгом. Кому-то она оказалась близка, и они с готовностью включились. Кто-то не понимал эти мероприятия, и для него всё казалось напрасной тратой времени. Мы продолжали работать над осознанностью...Но после первого же инкремента мы получили ответ от команд: «Давайте так работать дальше!» Многие отмечали, что прозрачность процессов увеличилась, скорость выполнения задач возросла, участники стали сближаться и становиться настоящей командой. Важная часть нашей Agile-трансформации – регулярные встречи scrum-мастеров (scrum-of-scrums), на которых мы обсуждаем разные вопросы по улучшению процесса кросс-командного взаимодействия, не обязательно напрямую связанные с методологией. Например, почему бы не назначить один день в неделю, свободный от встреч на уровне программы (чтобы решить текущие задачи команды)? Так что по ходу развития проекта менялись и правила игры. Любые изменения в процессах и нововведениях обязательно сопровождаются коммуникацией на всех участников проекта. Текущее состояние наших правил мы фиксируем в Confluence.В течение проекта мы постепенно добавляли все новые и новые практики. Например, для scrum-мастеров мы организовали agile-интервизии. Они помогают разобраться в проблемах, возникающих в командах. Каждый скрам-мастер формирует кейс и выносит его на общее обсуждение. Также scrum-мастер может обратиться к agile-коучу, вместе с ним разобрать проблему в команде и найти решение в формате супервизии. Если говорить про систему регулярных встреч на уровне всего проекта, то она выглядит так:● стендапы, на которых каждая команда ежедневно выравнивается относительно своих планов;● ежедневный утренний NIT (Nexus Integration Team), где мы обсуждаем технические решения на уровне архитекторов команд, а также риски и блокираторы;● синхронизация владельцев продуктов (PO Synс), где владельцы продуктов сверяют свои задачи и сроки их реализации;● встреча scrum-мастеров (scrum-of-scrums), где scrum-мастера обсуждают текущие проблемы кросс-командного взаимодействия и синхронизируют подходы;● демонстрация результатов спринта (demo), где команды демонстрируют реализованные за спринт задачи;● ретроспектива, которая проводится как для всего проекта, так и для каждой команды в отдельности. На них обсуждают, что необходимо сделать, чтобы в дальнейшем быть более эффективными. Ретроспективы проводятся после каждого спринта и, отдельно, после каждого инкремента;● регулярные встречи по планированию спринта, на них команды определяют список задач для выполнения в начале каждого спринта;● кросс-командное выравнивание по планированию спринта, где представители команд рассказывают, как прошло командное планирование и возникли ли какие-либо сложности;● кросс-командное выравнивание по результатам спринта, задачей которого является обсуждение реализации целей спринта и прогресса по выполнению целей инкремента. Своего рода некое «ревью» по итогам трехнедельной итерации;● презентация интеграционного сценария, которая происходит в последнем спринте, в рамках которого мы интегрируем разработанные решения;● планирование инкремента (PI Planning), которое также происходит после последнего, четвертого спринта, и на котором мы в течение двух дней планируем задачи на следующий инкремент. Жизнь вносит свои коррективы Отдельным вызовом для нас (как и для многих других) стал карантин, который случился на старте проекта. Мы успели арендовать новый офис, чтобы все могли беспрепятственно общаться в духе Agile, провести первое PI-планирование, запустить первый инкремент. А дальше пришлось перестраиваться.Внутрикомандные церемонии легко переехали в online, потому что некоторые участники изначально работали удаленно. А вот с масштабными мероприятиями, вроде PI Planning, оказалось сложнее. И мы взяли таймаут длиной в спринт (коллеги занимались техническим долгом и прочими полезными вещами), чтобы придумать, как обеспечить эффективную работу в online для нескольких сотен человек. В итоге мы разработали план действий с применением online-инструментов, с помощью которых успешно запланировали и завершили еще 5 инкрементов. Так из чего же состоит наше PI-планирование?В классическом планировании все задачи и зависимости между командами фиксируют на доске со стикерами и нитками. Мы заменили ее на цифровую доску Jira. Так мы видим планы с разбивкой по спринтам как в разрезе одной команды, так и всей программы в целом, с учетом межкомандных зависимостей. Зависимости – это взаимосвязанные между собой задачи, в которых одна задача не может быть выполнена, если не выполнена другая. 
Задачи и их зависимостиВсе зависимости имеют цветовую индикацию. Красная линия связи – повод поменять планы: выход задачи заблокирован другой задачей, которая планируется к выходу позже. Чаще всего диаграмма пестрит желтыми линиями — они означают, что зависимые задачи завершаются в одном спринте. По таким задачам надо постоянно синхронизироваться, чтобы убедиться, что в планах зависимых команд ничего не поменялось. Зеленая линия говорит о том, что блокирующая задача выполняется раньше заблокированной.Также в рамках планирования мы учитываем все риски и блокираторы, которые могут нам помешать успешно завершить инкремент. Риски и блокираторы программы учитываем в Excel-таблице — и тоже выводим на доску при планировании, а затем в течение всего инкремента мониторим на NIT:
Наши рискиЕще во время планирования мы сразу обсуждаем сценарий интеграционного тестирования, чтобы убедиться, что вся функциональность, участвующая в сценарии, запланирована в инкремент. 
План будущего тестированияПомимо Jira в процессе всего планирования мы используем и другие инструменты: · общение – Microsoft Teams;· проведение опросов – Mentimeter; · оценка задач – Voting Poker.И теперь, даже после частичного снятия ограничений, мы все равно проводим PI Planning в online-формате.Подведем итогиС помощью всех вышеперечисленных инструментов и методологии, которую мы обсудили в статье, мы успешно прошли всю фазу «Разработка и тестирование». Выработанный нами Agile-mix позволил качественно следить за выполнением бэклога, оперативно реагировать на изменения и управлять командой численностью более 1900 человек, в распределенном режиме. К тому же, сейчас все встречи и взаимодействия в проекте проходят на 100% в онлайне: мы проверили на себе, что для эффективного выполнения задач не обязательно работать очно, и повысили продуктивность работы на 60% в удаленном формате. На наш взгляд, всё получилось, потому что мы сфокусировались на вовлечении людей в изменения, создании среды для обучения и работе над осознанностью. И, конечно, ввели единые для всех правила игры.Сейчас мы разработали свою методологию с использованием Agile-практик и для финальной фазы проекта: «Внедрение и завершение работ». После того, как мы попробовали работать по этой методологии, уже не хочется возвращаться к более традиционным практикам. Хабравчане, а у вас был опыт применения Agile на больших проектах? Поделитесь своим мнением и историями в комментариях!
===========
Источник:
habr.com
===========
Похожие новости:
- [Программирование, ERP-системы, Управление проектами, Карьера в IT-индустрии, Читальный зал] Надували, надуваем и будем надувать. Пузыри программистов
- [Анализ и проектирование систем, Agile] Краеугольный камень анализа. Часть 1
- [Администрирование баз данных] SAP HANA. Таблицы с типом хранения Row
- [Управление разработкой, Agile, Управление персоналом, Карьера в IT-индустрии] TechLead — уходи
- [Анализ и проектирование систем, ERP-системы, Big Data, Хранилища данных, Финансы в IT] Как упростить доработки и поддержку хранилища данных?
- [Администрирование баз данных] SAP HANA. Операция Delta Merge
- [Высокая производительность, Управление разработкой, Agile, IT-компании] Как масштабировать разработку при 400 000 RPM и не надорваться
- [Мессенджеры, Oracle, API, Голосовые интерфейсы] Как можно запустить MVP личного кабинета в WhatsApp и получить новый инструмент для проверки гипотез
- [Программирование, Управление проектами] Если у вас нашли SCRUM
- [Управление разработкой, Голосовые интерфейсы] Навык для Алисы «Проведи стендап»
Теги для поиска: #_erpsistemy (ERP-системы), #_agile, #_agile, #_hana, #_sap, #_scrum, #_safe, #_gibkie_metodologii (гибкие методологии), #_blog_kompanii_severstal (
Блог компании Северсталь
), #_erpsistemy (
ERP-системы
), #_agile
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 01-Ноя 11:38
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 8 месяцев |
|
|
Привет, Хабр! Мы – Антон Кузнецов и Ксения Краснова, Agile coach и руководитель Программы проектов в компании «Северсталь». Расскажем, как мы применили гибкие подходы для внедрения новой ERP-системы S/4HANAНачнем сначала: что значит ERP для «Северстали»?ERP – большая и сложная система, в которой учитываются производственные операции, ресурсы, финансы и активы компании. Она позволяет автоматизировать работу большого предприятия и сделать любой процесс (от документооборота до продажи нескольких сотен тонн металла) проще, быстрее и удобнее.  В «Северстали» ERP – это «сердце» компании. В ней работают 20 тысяч пользователей, и без ERPтрудно представить работу такой огромной металлургической корпорации. «Северсталь» – это не просто заводы, рабочие и тяжелый физический труд. Мы повышаем эффективность работы за счет цифровых технологий, активно применяем Data Science, роботизируем и цифровизируем процессы. «Северсталь» уже давно не просто металлургическая, а цифровая компания. И вот, мы плавно подошли к следующему вопросу:Зачем мы вообще начали менять текущую ERP на S/4HANA?Компания динамично развивается и использует новые технологии. И понятно, зачем: это позволит автоматизировать все, что можно автоматизировать, сократить влияние человеческого фактора, увеличить скорость работы производства и, как следствие, повысить удовлетворенность клиентов, а вслед за ней и прибыль.  Причина №1: Сейчас компания использует систему SAP ECC 6.0. Развитие этой системы уже остановлено, а поддержка SAP ECC будет полностью прекращена с 2027 года. Тогда почему мы поставили себе срок перехода на S/4HANA в 2021 году, а не ближе к 2027? Чем раньше – тем лучше не только из-за того, что к 2027 мы точно успеем отладить и стабилизировать систему, но и потому что специалисты S/4HANA находятся в дефиците. Чем больше затягивается переход, тем ожесточеннее борьба за кадры. К тому же, другие системы, стоящие вокруг ERP, уже развиваются на базе S/4HANA. Оставаться и дальше на ECC 6.0 – значит постоянно тратить время на костыли и интеграцию. Еще один важный момент, связанный с текущей системой: доработки, которые нужны для реализации новой бизнес-стратегии «Северстали», скорее всего, сломают действующую систему или, как минимум, сильно её замедлят.Причина №2: «Быстрее! Выше! Сильнее!» – это про «Северсталь». Мы хотим снизить количество кастомного (нестандартного) кода и улучшить time-to-market (время от начала разработки до внедрения продукта). К 2022 году мы планируем снизить time-to-market в 2-3 раза по отношению к 2019-му. По этим причинам в 2019 году мы начали работу над проектом по замене текущей системы на систему SAP S/4HANA. Внедрение S/4HANA – это не просто внедрение новой ИТ-системы. Это глобальное изменение важных процессов компании. Если вспомнить о том, что ERP – это сердце компании, речь идёт ни много ни мало о трансплантации сердца на ходу.Почему нам не подходит Waterfall? Ощутили всю серьезность ситуации и степень ответственности? Представили масштабы проекта? А теперь, еще пара вводных для полной картины:1. Изменения в процессах и структуре компании непрерывные и динамичные;2. Платформа монолитная: меняя что-то в одном месте, легко можно сломать что-нибудь в другом;3. Развитие текущей ERP нельзя останавливать (мы заморозим работу всей компании), но при этом необходимо переосмыслить множество процессов и «с нуля» создать новую систему. Обычно, когда говоришь о модернизации такого большого и глубоко интегрированного механизма, то представляешь процесс в виде Waterfall: прежде чем начать разработку, надо всё спроектировать, учесть все зависимости, попытаться предусмотреть риски и написать документ, который по объему будет не меньше, чем «Война и мир».  В общем, фаза анализа по составлению документации и требований в классическом подходе на наших объемах заняла бы 6-8 месяцев. Пока бы мы тратили столько времени на составление плана и детализацию ожиданий от S/4HANA, все процессы компании, которая динамично развивается, могли измениться. В конечном итоге, наш поезд никуда бы не поехал, так как направление общего движения за это время изменилось, рельсы нужно перекладывать. Получается замкнутый круг: мы работаем и выпускаем документацию, к этому моменту она устаревает, мы пишем новую, и так до бесконечности. Перед нами встала задача: как сделать так, чтобы ничего не потерять и выпустить продукт, который удовлетворит конечного пользователя, и при этом учесть постоянное развитие и изменения в процессах? Посмотрели чужой опыт, запросили у консультантов методики и варианты, но так и не нашли ответа на вопрос, чье кунг-фу сильнее. Поэтому решили из всего многообразия известных подходов выбрать только то, что подходит именно нам. За основу взяли SAFe, немного Nexus, ну и как же без любимого SCRUM.Как мы в итоге выстроили работу проекта?Следует упомянуть, что проект состоит из трех фаз: 1. Концептуальное проектирование;2. Разработка и тестирование;3. Внедрение и завершение работ.Сейчас мы только перешли к третьей фазе, а в рамках этой статьи подробнее поговорим именно про фазу «Разработка и тестирование». Концептуальное проектирование осуществлялось по классической модели Waterfall, так как дизайн методологии разрабатывался в рамках этой фазы. А вот разработку и тестирование мы полностью проходили уже с использованием нашего Agile-mix.Ключевая идея такая: разработка и тестирование разбиваются на инкрементные циклы продолжительностью три месяца. Каждый инкремент состоит из четырех трёхнедельных спринтов. Три из них отведены непосредственно на разработку и тестирование. Четвертый спринт направлен на то, чтобы выпустить общий для всех команд результат по проекту и подготовиться к следующему инкременту. В конце каждого инкремента полученные результаты проделанной работы мы демонстрируем заказчикам проекта – владельцам сквозных процессов. Еще не запутались? Ниже на схеме отражены все фазы.  Фазы проекта внедрения S/4HANA А сейчас давайте глубже окунемся во все тонкости организации нашей внутрикомандной работы.Команды: разделять и особо не властвоватьПринцип формирования и структура команд проекта S/4HANA строится следующим образом: · 10 команд функционального внедрения, где каждая команда отвечает за определенное функциональное направление (например, ремонты, продажи и т.д.);· 3 платформенные: команда миграции данных, команда интеграции со смежными системами и команда сопровождающих сервисов. Все они автономны с точки зрения ресурсов и компетенций и выстроены таким образом, чтобы поставлять функциональный объем направления от начала и до конца (end-to-end). Немного о принципе формирования функциональных команд: мы опирались не только на модули системы, но и на организационную структуру предприятия. Таким образом, функциональные команды сформированы исходя из бизнес-процессов компании. Мы не придумывали экзотических ролейВладелец продукта отвечает за формирование видения и управление бэклогом. Он направляет команду, сверяется с потребностями бизнеса и выравнивается с другими владельцами продукта. Очевидно, что такой человек должен быть гуру в своем функциональном направлении. Функциональный архитектор занимается постановкой технической задачи. Он определяет, как требование должно работать в системе и как разрабатываемая функциональность влияет на смежные команды. Архитектор разработки отвечает за разработку. Он бережет чистоту кода и прозрачность архитектуры, а реализацией требований занимаются, естественно, разработчики.В командах есть тест-менеджер, который отвечает за проверку качества разрабатываемых решений, а также за подготовку материалов и контроль автоматизации тестирования. Scrum-мастер заботится о следовании методологии и атмосфере в команде. В командах нет выделенного скрам-мастера, и кто-то обычно совмещает эту роль с другой (например, с ролью функционального архитектора).Чем мы руководствовались, когда формировали команды? Здесь работают три основных принципа: ставка на внутренние компетенции, самоформирование и функциональное подчинение.Ставка на внутренние компетенцииМы приняли принципиальное решение максимально подключать к проекту внутренних сотрудников, а не приглашенных экспертов. Они не только лучше знают «внутреннюю кухню» компании, но среди них есть те, кто участвовал в прошлом внедрении системы. Эти люди уже «нюхнули пороха» с предыдущим внедрением ERP и, преисполненные опытом, могут спрогнозировать ошибки. Еще нам важно, чтобы все компетенции и знания, полученные в ходе реализации проекта, оставались и в дальнейшем внутри компании. СамоформированиеКаждая команда сама решает, каких людей им не хватает, и может самостоятельно подбирать и нанимать к себе сотрудников. Это помогает избегать длительных процедур поиска и согласования кандидатов и, в то же время подбирать в команду тех людей, которые подходят и по духу, и по компетенциям. Функциональное подчинениеВсех ключевых участников мы вывели из подразделений и полностью переключили на наш проект, чтобы их не отвлекали на другие задачи. Так все могут полностью сфокусироваться на целях и задачах проекта. При этом мы не пересаживали членов команды из своих отделов. Таким образом, не потребовалось переделывать организационную структуру сейчас и не потребуется после завершения проекта: все сотрудники вернутся к своим обычным задачам, но уже будут иметь навыки и компетенции в работе с новой системой S/4HANA. Церемонии, ритуалы и немного магииКаждая команда проводит регулярные встречи или, как принято говорить в среде Agile, — церемонии. На них команды упорядочивают бэклог, планируют следующие спринты и инкременты, выравниваются относительно планов и определяют блокираторы, которые стоят на пути к достижению цели. Внутрикомандные мероприятия — это то, чему мы уделили особое внимание. Перед стартом фазы «Разработка и тестирование» мы провели серию установочных тренингов, где рассказывали командам, как и зачем проводить церемонии. Далее команда методологов помогала командам настроить внутренние процессы, в том числе ключевые Scrum-встречи. Мы заранее предупредили команды, что этот подход не высечен в камне, и впереди нас ждет первый «тренировочный» инкремент. Если команды посчитают, что им что-то не подходит, то мы сможем поменять процессы. Нельзя сказать, что новую методологию все приняли с восторгом. Кому-то она оказалась близка, и они с готовностью включились. Кто-то не понимал эти мероприятия, и для него всё казалось напрасной тратой времени. Мы продолжали работать над осознанностью...Но после первого же инкремента мы получили ответ от команд: «Давайте так работать дальше!» Многие отмечали, что прозрачность процессов увеличилась, скорость выполнения задач возросла, участники стали сближаться и становиться настоящей командой. Важная часть нашей Agile-трансформации – регулярные встречи scrum-мастеров (scrum-of-scrums), на которых мы обсуждаем разные вопросы по улучшению процесса кросс-командного взаимодействия, не обязательно напрямую связанные с методологией. Например, почему бы не назначить один день в неделю, свободный от встреч на уровне программы (чтобы решить текущие задачи команды)? Так что по ходу развития проекта менялись и правила игры. Любые изменения в процессах и нововведениях обязательно сопровождаются коммуникацией на всех участников проекта. Текущее состояние наших правил мы фиксируем в Confluence.В течение проекта мы постепенно добавляли все новые и новые практики. Например, для scrum-мастеров мы организовали agile-интервизии. Они помогают разобраться в проблемах, возникающих в командах. Каждый скрам-мастер формирует кейс и выносит его на общее обсуждение. Также scrum-мастер может обратиться к agile-коучу, вместе с ним разобрать проблему в команде и найти решение в формате супервизии. Если говорить про систему регулярных встреч на уровне всего проекта, то она выглядит так:● стендапы, на которых каждая команда ежедневно выравнивается относительно своих планов;● ежедневный утренний NIT (Nexus Integration Team), где мы обсуждаем технические решения на уровне архитекторов команд, а также риски и блокираторы;● синхронизация владельцев продуктов (PO Synс), где владельцы продуктов сверяют свои задачи и сроки их реализации;● встреча scrum-мастеров (scrum-of-scrums), где scrum-мастера обсуждают текущие проблемы кросс-командного взаимодействия и синхронизируют подходы;● демонстрация результатов спринта (demo), где команды демонстрируют реализованные за спринт задачи;● ретроспектива, которая проводится как для всего проекта, так и для каждой команды в отдельности. На них обсуждают, что необходимо сделать, чтобы в дальнейшем быть более эффективными. Ретроспективы проводятся после каждого спринта и, отдельно, после каждого инкремента;● регулярные встречи по планированию спринта, на них команды определяют список задач для выполнения в начале каждого спринта;● кросс-командное выравнивание по планированию спринта, где представители команд рассказывают, как прошло командное планирование и возникли ли какие-либо сложности;● кросс-командное выравнивание по результатам спринта, задачей которого является обсуждение реализации целей спринта и прогресса по выполнению целей инкремента. Своего рода некое «ревью» по итогам трехнедельной итерации;● презентация интеграционного сценария, которая происходит в последнем спринте, в рамках которого мы интегрируем разработанные решения;● планирование инкремента (PI Planning), которое также происходит после последнего, четвертого спринта, и на котором мы в течение двух дней планируем задачи на следующий инкремент. Жизнь вносит свои коррективы Отдельным вызовом для нас (как и для многих других) стал карантин, который случился на старте проекта. Мы успели арендовать новый офис, чтобы все могли беспрепятственно общаться в духе Agile, провести первое PI-планирование, запустить первый инкремент. А дальше пришлось перестраиваться.Внутрикомандные церемонии легко переехали в online, потому что некоторые участники изначально работали удаленно. А вот с масштабными мероприятиями, вроде PI Planning, оказалось сложнее. И мы взяли таймаут длиной в спринт (коллеги занимались техническим долгом и прочими полезными вещами), чтобы придумать, как обеспечить эффективную работу в online для нескольких сотен человек. В итоге мы разработали план действий с применением online-инструментов, с помощью которых успешно запланировали и завершили еще 5 инкрементов. Так из чего же состоит наше PI-планирование?В классическом планировании все задачи и зависимости между командами фиксируют на доске со стикерами и нитками. Мы заменили ее на цифровую доску Jira. Так мы видим планы с разбивкой по спринтам как в разрезе одной команды, так и всей программы в целом, с учетом межкомандных зависимостей. Зависимости – это взаимосвязанные между собой задачи, в которых одна задача не может быть выполнена, если не выполнена другая.  Задачи и их зависимостиВсе зависимости имеют цветовую индикацию. Красная линия связи – повод поменять планы: выход задачи заблокирован другой задачей, которая планируется к выходу позже. Чаще всего диаграмма пестрит желтыми линиями — они означают, что зависимые задачи завершаются в одном спринте. По таким задачам надо постоянно синхронизироваться, чтобы убедиться, что в планах зависимых команд ничего не поменялось. Зеленая линия говорит о том, что блокирующая задача выполняется раньше заблокированной.Также в рамках планирования мы учитываем все риски и блокираторы, которые могут нам помешать успешно завершить инкремент. Риски и блокираторы программы учитываем в Excel-таблице — и тоже выводим на доску при планировании, а затем в течение всего инкремента мониторим на NIT:  Наши рискиЕще во время планирования мы сразу обсуждаем сценарий интеграционного тестирования, чтобы убедиться, что вся функциональность, участвующая в сценарии, запланирована в инкремент.  План будущего тестированияПомимо Jira в процессе всего планирования мы используем и другие инструменты: · общение – Microsoft Teams;· проведение опросов – Mentimeter; · оценка задач – Voting Poker.И теперь, даже после частичного снятия ограничений, мы все равно проводим PI Planning в online-формате.Подведем итогиС помощью всех вышеперечисленных инструментов и методологии, которую мы обсудили в статье, мы успешно прошли всю фазу «Разработка и тестирование». Выработанный нами Agile-mix позволил качественно следить за выполнением бэклога, оперативно реагировать на изменения и управлять командой численностью более 1900 человек, в распределенном режиме. К тому же, сейчас все встречи и взаимодействия в проекте проходят на 100% в онлайне: мы проверили на себе, что для эффективного выполнения задач не обязательно работать очно, и повысили продуктивность работы на 60% в удаленном формате. На наш взгляд, всё получилось, потому что мы сфокусировались на вовлечении людей в изменения, создании среды для обучения и работе над осознанностью. И, конечно, ввели единые для всех правила игры.Сейчас мы разработали свою методологию с использованием Agile-практик и для финальной фазы проекта: «Внедрение и завершение работ». После того, как мы попробовали работать по этой методологии, уже не хочется возвращаться к более традиционным практикам. Хабравчане, а у вас был опыт применения Agile на больших проектах? Поделитесь своим мнением и историями в комментариях! =========== Источник: habr.com =========== Похожие новости:
Блог компании Северсталь ), #_erpsistemy ( ERP-системы ), #_agile |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 01-Ноя 11:38
Часовой пояс: UTC + 5