я их не делю по подкомандам, команда одна но внутри нее могут быть разные роли

для клиента ценность представляют деньги так как это бизнес, вы что ему денег даете?

все эти скоростя ну как бы правильно сказать сколько у вас скрам команда 300 символов в час или в чем вы скорость разработки считаете?

Для клиента ценность - это продукт, который позволяет решить проблемы этого клиента

Оценки вообще штука очень субъективная. Как можно полагаться на оценку времени выполнения, когда она может изменяться в процессе работы на десятки процентов?

какие у него проблемы он к вам пришел дал денег у него очевидно все не плохо

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

> Как можно полагаться на оценку времени выполнения, когда она может изменяться в процессе работы на десятки процентов? Говорят в 5-10 раз. Для мелких задач в пределах дня.

В скраме стоянием над душой занимается коллектив. Командное самосознание ))

Но скрам далеко не всем заходит. Даже не скрам, а именно работа в команде с высоким уровнем коммуникаций

Есть реальный пример из практики. Парень в классической функциональной команде работал, слабо тянул. Взяли его в скрам-команду. Через полгода его производительность возрасла на порядок.

Функциональная команда покрывала важное направление. Скрам-команда создавалась с нуля под продукт

тоже видел там все

Кроме скрама?

Да я не про то. Я как бы спросил - скрам видели?

да я сам пару раз внедрял ну и на мне тоже внедряли в свое время))

Там по определению кросс-функциональные команды. Не заработало? Решили на функциональные подразделения переехать?

почему получалось и работало но не в чистом виде, в чистом виде я видел скрам один раз на заре своей карьеры и это был лютый фейл так как к тим лиду приставили нас джунов первая работа и вот начался скрам

ну я описывал в силу архитектуры проектов на дистанции уже не получается брать разные задачи все рассаживаются по модулям, естественно накрошиш им юзер стори сам, ну там оценять уже ну и завесишь таски сам и так понятно кто что будет делать

ну я описывал в силу архитектуры проектов на дистанции уже не получается брать разные задачи все рассаживаются по модулям, естественно накрошиш им юзер стори сам, ну там оценять уже ну и завесишь таски сам и так понятно кто что будет делать

Как ребята и девчата справлялись в ваше отсутствие интересно

Для меня функциональные подразделения всегда оссоциировались с очень большими препятствиями при изменении. Приходиь в компанию, которая уже имеет устоявшуюся структуру и инструменты, устаревшие 5-10 лет назад, видишь как бэк и фронт пилят одну и ту же фичу, но потом синтегрировать не получается. Говоришь - а давайте тесты в терминах бизнел логики сделаем на gherkin. Будем одни и теже формулировки автоматизировать на бэке и фроне и в итоге интеграция упростится. На что ответ - говорите с тимлидом ) А тимлид зашивается, ведь он один решения принимает ))

Для меня функциональные подразделения всегда оссоциировались с очень большими препятствиями при изменении. Приходиь в компанию, которая уже имеет устоявшуюся структуру и инструменты, устаревшие 5-10 лет назад, видишь как бэк и фронт пилят одну и ту же фичу, но потом синтегрировать не получается. Говоришь - а давайте тесты в терминах бизнел логики сделаем на gherkin. Будем одни и теже формулировки автоматизировать на бэке и фроне и в итоге интеграция упростится. На что ответ - говорите с тимлидом ) А тимлид зашивается, ведь он один решения принимает ))

Я вижу именно проблему в иерархии. Ключевой человек рано или поздно перегружается если не делегирует обязанности. А если делегирует то он уже не ключевой и иерархия тогда смысла не имеет. В противовес кроссфункциональная команда (без тимлидов - это важно). Я иду к бэкенд разработчику и вы сами решаем как нам интегрироваться. И никто не пострадал и никто не перегрузился. Команде потом решение сообщили - нас поправили, если у кого-то возникло желание.