«Да кто такой этот ваш аджайл?! Мы же не продуктовая команда!», «И как меня угораздило в это вляпаться?!» — такие выражения (и много чего еще) я часто слышала на командных встречах архитекторов в роли агента изменений.
Всем привет! Я – Мадина, скрам‑мастер в Департаменте управления технологиями МТС, у нас это подразделение называют Департаментом Technology Governance (TechGov).
Наше подразделение (относительно недавно созданное) занимается управлением технологиями на уровне всей компании. Если коротко – структура Департамента представляет собой Центры компетенций и Центры практик.
Центры компетенций описывают практики, методологии и стандарты, центры практик занимаются внедрением и масштабированием этих практик по всем продуктам компании. Трансформация, а тем более технологическая – дело непростое, и без применения гибких методологий тут не обойтись.
Agile не ограничивается только продуктовыми командами, любое подразделение в компании может получить пользу от внедрения этой методологии. Ведь Agile – это не просто модное слово, это философия работы, которая позволяет улучшить процессы и более эффективно достигать поставленных целей. Тем более, наш департамент занимается Продуктовой трансформацией в том числе, а это значит мы должны следовать принципу Eat your own dog food (практика использования компанией или командой разработчиков собственных сервисов и продуктов).
Но одно дело (тоже весьма непростое) — внедрять скрам или канбан в командах разработки, где есть понятный инкремент и стейкхолдеры. И совсем другое — внедрять гибкие подходы в Центрах компетенций или практик. Таких, например, как архитектура, управление производственным процессом, R&D или даже сам Центр практик Agile.
Мой путь агента изменений был нелегок и тернист, я набила кучу шишек, случались и провалы. Но я извлекла из этой истории много уроков и, кажется, мы с командой смогли нащупать верную дорогу, используя здравый смысл, и начали ощущать пользу от внедряемых изменений.
Итак, от директора по развитию технологий TechGov поступил запрос на скрам-мастера в Центры практик и компетенций управления корпоративной архитектуры. Запрос звучал примерно так: «Нужен гибкий подход к реализации задач. Продуктовые практики при разработке стандартов и методологий».
Ключевые стратегические направления, которыми занимается Центр:
ArchOps;
Бизнес-архитектура;
CloudNative;
Архитектурные стандарты;
Технологический радар;
Open/Inner Source;
и другие направления.
Стоит ли говорить о том, как было тяжело первое время вникать в суть дискуссий и задач на командных встречах? Например, тема встречи такая: «Обсуждение метамодели аналитических и архитектурных артефактов». Я гуглю: «Что такое метамодель?» и получаю ответ: «Метамодель – это модель, описывающая другую модель».
Эммм... спасибо…
Что я увидела на старте: каждый сотрудник занимался своим, на первый взгляд, узкоспециализированным делом и особо не заботился о том, что происходит за пределами своей области ответственности. И да, до меня команда уже работала в спринтах, проходили синхронизирующие встречи.
Было множество митингов, презентаций и писем друг другу, но на практике реализация и внедрение проходили туго. Спринты закрывались и открывались формально, никаких процессных метрик не велось. Во избежание бунта я решила начать процесс изменений поэтапно. Сначала встретилась с каждым членом команды на индивидуальной встрече, и мы заполнили шаблон STATIK.
Основной моей задачей было погрузиться в работу центра и понять, какие проблемы есть на поверхности.
Вот какие проблемы мы вместе обозначили:
много зависимостей, которые очень сложно решаются или не решаются совсем;
непрозрачный канал коммуникации между руководством, смежными подразделениями;
«я не понимаю, чего от меня хотят».
Пообщавшись с директором и каждым участником команды я для себя сделала вывод, что команда находится примерно на красном уровне развития, если оценивать по спиральной динамике:
А значит, нам надо постепенно выходить на синий уровень, а это инструкции, правила, постоянные ритуалы. Если короче – дисциплина.
Этап 1. И тут мы пришли к гигиене Jira…
Что было (тут прошу понять и простить за «англицизмы», но в нашей профессии без них никак:)):
Lead time* задач несколько месяцев, выполнение запланированных задач на спринт только 20%. Задачи и истории не соответствовали объектной модели**, принятой в департаменте.
*Lead time задач — промежуток времени, необходимый для выполнения задачи.
**Объектная модель Jira — это совокупность объектов (epic, story, task) их свойств, параметров и взаимосвязей (звучит почти также как объяснение термина метамодель, знаю????).
Очевидно, что для управляемости и прозрачности ситуацию нужно было улучшать.
И тут начались вопросы: «а зачем?», «а почему?», «я не хочу опускаться на уровень задач, мне достаточно эпика на квартал, это мой фокус». Но, конечно же, для меня, агента изменений, это все не ново. Где-то вопросы решались уговорами, где‑то «шантажом», где-то пряником, а где-то кнутом.
И тут есть немаловажная деталь — это полная поддержка директора. Он четко понимал ценность всех этих шагов и помогал мне на каждом шагу, донося до команды, что я не просто какой‑то «внешний коуч», а такая же часть команды, нацеленная на результат.
Постепенно с командой мы стали улучшать метрику «план/факт» по спринту. То есть ребята научились планировать как минимум на 2 недели с фокусом на какую-либо ценность.
Я настроила дашборды (информационные панели), которые визуализировали работу и фиксировали «нарушения» гигиены и нашей объектной модели. Кажется, теперь не надо уже вести кучу разной отчетности, разрозненные таблицы в Confluence с отчетом о прогрессе по какому-либо направлению, ведь все описано в Jira, по результатам приложен артефакт и достаточно в плагине Structure посмотреть ход выполнения задач. Выглядит это примерно так:
А вот так выглядит завершенная работа по спринту во встроенных дашбордах Jira:
Причем доступ к задачам есть у любого сотрудника департамента, каждый может посмотреть прогресс и чем занимается центр.
По регулярным событиям: помимо планирования/обзора спринта у нас появились ежедневные короткие стендапы и ретроспективы. На начальных этапах казалось, что ежедневные встречи для синхронизации — это лишнее время, которое можно потратить на более полезную работу. Но постепенно команда осознала, что такие встречи помогают нам следить за прогрессом каждого участника и оперативно решать проблемы. Эти стендапы стали нашей ежедневной рутиной, без которой мы уже не можем представить работу.
А ретроспективы – это место, где мы обсуждаем насущные проблемы и пытаемся их решить.
Чего удалось достичь на первом этапе: появилась сфокусированность на конкретных задачах, ребята стали больше общаться друг с другом, научились решать зависимости друг перед другом более эффективно. Улучшение гигиены Jira помогло решить вопрос с прозрачностью, все реже и реже мы слышим от руководства вопросы о том, кто чем занят и какого результата удалось достичь по тем или иным активностям, так как к любой задаче всегда приложен артефакт.
Этап 2. Взаимодействие снаружи
Теперь, когда мы более или менее разобрались с работой «внутри», пора понять, что происходит у нас «снаружи». Тем более, что ком зависимостей и проблем во взаимодействии копился все это время во всем департаменте. Очень много работы зависело от смежных центров/платформ/отделов. Мы то и дело слышали:
«Ну я встречу закинул, а он не пришел».
«Ну мы встречу провели, а ничего не меняется».
«Ну я отправил письмо, а ответа нет».
Вывод напрашивается сам: нужна общая «синхровстреча». Мы в Центре практик Agile всей командой методологов и скрам мастеров долго думали, как эту проблему решить. Поначалу были попытки проведения таких встреч онлайн, но каждый раз то ключевые сотрудники не подключались, то вовлечение было минимальным.
Поэтому мы решили собрать всех в одном месте и в одно время, чтобы сначала обозначить друг другу зависимости (пресинк), а потом после цикла квартальных планирований рассказать. приняли ли мы обязательства по выполнению зависимостей или нет (постсинк). Для нас это был эксперимент, мы не очень представляли, сколько зависимостей есть по факту и есть ли смысл в проведении такого мероприятия. Чисто интуитивно понимали, что оно необходимо. Что интересно, что и сами сотрудники считали, что зависимостей не так много. И тут мы подготовили доску в Miro, где попросили весь департамент обозначить зависимости, чтобы на встрече уже предметно их обсуждать. И вот как выглядела доска:
Итак, встреча проходила ровно 1 день в офлайн формате. Собрать всех в одном месте стало тем еще приключением. Мы долго прорабатывали адженду, обсуждали, как настроить эффективную работу в группах, артефакты и образ конечного результата. Встреча была проведена, многие зависимости были проговорены вообще впервые. Но уже к обеду опрос показал, что очень многие смогли договориться:
Что же касается центра архитектуры, то на пресинке к архитекторам выстроились очереди из зависимых центров. Это очень четко подсветило, насколько важные задачи решает этот центр и сколько коллег в буквальном смысле слова от него зависят.
После проработки зависимостей, мы пришли к тому, что в Центре архитектуры пора вводить практику проведения PI Planning.
Этап 3. Масштабируем и каскадируем
Теперь наступило время погрузиться в процесс внедрения и масштабирования практик, которые разрабатывает центр корпоративной архитектуры по всей компании. Давайте вернемся к структуре, которую я описывала ранее более детально:
Как происходит сейчас:
Центр компетенций разработал стандарт и отдал его в Центр практик на внедрение. Центр практик встречается с Главными архитекторами и рассказывает о стандарте и о том, как его внедрить.
На «уровне техники» это воспроизводится процессом каскадирования эпиков. То есть Центрами компетенций и практик прорабатываются эпики и 1 раз в квартал эти эпики массово каскадируются* (назначаются) на Главных архитекторов. Например: необходимо, чтобы все продукты компании внедрили у себя определенный стандарт. Для этого создается эпик, описывающий этот стандарт и какие действия необходимо проделать, чтобы его внедрить.
Далее эпик массово клонируется (каскадируется) на представителей всех кластеров компании, а они уже клонируют этот эпик в продукты. У продуктов есть требование на реализацию стратегических эпиков технологической трансформации (от нашего департамента) в виде 25% от бэклога, поэтому они выбирают скаскадированные эпики, которые смогут «осилить» за квартал.
Так, главные архитекторы кластеров также массово каскадируют «архитектурные» эпики на продукты. Все это происходит в асинхронном режиме с «посредниками» в виде центра практик Стратегия.
А теперь представьте масштабы нашей компании и продуктов в ней. То есть, когда мы каскадируем массово эпики на все продукты и ожидаем, что эпики должны быть реализованы в срок, кажется, что это заранее невыполнимый KPI.
А вот как это выглядит со стороны продуктов — когда к тебе 1 раз в квартал «прилетает» эпик (даже очень хорошо описанный и с понятной ценностью) все равно непонятно как «впихнуть» это в свой бэклог, когда там висят очень важные и горящие идеи для бизнеса. Вот и получается «кидание мяча» от одних к другим, претензии и недовольства.
Видится, что формат PI-планирования — очевидный шаг, который поможет синхронизации и выравниванию. Во втором квартале мы уже провели пилотное PI-планирование сначала внутри центров архитектуры (что, кстати, помогло решить проблему «я не понимаю, чего от меня хотят»), в следующих кварталах планируем подключить к этому Главных архитекторов, чтобы процесс был обоюдовыгодным и каждый чувствовал свою сопричастность и ответственность за результат.
Циклы планирования будут выглядеть так:
И, наконец, этап 4. Метрики, исследования и выводы
Внедрение продуктовых практик мы начали с базового тренинга по продуктовке. Теперь мы прорабатываем дерево метрик и проводим исследования эффекта от внедрения той или иной практики. Результатом этой деятельности должна стать ситуация, когда Владельцы продуктов сами будут обращаться к нам с просьбой помочь внедрить ту или иную практику, видя, как у соседнего продукта стали улучшаться показатели.
В целом, внедрение Agile в центр корпоративной архитектуры стало сложным процессом, но правильная организация работы помогла достичь успеха.
Сегодня, как мне кажется, мы стали более продуктивными и адаптивными к изменениям, более открытыми для общения и сотрудничества в команде, непрерывно улучшаем наши метрики, процессы и инструменты. И эти достижения стали возможными только благодаря командной работе и полной поддержке руководства.
Впереди еще много работы, ведь трансформация — это непрерывный процесс.
Можно сказать, что мы уже на четвертом уровне. Как достигнем пятого – ждите еще одну статью:)
Совместим ли Agile и Центры архитектуры? Думаю, что однозначный ответ — да. Я, наверное, впервые услышала от руководителя Центра фразу: «Первый раз вижу скрам-мастера, который приносит пользу».
P.S. Если у вас есть вопросы – с радостью отвечу на них в комментариях. Там же жду ваши истории о внедрении Agile в непродуктовых командах и опыте работы со скрам-мастерами.
Комментарии (39)
dididididi
22.06.2023 15:33+1Ага. А потом ты тратить день, чтоб передвинуть задачку из статуса "в разработке" В статус "сделано", а оказывается, что задачки критичного уровня непривязанные к сторе релизного эпика, может двигать только автор эпика по чётным четвергам релизного цикла, если он овен. А там ещё в конце 4 статуса " Завершено", "сделано", " Закончено", "закрыто". И ты долго думаешь, завершил ты её или сделал, а потом звони скрам мастер и говорит, и ругается что баги закрываются, стори заканчиваются,а в статус сделано разработчик передвигать не имеет права, только течтировщик, а завершено передвигает бизнес-оунер и всём жто понятно, а ты единственный идиот не допер.
madina676 Автор
22.06.2023 15:33-5Это очень смешно, честно:))
просто, к сожалению, суровый российский энтерпрайз превратил скрам-мастеров в секретарей jira, а ведь это совсем не так) мы в своем центре за ролевую модель берем Теда Лассо и на разных уровнях зрелости команд применяем разные техники и инструменты.На вводной встрече с командой моей первой фразой было: "Мы с вами вместе постараемся создать комфортную среду для работы", что тогда не очень понравилось, как мне кажется, руководству, но что в итоге сыграло всем на руку. Главное, не забывать о здравом смысле везде.
dididididi
22.06.2023 15:33+6Два абзаца и нифига не понятно! На байта полезной информации! Божечки! Это шедевр канцелярщины! Жгите ещё!
dididididi
22.06.2023 15:33"Причем доступ к задачам есть у любого сотрудника департамента, каждый может посмотреть прогресс", но никто не смотрел, потому что это никому не вперлось, потому что ничерта непонятно, итак затрахали своими совещаниям по "метамоделям архитектурного цикла". Когда ж я уже стану старый буду ходить по тупым совещаниям кивать и улыбаться и нести ерунду и зарабатывать много денег.
dididididi
22.06.2023 15:33+5Автор, пишите ещё! Каждый абзац - это шедевр дикой бюрократизации и эффективного менеджмента.
madina676 Автор
22.06.2023 15:33-3Дорогой комментатор, спасибо) непременно еще напишу:)
Может можно познакомиться с эффективным процессом работы, который выстроили вы в очень успешной команде? Было бы очень полезно почитать)
dididididi
22.06.2023 15:33+1Ну я смог одного скраммастера в тестировщицы перевести. Вторая почуяла, чем пахнет и перестала фигню нести, и статусную модель в жире покромсала с 36 статусов до 8 и отменила три обязательных церемонии, и стала гораздо быстрее из вести, и свой покер себе подальше засунула.
madina676 Автор
22.06.2023 15:33-1Ну это, конечно, очень крутое достижение! За такое можно и «подраконить» незнакомого человека в сети:)
INCorpes
22.06.2023 15:33Скрам мастер рассказывает о том нужен ли Скрам мастер... похоже на job security. Надо просить минимум коллег, чтобы они написали нужен ли им Скрам мастер, а в идеале команды, которые обходятся без них в принципе ;)
funca
22.06.2023 15:33"Жандарм – это порядок, а порядок никто не любит". В разных компаниях реальные функции и полномочия скрам-мастера сильно разнятся, поэтому без знания местных особенностей обсуждение нужен/не нужен это холивар. Кроме того, как у любых руководителей, многое определяется сугубо личными качествами и опытом.
Str5Uts
22.06.2023 15:33Дело в том что в данном случае тут нет даже примера того как их "стратегические" эпики звучит и из каких задач состоят.
Тут же на сколько я понял идут стратегические эпики по маршруту ЦК > ЦП > Кластер, в размере 25% от бэклога.
Т.е. на команду, какой-то хрен с горы вываливает мутную дичь и вместо делания своей работы, ты должен этой дичью заниматься.
madina676 Автор
22.06.2023 15:33Ну если повышение надежности продукта или уход с нецелевых технологий - это дичь, то да.
Str5Uts
22.06.2023 15:33+1Без конкретики это голословные утверждения (т.е. дичь), у вас это в статье невооружённым взглядом видно.
когда к тебе 1 раз в квартал «прилетает» эпик (даже очень хорошо описанный и с понятной ценностью) все равно непонятно как «впихнуть» это в свой бэклог, когда там висят очень важные и горящие идеи для бизнеса. Вот и получается «кидание мяча» от одних к другим, претензии и недовольства.
Если у команды есть реальных 25% времени чтобы внедрить хорошую технологию «с понятной ценностью» то никто не будет бодаться, а с радостью за это возьмутся. Если же дичь — то будет «кидание мяча».funca
22.06.2023 15:33+1Если у команды есть реальных 25% времени чтобы внедрить хорошую технологию «с понятной ценностью» то никто не будет бодаться, а с радостью за это возьмутся.
Здесь как с уборкой - в теории всем нравится когда удобно и красиво как в пятизвёздочном отеле, но в реальности менять своих привычки бросать носки куда попало и разгребать авгиевы конюшни за другими ни кто не стремится.
У меня по опыту внедрение новых технологий и полезных инженерных практик, по большому счету это всегда боль. Причем менеджмент с их сроками и бюджетами здесь полбеды. Много отрицания идёт от самих же инженеров - людям удобнее и кажется безопаснее работать так, как они привыкли.
Для того, чтобы изменить что-то технически, сперва приходится менять самих людей: либо учить и воспитывать пока новые подходы не войдут в привычку, либо в прямом смысле. Банальный пример - кодстайл. На одном из проектов внедрение заняло больше года, т.к. взрослые дядьки на серьезных щщах ни как не могли договориться относительно отступов: табы или пробелы.
Str5Uts
22.06.2023 15:33+1Я попросил конкретные примеры, чтобы понять что это вообще такое "повышение надежности продукта или уход с нецелевых технологий" и какого типа задачи.
По моему опыту, полезные изменения многим были интересны, некоторым безразлично, но чтобы противиться — то только на задачи типа "дичь".
Ну ещё можно предположить вариант, что например если делаешь бизнес задачи то по KPI тебе будет премия. А если будешь заниматься задачами от этого ЦК, то дырку от бублика.
Ну или говорят 25% на задачи, а в реальности по бизнес задачам грузят 100% и получается что надо 125% выдать на гора.
funca
22.06.2023 15:33Мне бы тоже хотелось видеть конкретные примеры, чем они занимаются. Хотя фокус статьи на другом, поэтому не вижу смысла критиковать автора, она рассказала про свой кусочек работы.
полезные изменения многим были интересны, некоторым безразлично, но чтобы противиться — то только на задачи типа "дичь".
"Дичь" это субъективная оценка. Во многом она зависит от прошлого опыта и текущих скиллов. Люди совершенно разные. Кто-то понимает и готов с радостью подхватывать изменения, другие наоборот - не понимают, или не видят для себя лично пользы, или видят угрозу и тормозят. Со всем этим приходится работать.
Str5Uts
22.06.2023 15:33+1поэтому не вижу смысла критиковать автора,
Лично автора смысла критиковать нету.
Она винтик в машине большой организации, кто-то придумал такую структуру и определил рабочие потоки. Автор работает в рамках возможного.«Дичь» это субъективная оценка.
Я работал в компаниях подобного размера.
Соответсвенно их ЦК — может быть как полезная часть организации, так и заповедник оторванный от реальности. Вот тут конкретика в виде общих деталей задач расставит всё по местам. Чем дальше по иерархии отстоит это от реальных команд, тем меньше шансов что это адекватный отдел. Если там задачи типа «привести текущие архитектурные модели к новому стандарту метамодели аналитических и архитектурных артефактов», вот это я называю дичь.
Опять же судя по статье создаётся впечатление что этот отдел стоит в стороне от основной структуры, соответсвенно он не имеет отношения к основной деятельности и не зависит от критерий успеха команды.
Т.е. сторонний дядя приходит и тебя заставляет заниматься корпоротивными играми и при этом то что он делает может тебе жизнь испортить, но не улучшить её.
INCorpes
22.06.2023 15:33+1Про порядок это обобщение, мне нравится порядок и я не скрам мастер :). Зависит от команды в целом.
В разных компаниях реальные функции и полномочия скрам-мастера сильно разнятся, поэтому без знания местных особенностей обсуждение нужен/не нужен это холивар
Есть правда в Ваших словах
Hasthur
22.06.2023 15:33+1Порядок - это здорово. Но включать в проектную работу очередного административного
паразитавредителя - не решение. Вы безусловно правы: руководитель решает. Может кому-то и хочется иметь своего карманного ИБД-мастера, чтобы рисовал релаксирующие метрики. Цена вопроса
dididididi
22.06.2023 15:33+1Мы этого конкретного обсуждаем. Она свои обязанности описала.
Про порядок я сам двумя руками. Но опять же, для меня порядок это системность. А у ней про системность речи не идёт вообще. Дашборжов накрутила, совещаний насобирала, чо сделала непонятно.
INCorpes
22.06.2023 15:33+2Тем более, что ком зависимостей и проблем во взаимодействии копился все это время во всем департаменте. Очень много работы зависело от смежных центров/платформ/отделов
Надо было просто провести тренинг по эскалации и разруливанию конфликтов
Итак, встреча проходила ровно 1 день в офлайн формате. Собрать всех в одном месте стало тем еще приключением. Мы долго прорабатывали адженду, обсуждали, как настроить эффективную работу в группах, артефакты и образ конечного результата. Встреча была проведена, многие зависимости были проговорены вообще впервые. Но уже к обеду опрос показал, что очень многие смогли договориться
А еще было потрачено куча денег компании, потому что наличие большого количества человек на митинге в большинстве случаев не слишком то эффективная штука. Почитайте "Death by Meeting: A Leadership Fable"
Сегодня, как мне кажется, мы стали более продуктивными и адаптивными к изменениям, более открытыми для общения и сотрудничества в команде, непрерывно улучшаем наши метрики, процессы и инструменты
Какие были метрики ДО прихода скрам мастера, "как мне кажется" это такой себе показатель эффективности. Возможно до Вашего прихода всё было лучше, хоть и менее организовано.
madina676 Автор
22.06.2023 15:33-2Если про производственные метрики, то lead time снизился более чем в в 2 раза. План/факт увеличился с 30% до 80%.
Об улучшении метрик упоминается в блоге)
dididididi
22.06.2023 15:33+2Синтетические показатели(
у меня тоже по лидтайму метрики есть, доп геморрой, вместо того чтоб сформулированную задачку положить в бэклог, её держат в текстом файлике и кладут прям перед реализацией, или в процессе. Ну и толку?
План/факт достигается снижением плана(
Вы на людей надавили, они стали часть времени тратить на подтасовку метрик, а толку?
Тупой вопрос: а по аджайлу можно давить на людей, требуя выполнения плана? Или по скраму хз в чем разница
madina676 Автор
22.06.2023 15:33-2Я вот не пойму, у вас какая-то личная обида на скрам-мастеров?
Вы со мной никогда не работали, вы не видели, как работает моя команда. У нас с ребятами очень доверительные дружеские отношения и после всех тех циклов налаживания инструментов и процессов, я еще ни разу не слышала негатива в сторону agile практик от команды, даже наоборот ребята постоянно сами просят помощи, например, в фасилитации, медиации конфликтов. Более того, есть центры, которые увидев то, что мы делаем приходят и сами просят скрам-мастеров «включиться» в их работу.
Если для вас так невыносимо существование скрам-мастеров, может каждый останется при своем мнении?
mirraim
22.06.2023 15:33+2В моем опыте было два диаметрально противоположных подхода у скрам-мастеров.
С одним из них мы этих дашбордов и метрик в глаза не видели - хотя они были(их обсуждали пару раз на встречах с ПМ, необязательных для разрабов). Работа работалась, спринты закрывались с 90% выполненных задач, код фриз и релизы за редким исключением в срок.
Другой мастер: куча непонятных затянутых совещаний, разные дашборды и метрики. Итог: постоянные переносы релизов и неоттестированный код в проде. Постоянные попытки "усилить команду" не показывали никаких значимых результатов. Зато этот мастер обладал очень хорошо подвешенным языком и все озвучиваемые на ретро проблемы закидывал позитивным словесным мусором. Внешне все было очень дружелюбно, но большая часть команды со временем просто перестала озвучивать реально существующие проблемы, потому что бесполезно.
Я понимаю, что вы, возможно, хороший скрам-мастер. Но, может быть, на самом деле вам просто перестали озвучивать проблемы?
mickvav
22.06.2023 15:33+1Идея собраться всем оффлайн и договориться - это на определенном масштабе организации прям правильная вещь. Без этого жизнь боль. Но да, это надо готовить и продумывать, а не просто загнать всех в одну комнату.
BugM
22.06.2023 15:33+1Скрам мастер конечно нужен. Вдруг штаты сокращать придется. Будет кого уволить чтобы отдел не пострадал.
dkuzminov
22.06.2023 15:33+1Помню, как пришел к нашей QA-инженеру (дело давно было, тогда мы притворялись, что работаем по CMMI level 5) и спросил, что именно за метрики она от меня хочет (какие-то строчки кода посчитать). По тому, как было сформулировано, было неясно, и возникли разные интерпретации. Чтобы лучше понять их потребности, я стал допытываться, что именно они с нашими метриками потом делают. Ответ убил. "Не знаю, я просто в Excel таблицу эти метрики записываю" -- было мне ответом.
anz
22.06.2023 15:33+2Вот вроде бы я тоже разработчик, должен все понимать... Но как будто про параллельный мир написано, вообще даже представить не могу что там у вас за центры практик и принятия решений. Похоже на рыбный текст
Наверное поэтому разработчики не любят вас, скрам-мастеров, потому что не понятно что за херню вы делаете, но с ужасно умным видом, клевыми словечками и огромными зарплатами
funca
22.06.2023 15:33Над уровнем архитектуры приложений находится архитектура систем. Но если вы хотите, чтобы системы в вашей организации строились по каким-то общим принципам, то получается нужна архитектура архитектур, модели моделей (метамодели) и все вот это. Довольно абстрактная деятельность, которая находится на три уровня абстракции выше конечной разработки, однако может иметь там самые серьезные последствия - как в плане побед, так и ошибок. Результаты такой деятельности в разработку падают в виде спецификаций, бест практик, запросов на изменения и т.п. Часто проблемы возникают из-за того, что архитекторы коммуницируют это в виде экшен айтемов - что нужно сделать, пропуская предпосылки - для чего. В итоге разработка действительно не понимает для чего все это нужно и потом всячески сопротивляется.
anz
22.06.2023 15:33+2Я немного слукавил в своем комментарии. На самом деле я понимаю о чем написано. Тема то здравая, идет обсуждение как управлять огромной системой!
На самом деле то, что описано в статье - зубодробительно просто. Причесать джиру, немного всех организовать. Но это все завернуто в "архитектуру архитектур" и "три слоя абстрактности". Все эти мысли - на поверхности, до них дойдет любой не дебил. Это поверхностный слой и это никого не интересует.
Расскажите в чем жыр. Почему ваша методология сработала? Почему тесное оффлайн общение решило кучу проблем? Какие сложности внедрения? Как вы работали с людьми? Какие метрики? Чего стала добиваться компания, чего раньше не могла? Начальник был на моей стороне и пропушил все в команды, где тут вызов?
Просто когда смысла особо нет, но хочется сделать посерьезнее, приходится заворачивать в умные слова и фразы. От этого смысл ускользает совсем и статья становится рыбной и не понятно
Str5Uts
madina676 Автор
Очень жаль, что у вас сложилось такое впечатление о скрам-мастерах и надеюсь, на вашем пути когда-нибудь встретится достойный скрам-мастер:))
vamireh
Именно такую и отправят в декрет. А недостойные будут работать.
Хех, сколько во мне сексизма, аж самому приятно
dididididi
В декрет отправят ту, что красивше(((
Hasthur
100% )) Хорошо, когда эти "мастера" и "подмастерья " не сильно мешают реальной работе. Но когда этот коммуникационный обвес желает продемонстрировать свою мнимую полезность - всё начинает реально буксовать
dididididi
Не.. Эту в Жиру пускают, она там может натворить. Вот те которые в поверпоинтах презентации делаю и экселях, те безобидные.
Hasthur
О том и речь ) В Жире они, как правило, такой кошмар навертят... Действия ради действия. А ты потом на этой дичи спотыкаешься на каждом шагу: вместо того, чтобы заниматься нормальной разработкой, раскладываешь на борде "пасьянсы"