Однобоко я имел ввиду, что команде ок ,а бизнес не понимает, что делать с этим человеком )

получается алтернативы путешественнику нет

иначе как его контроллировать, какие метрики использовать и пр?

Можно сообщество еще создать, пусть мастер-классы поделает с представителям каждой команды. Тут только надо добровольно чтобы. Важно.

Про гильдии спотифаевские вспомнил

это да, это решили. Но это тоже неконтроллируемо выходит

не рисовать же ему личную канбан доску )

это да, это решили. Но это тоже неконтроллируемо выходит

И не наджо заставлять, иначе не сыграет. У нас много сообществ умерло прежде чем получаться начало.

Коллеги, у вас тут каждый божий день обсуждения скрам гайда и то, как его лучше, правильнее понимать. Если не брать в расчёт резонный вопрос, а когда вы работаете, то вот подумалось - а если safe так же, с таким же пристрастием обсуждать, так ведь это сколько лет можно говорить в чате не переставая, т. к. объем то куда поболее будет, да и пред метов для об уждения не сравнимо больше. 😊😊😊

Коллеги, у вас тут каждый божий день обсуждения скрам гайда и то, как его лучше, правильнее понимать. Если не брать в расчёт резонный вопрос, а когда вы работаете, то вот подумалось - а если safe так же, с таким же пристрастием обсуждать, так ведь это сколько лет можно говорить в чате не переставая, т. к. объем то куда поболее будет, да и пред метов для об уждения не сравнимо больше. 😊😊😊

Нормально работаем :) Иногда не поднимая головы.

Коллеги, у вас тут каждый божий день обсуждения скрам гайда и то, как его лучше, правильнее понимать. Если не брать в расчёт резонный вопрос, а когда вы работаете, то вот подумалось - а если safe так же, с таким же пристрастием обсуждать, так ведь это сколько лет можно говорить в чате не переставая, т. к. объем то куда поболее будет, да и пред метов для об уждения не сравнимо больше. 😊😊😊

Простите. Я понимаю, что не надо говорить, надо фигачить код. Но не могу удержаться.

Нормально работаем :) Иногда не поднимая головы.

👍😁👍😁

Коллеги, у вас тут каждый божий день обсуждения скрам гайда и то, как его лучше, правильнее понимать. Если не брать в расчёт резонный вопрос, а когда вы работаете, то вот подумалось - а если safe так же, с таким же пристрастием обсуждать, так ведь это сколько лет можно говорить в чате не переставая, т. к. объем то куда поболее будет, да и пред метов для об уждения не сравнимо больше. 😊😊😊

а для чего вообще этот чат тогда?

отрефлексировали и дальше пошли командам улыбаться

Коллеги, у вас тут каждый божий день обсуждения скрам гайда и то, как его лучше, правильнее понимать. Если не брать в расчёт резонный вопрос, а когда вы работаете, то вот подумалось - а если safe так же, с таким же пристрастием обсуждать, так ведь это сколько лет можно говорить в чате не переставая, т. к. объем то куда поболее будет, да и пред метов для об уждения не сравнимо больше. 😊😊😊

В SAFe обсуждать нечего. В SAFe очень мало собственных разработок, это компиляция из опробованных методов и практик.

блин, идеалисты вы мои. Да понятно что надо шерить знаиния и все такое. Ну например это полгода займет, мне на это время проект остановить? )

Если в команде появился супергерой полимент «Человек-бутылочное горлышко», то стоит его суперсилы распределить. Например принудительно обьединить его в постоянную пару (или тройку) с другими разработчиками так, чтобы он не «работал» а строго объяснял паре, что делать.

А «пара» - делала и заодно документировала

Можно для этого даже task force team создать из представителей нескольких команд

Если в команде появился супергерой полимент «Человек-бутылочное горлышко», то стоит его суперсилы распределить. Например принудительно обьединить его в постоянную пару (или тройку) с другими разработчиками так, чтобы он не «работал» а строго объяснял паре, что делать.

Он не появился в команде, он был и он вне команд. Такой стартовый сетап

Тем проще

Поподробней )

В SAFe обсуждать нечего. В SAFe очень мало собственных разработок, это компиляция из опробованных методов и практик.

Ну на скрам гайд по объёму наберётся. Да и в scrum не все новое, есть и заимствованное. Как говорится, все новое - хорошо забытое старое

Поподробней )

Сколько команд?

4 я писал

Из каждой команды назначается доброволец с достаточными тех скиллами. Задача добровольцев - работать в паре с супергероем. Работа идёт в формате: супергерой подробно объясняет, что делать, доброволец делает.

Ещё один доброволец документирует.

Затем меняются местами, но не с супергероем - он всегда только говорит и объясняет

Из основной команды на время уходят?

Да

Путешественник но наоборот ) ок

Да:)

Не надо заставлять. Старайтесь добровольцев искать.

Можно пряником ...

Это понятно. Заставлять не наш метод

Не надо заставлять. Старайтесь добровольцев искать.

Заставлять - не наш метод (да и не сработает). Только добровольцы, их всегда можно назначить:)

Заставлять - не наш метод (да и не сработает). Только добровольцы, их всегда можно назначить:)

Ты это, пинта кофе тебя так взбодрила? :)

Ты это, пинта кофе тебя так взбодрила? :)

Я ее еще не выпил :)

Я ее еще не выпил :)

Пока не выпил мою ересь почитай. Интересно твое мнение https://t.me/agile_ru/65060

А точно ересь?

Да не ересь

Но и нового ж нет

Вообще про самоорганизацию очень клево в Management 3.0 рассказано. И где границы и как их ставить :)

Это и правда Дод и критерии приемки. Все уже придумано )

Самоорганизация - она жеж вокруг how. Но для нее требуется понимание what и why.

Т.е. команда должна разделять не только ценности ажайла, но и видение продукта. Иначе будет... так себе самоорганизация.

отрефлексировали и дальше пошли командам улыбаться

👍

Самоорганизация - она жеж вокруг how. Но для нее требуется понимание what и why.

Спс

Спс

А текст полностью почитаю, как проснусь окончательно :)

Ок

А ограничения - это все, что за облаком? Или само облако?)

За облаком. Все что давит снаружи. Альтернатива это то что между требованиями и ограничениями.

Чем больше пространства, тем больше свободы :)

Понятно :) Не хватает как по мне более развренутого заключения. Если это конец уже, конечно

Ну я запостил ф фейсбук. Возможно коллеги еще что-то подскажут.

Антон Бевзюк “Каждая организация — сложная адаптивная система. Это похоже на игру, в которой правила меняются на ходу, а функция разработки игры делегирована самим участникам. Ваша работа как менеджера состоит не в том, чтобы создать достаточное количество правил, по которым будет играть ваша организация. Ваша задача — создать ситуацию, в которой люди будут совместными усилиями создавать собственные правила. Именно их совместные усилия и позволяют системе найти свой путь к кромке хаоса (или к кромке упорядоченности, если вам так больше нравится). Самоорганизация способна сама найти кромку хаоса, когда ее параметры оказываются в определенном критическом интервале. Менеджер не занимается разработкой игр. Его не должно беспокоить, какие правила будут действовать на нижних этажах организации. Его задача — настроить самые общие параметры, такие как разнообразие компетенций членов команды, беспрепятственный обмен информацией между людьми и отсутствие препятствий для коммуникации между командами.” Excerpt From: Юрген Аппело. “Agile-менеджмент: Лидерство и управление командами”. Apple Books. Короче говоря, мы как менеджеры (а СМ - это тоже менеджер) создаем ограничения (например соблюдения правил скрама, или что команда - это фичакоманда со всеми причиндалами, или что на обзоре спринта показываем только то что на продакшне), а дальше команда сама экспериментирует с набором практик в рамках этих ограничений.

Это комментарий Антона из ДоДо. Захотел эту книгу почитать.

Всем привет! Очень хочу попрактиковаться в построение BPMN, UML и других диаграммах. есть какие нибудь как сборники задачь?) или задания с примерами, что бы сначало самой разробраться, а потом посмотреть как лучше було бы сделать? В моей работе этого очень не хватает.

Всем привет! Очень хочу попрактиковаться в построение BPMN, UML и других диаграммах. есть какие нибудь как сборники задачь?) или задания с примерами, что бы сначало самой разробраться, а потом посмотреть как лучше було бы сделать? В моей работе этого очень не хватает.

Никто не скажет как лучше. А если и скажут - бегите от них. Быстро-быстро.

Если хотите описывать процессы нормально, почитайте Репина. Либо кого из забугорных. Фамилий не знаю. Может коллеги помогут.

Всем привет. А есть тут SM или PO, которые работают с DT мобильного приложения (iOS+Android)? Хотел бы пару вопросов задать.

Всем привет. А есть тут SM или PO, которые работают с DT мобильного приложения (iOS+Android)? Хотел бы пару вопросов задать.

Прям Sm + PO?

Прям Sm + PO?

Или :) Хотя, может и Лид помочь :)

Или :) Хотя, может и Лид помочь :)

Ну это некашерно. Ты тут это слово не надо. Побьют :)

Лид по уровню знаний, а не роли :)

Ну это некашерно. Ты тут это слово не надо. Побьют :)

Тут скорей за кашерно побьют )

Лид по уровню знаний, а не роли :)

Это называется старший )

😂

Что это?

Эх не успел чей-то квартальный план посмотреть

Было б что обсудить )

Или :) Хотя, может и Лид помочь :)

Если +/- трехлетний опыт подойдёт - спрашивайте :)

В смысле опыт был три года назад :)

Вы спрашивайте да, там посмотрим

У меня тут тоже две мобдев команды

Окей, тогда вот

Запускаем новый продукт. Я SM. Нужно поставить процесс разработки на рельсы. Разработка будет вестись на бэке, Android и iOS. По каждому направлению будет 2 человека, пока. Дизайнер один, тестер один. Это и есть команда. Продукт, как сказал, одни, бэклог один, но в нем могут быть фичи специфичные каждой платформе. Плюс разрабы iOS могут писать быстрее или медленнее чем, Android, и наоборот. Бэк должен работать на шаг впереди, имхо. И ещё всяких нюансов присущих разработке мобильных приложений. Вопросы: 1. Как были организованы команды у вас? 2. Как декомпозировались задачи: выделяли отдельно для платформ, бэка? 3. В работу брали задачи фичами (инкремент - это готовый iOS и Android c одинаковой функциональностью) или тасками разных фичей в зависимости от производительности разработчиков платформ, готовности элементов? 4. В трэкере был один общий проект или разные в зависимости от платформы? 5. Какие принципы работы и грабли, на которые не нужно наступать, можешь обозначить с ходу?

Всем привет. Поделитесь опытом, коллеги. Ситуация: сейчас в команде 3 разработчика. Android - МСК, Android - Казань, Back - Казань. Хотим расширяться и взять еще 3 людей: 1 на Back, 2 на iOS. Брать можно только в разные города. У меня в голове сейчас две парадигмы: 1. Фичи-команды (Android, iOS, Back) в каждом городе 2. Пары по компетенциям в кадом городе. Например, МСК - 2 Android, Казань - 2 iOS, 2 Back. Что думаете? Если есть какие-то альтернативы, то очень хочу услышать.

Это все в продолжении вот этого.

Самое главное, что я не могу понять это кейс: мы берём в работу вот эту фичу и отдадим её в конце спринта и на Android, и на iOS или же мы берём в работу вот эти таски по бэку, iOS и Android (могут быть связаны фичей, а могут и нет. Например, Android опережает iOS по фичам)? 🙈

Два варианта.

Две команды, одна иос, одна андроид, бэк в каждой, куа в каждой. Разное время выведения фич в прод как следствие. И вообще считай два продукта