Комментарии 28
Таки а что есть "скрам"?
Или как можно оценить РоС?
Похоже на Грабли номер 2. Что именно вы скрыли под этим термином? Полагаю вариант Proof of Concept, не так ли?
В моей организации единогласно под этим подразумевают Participative Organizational Conduit (это методология Adizes). Наверное, надо обращать внимание на вторую букву, но и там есть третий известный термин.
Но если даже это какой-то концепт, то эстимировать на него время необходимо. И чаще всего только на основе интуиции. Эстимирование вообще основополагающий KPI любого сотрудника, хотя бы его собственной части.
все верно, Proof of Concept
Прости, дорогой, когда я пришел в интернеты, кириллица не поддерживалась
Не прощаю, тем более, мне известен всего один интернет, а не несколько, к тому же в 95-х окнах всё прекрасно поддерживалось, только кодировку надо было нужную выбрать, до этого так же неплохо заходило, что с ДОС-а, что с оболочки окон 3.х
Так что вначале исправь свой ник (пора бы уже), а потом что-то другим советуй, иначе проходите дальше…
Пример: команда должна проводить рефайнмент сессии и оценивать скоуп своих задач. Классно звучит...
Чё? А по-русски?
ребята, я тут методичку прочитала на 16 страниц, сертификат получила, сейчас я буду вам рассказывать, как нужно выстраивать скрам/канбан процесс". Реально?? Можно было просто сказать "вы тупые, работали столько лет неправильно, а я умная, сейчас вас научу". Я была бы послана обратно со скоростью пули.
Как гласит пословица: "Хочешь помочь мастеру - отойди и не мешай!". Особенно если все знания и опыт сводятся к "методичке на 16 страниц".
Тем более, даже в PMBOK написано, что SCRUM/Kanban и т.д. не должны быть самоцелью.
Грабли №5. Слушать команду
Она реально лучше знает, как надо.
Пример: команда должна проводить рефайнмент сессии и оценивать скоуп своих задач. Классно звучит, но мы некоторые задачи не можем оценить и не делаем этого. Вот как можно оценить саппорт скрам-команды, когда она переходит....ну пусть на java 14? Или как можно оценить РоС? А совместный рефакторинг архитектора и команды?
Как быть: методички - класс, их писали не идиоты. Но всегда задавайте вопрос "а что для нас важно: следовать процессу или делать качество?"
Не пытайтесь повторить.
Этот параграф выглядит как набор бессвязных предложений. По крайней мере, я не понял, он раскрывает тему "слушать команду"
Одна из идей скрама состоит в том, чтобы избавиться от всяких «лидов». Лиды не масштабируются, это центральная точка отказа, они аккумулируют знание, которым не умеют делиться, их иногда переезжает автобус, или же они уходят в другие компании.
Папа-лид заболел - и команда, как стадо овец, топчется на месте, потому что либо не имеет права принять решение, либо не имеет компетенции, либо не имеет информации.
Все гибкие методологии так или иначе содержат идею о том, что команда должна быть самодостаточной, независимой единицей. «Лиды» в этой структуре - прошлый век, отголоски типичных иерархичных моделей.
Скрам-мастер это тренер, задача которого — помочь команде вырасти, научив идентифицировать проблемы и показав, как их решать.
Согласен. Но СМ не разработчик и не может вникнуть в проблемы команды достаточно глубоко чтобы решать их максимально эффективно. Суть моего комментария скорее была в том, что обязанности СМ должен брать на себя разработчик из той же самой команды, а не отдельный рандомный человек и это и есть в моем понимании лид.
Ну, добро пожаловать в аджайл ;)
Хочу посочувствовать, что приходится использовать SAFe. SAFe не имеет никакого отношения к аджайлу, это старый-добрый waterfall, щедро обмазанный сверху дремучей бюрократией. В сети достаточно ресурсов, рассказывающих про врожденные проблемы SAFe, искренне рекомендую. Я понимаю, что решение использовать SAFe пришло из Deutsche Telekom, но тем не менее врага нужно знать в лицо.
Хотел бы обратить внимание на несколько пунктов в тексте:
приходит зеленый скрам мастер в систем тим (ох уж этот SAFe), где сидят матерые мужики (простите за сексизм) в составе архитекторов, конфиг-менеджеров и автоматизатора и говорит: "ребята, я тут методичку прочитала на 16 страниц, сертификат получила, сейчас я буду вам рассказывать, как нужно выстраивать скрам/канбан процесс". Реально?? Можно было просто сказать "вы тупые, работали столько лет неправильно, а я умная, сейчас вас научу". Я была бы послана обратно со скоростью пули.
"Сеньорность" определяется не выслугой лет, это не армия. Одними из важнейших характеристик "сеньора" является открытость, способность к рефлексии и стремление постоянно улучшать свою работу. Без этого он продолжает оставаться джуниором, не важно, какой title написан у него в договоре найма.
Если вы сталкиваетесь с командой (будь то команда архитекторов или команда тестировщиков), которая отвергает любые изменения или не способна давать качественный фидбек, не стоит сразу относить это на счет своей "зелености". Смотрите на это как на challenge, на возможность помочь команде действительно вырасти.
мы некоторые задачи не можем оценить и не делаем этого. Вот как можно оценить саппорт скрам-команды, когда она переходит....ну пусть на java 14? Или как можно оценить РоС? А совместный рефакторинг архитектора и команды?
Все задачи из приведенных примеров можно оценить. Вы молодцы, что позволяете работать принципу "individuals and interactions over processes and tools". Но у оценок есть важная функция: заставить команду подумать о задаче до того, как принять ее в спринт. Неоцененные задачи любят попадать в спринт и вызывать там всевозможные затыки, потому что внезапно, каждый раз, с ними что-то оказывается "не так просто".
Если команда говорит вам, что задачу нельзя оценить, это сигнал о том, что они просто не хотят думать над задачей. Нужно начинать хоть с каких-то, максимально грубых оценок, стимулировать обсуждения "а что, если ...?", и, по мере увеличения опыта команды, добавлять больше деталей.
на первых порах я с рвением пыталась решить все, что команда высказывала на ретро. А как иначе, это же Impediment! А классный скрам-мастер должен их устранять.
Скрам-мастер не мама. Задача скрам-мастера - научить команду видеть и решать свои проблемы самостоятельно, помочь команде стать той самой самоорганизующейся командой.
Да, проблемы, поднятые командой, нужно приоритезировать, это должна делать сама команда. Нужно выбирать несколько важнейших проблем и максимально делегировать их решение команде.
Подведу итог. Вы на верном пути. Нужно только помнить, что скрам-мастер - не слуга команды, не мальчик на посылках и не офис-менеджер. Скрам-мастер это тренер, задача которого - помочь команде вырасти, научив идентифицировать проблемы и показав, как их решать.
вау! спасибо за советы!
Не за что.
У большинства скрам-мастеров, которых я видел, есть проблема с самоопределением. Они не знают, кто они, зачем нужны и чего хотят. Особенно сильно это заметно на пост-советском пространстве, где аджайл все еще воспринимается как ЕЩЕ более креативный способ глумления и капиталистической эксплуатации простого трудяги от клавиатуры.
Скрам-мастер, как тренерская роль, не может жить без плана, без стратегии. Выработайте себе стратегию и последовательно реализуйте. И помните, что ваша задача - не таски в джире копипастить и стулья на митинге расставлять, а поднимать команды на новый уровень совместной работы и коммуникации.
Да, внезапно может оказаться, что «сеньоры» совершенно не умеют работать в команде, потому что они привыкли всю жизнь сидеть в своем подвале. Они будут сопротивляться изменениям, это нормально. Это от того, что на самом деле они не «сеньоры». Придется вытаскивать их на свет божий и объяснять, почему для компании важно чтобы все были открытыми, работали вместе.
Интересная в общем работа, да ;)
Топ-10 граблей начинающего скрам-мастера