Sergey
Есть тысячи вариантов.
Pavel
Или вот, тоже пример, чистый софт, но связан с процессингом платежей в системе visa. PSM II прям тебя заставит сделать специализированную комплайнс-команду.
Pavel
Sergey
Возможно. Нужно понимать контекст
Pavel
Не путай :)
Sergey
Фронт стори, бэк стори, а в третьем Спринте мобайл стори. Скрам, че ..
Pavel
Ай, антипаттерны agile - еще не водопад.
Sergey
Да я шучу.
Pavel
Значит строй водопад. Будет эффективно :) Я не предлагаю строить в этом случае LeSS. Я просто рассказал как в нем это решается. У нас так.
Зря не предлагаешь. LeSS более-менее универсален и по идее должен работать везде, где работает scrum
Sergey
Специализация команд это потеря гибкости и риски.
Pavel
Специализация команд это потеря гибкости и риски.
Сергей, но команды в любом случае специализируются.
Pavel
Это часть командообразования.
Sergey
Зря не предлагаешь. LeSS более-менее универсален и по идее должен работать везде, где работает scrum
Он и работает. Просто для этого в каждой команде должен быть специалист по Коболу. Пусть даже совмещающий это со знанием джиэс
Pavel
Чтобы не было специализации, тебе придется либо постоянно "ротировать" команды, либо на этом мысль останавливается :)
Pavel
Он и работает. Просто для этого в каждой команде должен быть специалист по Коболу. Пусть даже совмещающий это со знанием джиэс
Зачем, если их надо всего три?:)
Sergey
Сергей, но команды в любом случае специализируются.
Представь бэклог. Пять команд. На планировании первые пять элементов берет любая из команд. Но каждой по одному. Потом вторые пять элементов ...
Sergey
Зачем, если их надо всего три?:)
Чтобы фичу могла делать любая команда. Тогда специализации не будет.
Sergey
Заболел, не заболел, уволился, не уволился - рисков нет.
Sergey
Это называется власть специалиста
Sergey
Незаменимость.
Pavel
Чтобы фичу могла делать любая команда. Тогда специализации не будет.
Сергей, так у тебя получится не "любая команда" в этой ситуации. У тебя получится, что в любой команде естьч еловек, который работает сугубо над кодом на коболе для фич, которые с остальнйо командой не будут пересекаться.
Sergey
Неа. Там еще есть много чего кроме кобола
Pavel
Неа. Там еще есть много чего кроме кобола
Но вот конкретно этот товарищ пишет только на коболе :)
Pavel
И егоф ичи уходят строго в мейнфрейм.
Sergey
Фича идет в команду. И она целиком отвечает за результат. Просто таких фич с коболом будет мало
Pavel
Сергей, так не получится.
Pavel
Вот ты размазал спецов по всем командам.
Pavel
Вот пришла фича.
Pavel
Она связана с разработкой на коболе, потому что надо в легаси поковыряться и т.п.
Sergey
Но вот конкретно этот товарищ пишет только на коболе :)
Что Ты будешь делатью если в системе будет 15 компонентов на разных языках?
Pavel
НИКТО кроме этого спеца в команде ее сделать не может. Он над ней будет работать один.
Pavel
Остальные будут работать над другими фичами.
Sergey
НИКТО кроме этого спеца в команде ее сделать не может. Он над ней будет работать один.
Наверное. Но в каждой команде. А не один на всех. Мы же про специализацию команд?
Pavel
Что Ты будешь делатью если в системе будет 15 компонентов на разных языках?
Плакать, скорее всего Кровавыми слезами, рвя остатки волос с макушки и проклиная себя, что я опять влез в финансы и банки :)
Pavel
Наверное. Но в каждой команде. А не один на всех. Мы же про специализацию команд?
Так может эффективней, чтоб они работали в команде? А не один типа в команде но на практике изолированно.
Pavel
Т.е. вот ты засунешь кобол в команду к жавистам и жсникам
Sergey
Вот вот. Мне недавно рассказали как ходят в одном банке королями два спеца по одной оракловой системе. Поплевывают ;)
Pavel
А у них инструменты разные, правила написания кода разные, подходы разные... вообще все разное, даже инженерные практики нельзя пошарить.
Pavel
В чем кроссфункциональность?:)
Sergey
Так может эффективней, чтоб они работали в команде? А не один типа в команде но на практике изолированно.
Тогда велкам в кросс-функциональные компонентные команды. Скрам это не запрещает.
Sergey
А у них инструменты разные, правила написания кода разные, подходы разные... вообще все разное, даже инженерные практики нельзя пошарить.
Изучать. Тут без вариантов. Я это у себя наблюдаю. Норм все ;)
Sergey
А у них инструменты разные, правила написания кода разные, подходы разные... вообще все разное, даже инженерные практики нельзя пошарить.
Стандартизация методов и подходов
ISO 9001 ....
Sergey
В чем кроссфункциональность?:)
Кросс-функциональность в возможности делать любой элемент бэклога без внешних зависимостей. Скрам же ;) Команда должна ... процитировать Скрам-гайд?
Sergey
Стандартизация методов и подходов
ISO 9001 ....
Тут я пас. Я много видел компаний с липовыми сертификатами. Как то не верю я в их магическую силу.
Pavel
Кросс-функциональность в возможности делать любой элемент бэклога без внешних зависимостей. Скрам же ;) Команда должна ... процитировать Скрам-гайд?
Сергей, давай я тебе такую аналогию приведу: у тебя в команде автомеханик, специаист по Oracle, юрист-международник, музыкант и офицер морской пехоты США. Ваш продукт - клон игры Carmageddon
Pavel
Команда кроссфункциональная? Да.
Команда может в таком составе выпустить продукт? Нет.
Pavel
Что из гайда не соблюдено?
Pavel
И не подумай, что ответ "ничего". гайд нарушен :)
Pavel
Если у тебя мультикомандная разработка и один из компонентов системы требует вмешательства узкого специалиста, но редко - смысл в наличие специалиста в каждой команде будет... редко.
Pavel
А вот смысл в команде специалистов, которые будут помогать остальным командам с такими редкими запросами - часто.
Sergey
Да я не против. А если для него не будет работы, дальше что?
Pavel
А теперь возвращаясь к бэклогам. Так как вот таким командам обрабатывать свои результаты ретро?
Pavel
Ну ок, в общий бэклог. Но оттуда их будут доставать только они же.
Pavel
То есть мы все равно получим бэклог команды, только спряем его внутри общего бэклога.
Pavel
ЗАЧЕМ?
Sergey
Также и компонентная команда с тремя кобол специалистами может перестать быть нужной. А может наоборот завтра весь бэклог станет только для кобольщиков ... мы теряем гибкость в этом случае.
Sergey
То есть мы все равно получим бэклог команды, только спряем его внутри общего бэклога.
Сложный ты. Я же согласился, что система тяготеет к этому. И в этом случае мы теряем гибкость. И рассказал как этого избежать. А что выбирать - отсутствие гибкости или затраты на специалистов и их обучение - решать надо в конкретной ситуации
Pavel
Сложный ты. Я же согласился, что система тяготеет к этому. И в этом случае мы теряем гибкость. И рассказал как этого избежать. А что выбирать - отсутствие гибкости или затраты на специалистов и их обучение - решать надо в конкретной ситуации
Я не согласен с тем, что система в такой ситуации теряет гибкость :)
Pavel
Четко выделяя бэклоги команд мы прозрачность повышаем. Что в этом не гибкого - я не вижу
Sergey
Контекст важен. Это все на уровне теории
Pavel
Вводя компонентные команды - да, теряем. Но компонентные команды это только один пример специализации.
Pavel
Мне больше импонирует feature\user journey team
Sergey
Если завтра один из бэклогов опустеет, ты не сможешь команды быстро переключить на новый код или даже язык. В этом гибкость.
Pavel
Если завтра один из бэклогов опустеет, ты не сможешь команды быстро переключить на новый код или даже язык. В этом гибкость.
Да, это риск. Хотя ситуация в которой бэклог пустеет ВНЕЗАПНО - несколько гипотетическая :)
Sergey
Да, это риск. Хотя ситуация в которой бэклог пустеет ВНЕЗАПНО - несколько гипотетическая :)
Угу. А вот степень риска и тяжесть последствий зависит от контекста.
Pavel
Сергей, ну отсутствие компонентных команд тоже не без риска :)
Pavel
Даже в проектах без супер-легаси на коболе или разработки железа.
Sergey
Мне больше импонирует feature\user journey team
Угу. Customer-focused feature teams. Именно на них и строится LeSS
Jane
Pavel
Самый распространенный пример из мира екомерс и немного геймдева - обработка платежей. Очень... неудобно, когда каждая фичекоманда пишет свою обработку :)
Sergey
Сергей, ну отсутствие компонентных команд тоже не без риска :)
Угу, контекст и еще раз контекст. И выбор фреймворка идет оттуда жеъ
Pavel
А один раз написать не получится :)
Sergey
Ох нас забанят скоро :)
Pavel
Jane
😂Почитать вас интересно
Pavel
Угу. Customer-focused feature teams. Именно на них и строится LeSS
ТАк вот такие команды тоже отлично специализируются :)