All streams
Search
Write a publication
Pull to refresh
9
0
Dmitry Podkorytov @Demetrikl

Developer / Scrum master

Send message
Если весь сыр бор вокруг сложностей перевода, то мне страшно вставать на этот скользкий путь (я собственно поэтому цитирую первоисточник). Понятно что сперва происходит некая деформация сути, когда мы мысль облачаем в слова, но когда еще начинают это переводить, то есть риск сильно исказить изначальный замысел.
Слова очень важны при формулировках, но так же важны люди для которых эти слова произносятся. Ведь формулировка вопроса на DSM очень тесно связано с тем, как команда получала знания о scrum. В целом это уже мастерство SM так ставить вопросы, чтобы помогать команде синхронизировать усилия и сфокусироваться. (серебряных пуль нет нигде, в том числе и в формулировках)

Еще насчет формулировок, я так понимаю, что scrum guide переводит группа энтузиастов. Вы могли помочь им с этим.
«Что ты сделал для достижения цели спринта? Что планируешь делать для достижения цели спринта?» — не имеют смысла.

Ну это вопросы согласно scrum guide:
  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the
    Sprint Goal?


Т.е. цель Daily Scrum — это не отчет о проделанной работе. А фокусировка команды на цели спринта. Инспекция в эмпирическом процессе.
Какие с вашей точки зрения правильные вопросы DSM?
Всё наоборот:

Наоборот с чем? Что вы опять оспариваете?

«Цель скрипта» — это «агрегатная функция» для распланированных задач.

А кто говорил обратное? Это и есть фокусировка, когда цель соответствует набору элементов бэклога, составляющих спринт.
Странно, когда цель и спринтовый бэклог не соответствуют друг другу.
должна?! — с чего вы это взяли?

Согласен неправильно высказался. Конечно «может».

Как несколько универсальных команд должны делить между собой общий backlog?

Ну вариантов уйма. У нас в Wrike 20+ «универсальных» команд. Продукт на всех один — это wrike. Верхне-уровнево продуктовый бэклог один и стратегия общая. Но дальше он бьется по направлениям, и каждая команда отвечает за определенный кусок функционала.

Ваш тезис в чем? Если команды будут не универсальными, то что изменится?
У меня нет опыта, когда все сделали правильно, а команда не вовлеченная. Обычно что-то сделано не так и отсюда проблемы. Поэтому тяжело такой кейс привести. Но исходя из этого:
А задачи для цели делают 2-3 человека (из 8) и в итоге не успевают. По идее, если не успевают, то вся команда должна навалиться и сделать, но сами они это делать не будут.

Проблема то не в вовлеченности участников, а в том что фокуса командного нет.
Я был в ситуации, когда команде нужно за спринт делать разношерстные задачи. Цель спринта выбиралась синтетически (т.е. сперва собирали спринт, а уже потом выписывали цель) — например, самая толстая история — это цель, а остальное подавалось под соусом «это не цель, но тоже очень важно сделать». Но проблема то не в команде, а в такой системе. Решается это все-таки работой с PO и backlog. При желании всегда можно переприоретизировать бэклог так, чтобы истории можно было объединить общей целью. И когда мы пришли к ситуации сфокусированных спринтов (сперва цель, потом истории), когда люди делают задачи под общей целью, то проблема «не переживают, что не достигаем цели спринта» ушла.

Еще момент, нельзя позволять команде садиться на шею SM. Быть только нянькой плохо. Надо жесткости давать.
Отличный вопрос. Спасибо.
Разгонять крайний случай. Большинству людей комфортно в scrum, просто нужна подстройка. Нужно больше деталей конечно, но сходу следующие мысли есть.
Не было групповой ответственности, все продолжали жить в парадигме «я сделал свою задачу, я молодец».

Ответственность это такая штука, которую мало передать, её еще должны взять (прошу простить за капитанство). Отсюда вопрос как у вас проходят планирования?
Кто занимается технической декомпозицией задач? кто определяет цель спринта? кто определяет объём элементов бэклога входящих в инкремент.
ИМХО хорошее планирование должно проходить по следующему сценарию:
  • PO ставит цель на спринт (обсуждается с командой)
  • PO предлагает объем элементов backlog, которые необходимо сделать чтобы достигнуть цели.
  • Команда разбирает (общение с PO) эти элементы, декомпозирует их на задачи (тут важно, чтобы SM фасилитировал и давал высказаться каждому члену команды, чтобы решения были согласованные, а не продиктованные кем-нибудь. Один из возможных инструментов scrum poker)
  • Команда составляет план спринта (сново важно, чтобы высказывались все — за этим следит SM)
  • Команда САМА выбирает тот объем работы на спринт, с которым она согласна, и который она обязуется сделать.


Если же цели не достигаются и инкременты не выпускаются, то на ретроспективе, нужно разбирать с командой: что пошло не так и почему так вышло? Тут опять же роль SM слушать и слышать. Если все сводится к «наши вашим чем то машут», то SM (в зависимости от команды) можно:
  • Вместе с командой попытаться СОВМЕСТНО найти решение, как сделать так чтобы ситуация не повторилась. «Вы согласны что ситуация нехорошая? А давайте найдем способ, как избежать подобной ситуации в будущем.»
  • Напрямую вскрыть причины отсутствия взаимопомощи. «Почему ты не помог, если видел, что команде нужна помощь? Какие у тебя были мотивации? Какие у тебя приоритеты и чем ты руководствуешься во время принятие решений?»
  • придумать что-то свое

В целом SM — это человек, который должен лучше всех чувствовать и понимать команду. Жесткие меры и создание стресса лучше не применять как главный инструмент работы с командой. Но и совсем пренебрегать им я думаю не получится. Иногда нужен холодный душ, чтобы привести людей в чувства.

qwez если это все опять в молоко, то можно перенести общение в личку. Либо тут раскройте побольше деталей про ваш процесс
Зачем бесконечно покрывать? Цепочка создания ценности ограничена, команда не может в рамках неё бесконечно расширять компетенции.

Суть моего высказывания в том, что не стоит выделять команды по компетенциям, т.е. команда фронтендеров, команда бэкендеров и команда QA — это не scrum команды. Scrum команда должна состоять из различных специалистов.
Не стоит путать технические задачи и элементы бэклога. Если в вашем понимании в продуктовом бэклоге лежат задачи типа «Запилить индекс в базе ...», то что-то не так с вашим продуктовым бэклогом.

Scrum guide не дает ответа как должны выглядеть элементы бэклога. Это уже вопрос индивидуальный. Но весьма распространена практика собирать backlog из epics и user story. В таком подходе, я не понимаю как будет следовать специализация историй. История описывает потребность. Команда решает как она будет её закрывать. Наличие различных специалистов в команде дает гибкость такой команде в поиске вариантов решения (любую задачу можно решить кучей способов). Задача команды исходя из своих компетенций придумать такое решение, которое принесет максимальную пользу (value). И команда нацелена доставить инкремент и закрыть пользовательскую потребность имеющимися силами.

Я не понимаю, где тут противоречие? Где потребность в выравнивании членов команды? Узкие специализации отдельных членов команды, только усиливают команду целиком. ВАЖНО чтобы люди не запирались в колодце своей специализации, не для каждой истории может быть необходима именно эта специализация, в такие моменты член команды приносит пользу другой работой.
А не как в этой статье предлагается тянуть всё единственной командой.

Как же вы легко суть то улавливаете? Интересно на чем основан этот вывод?

Нет смысла думать о масштабировании, до того момента пока в одной команде не смогли scrum наладить. Я в статье предлагаю запустить пилот, и уже по его результатам пробовать расширять scrum.
Круто, что мы на одной волне понимания.
100% scrum из под палки не заработает. Через боль можно только создать видимость agile. Это начинает работать только когда добровольно и осознано.
Это все справедливо, но наверное все таки разные плоскости. Scrum может оставаться тактическим инструментом в разработке. Не вижу явной несовместимости инвестирования и наличия scrum. Насколько я знаю на западе некоторые фонды наоборот требуют наличия scrum.
А может и кофе подавать, и полы помыть, чтобы быть при деле и не деморализовывать команду.

Вопрос не в «при деле», а что корону надо снимать. Если мытье полов помогает приблизится команде к цели спринта, то почему бы и нет.
Это нормально — lenta.ru/news/2018/06/05/premier
Это так. Но ценный член scrum команды — это тот, кто умеет кооперировать личные и командные интересы.
Еще мне в свете разговоров о scrum непонятно, что за лютый менеджер, который кошмарит бедных разработчиков?
Отцы-основатели scrum того же мнения, scrum — это практический фреймворк, а не сферический конь. Никто и не требует этого, когда все равны, то
  • если это среднячки, то крутые штуки они делать не смогут.
  • если это мегафулстэки, то не сделать из них команду. Будет лебедь, рак и щука.


Scrum — это про объединение людей с разными специализациями в одну команду, готовых помогать друг другу людей.
Программисты так устроенны, если они не будут что-то новое учить, то их развитие остановится, они начнут чахнуть и убегут с Вашего проекта…
Но прежде всего, когда речь идет о команде, до принятия каких-либо решений, нужно советоваться с самой командой.

Естественно, что если не заниматься рефакторингом, не использовать современные технологии, не работать со свежими версиями библиотек и т.д., то ваш продукт погрязнет в тех.долге и умрет.
Когда команда отвечает за то «как» будет сделана задача, то она вольна выбирать инструментарий, а PO должен довериться ей в этом. Когда команде говорят «ЧТО» делать, т.е. сразу дают тех.задание, то команда начинает битву за технологию.
Кейс именно об этом, что разработчики более сведущие в технологии, дайте им право решать как делать задачу. Это win-win схема PO занимается продуктом и не лезет в детали разработки, а команда решает задачи, о которых им рассказал PO. Они верят, что если PO сказал, что у пользователя болит тут, то это не пустые слова. А как снять боль — это команда решает сама и делает это лучшими средствами.

Для примера тот же лидер в команде. Вы говорите что лидера быть не должно… Но где Вы найдете команду из ТАКИХ профессионалов, которые в лидере не нуждаются?

Не совсем так, я говорю что «назначенный» лидер и scrum плохо подходят друг к другу. Лидерство должно быть ситуационным и органическим. Команда сама понимает, что Вася мегакрут в СУБД, а к Пете можно обратиться по вопросом браузерной оптимизации JS. Просто это естественный процесс, не нужно влезать в него бюрократической машиной.

Таких команды если и есть, то ну в очень и очень и очень крутых компаниях. Поэтому получается что либо scrum только для крутых компаний,

Дело не в крутизне компаний, а в том для чего вам scrum и как понимание этого донесено до людей. Как уже не раз писалось, scrum — это не серебряная пуля. И к сожалению, работать в scrum могут не все люди (жесткий индивидуалист с болью встраивается в scrum процесс). Но если scrum вам подходит, то при правильной настройке, вы получите то, чего хотите. А моя статья — это некие маячки необходимости подстройки.
Да про мотивацию абсолютно верно. Совсем недавно была статья на хабре про реалии российского IT рынка. Что очень странно ждать вовлеченности от людей на окладе. Запад это давно осознал и опционы — это просто мастхэв. Надеюсь наш рынок дорастет до этого.
Но с другой стороны не только менеджеру полезен t-shaped
В современном мире технологии стремительно рождаются и умирают, прокапывая в глубь конкретную технологию можно оказаться на дне, когда технология уже никому не нужна. Если же в угоду менеджерам человек будет смотреть вширь, то ему самому легче будет оставаться актуальным и востребованным на рынке.
Прекрасно расписано!
Помимо самих скилов в букве Т, важна готовность делать задачи в горизонтальной плоскости. Важно различать «можется» и «хочется». ИМХО scrum говорит о том, что команды в которых люди готовы делать не профильную работу — более подвижны и способны к адаптации.

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Date of birth
Registered
Activity