Пробовали такое на практике? Поделитесь опытом :)

Для каких именно задач мог бы подойти настолько дорогой в использовании подход, как считаете?

А что про это модель Кеневина говорит?

А давайте попробуем без коучинга, ближе к конкретике? Мне ваше мнение интересно, как автора темы.

Ок, в следующий раз попробуйте начать не с коучинга :) А на счет Кеневина я серьёзно. Он вполне отвечает на ваш вопрос.

То что написали про uML на первый взгляд напоминает создание и описание клиентского пути , которое обычно и делает вся команда. Для узкоспециализированных юнитов (коквыми являются участники энтерпайзов кровавых) я не вижу преимуществ. Аналитик("технолог") будет оркестрировать команду. Тестер не сможет покодить, особенно если систем несколько в разных стенах итп

Но при этом тестер сможет адекватно оценить объём тестирования. Особенно это важно, если аффектится сторонняя система.

Ну началось. Моббинг реально очень дорог в применении - вся команда тратит время на всего одну задачу. Очевидно, что себестоимость фичи при этом адски велика. Поэтому я задал конкретный вопрос - "для каких задач вы считаете подходящим предложенный вами метод?" Где в нем коучинг? Или вы предлагаете его для любых задач и поэтому вопрос вам показался коучинговым?

«Он» это Сноуден? Кеневин это название модели, которую предложил Сноуден.

Не дороже обучения.

В "кровавом" на UML окажется не только клиентский путь, но и взаимодействие между компонентами продукта/решения. В описании мне очень понравилась аналогия с машиной: "Это как в вождении машины: один человек управляет рулем, а другие помогают ему с навигацией и советами..." (в реале водитель им скорее отвечает: "идите на*** со своими советами, не мешайте вести машину! Иннокентий, ты в карту смотришь, подскажи на каком перекрестке поворачивать. А остальные - просто не мешайте" )))

Обучения чему? Я утверждаю, что далеко не в каждой задаче нужно обучение всей команды. А если в каком-то проекте оно нужно в каждой задаче, у проекта в этот момент большие проблемы. И у команды тоже.

Как вы считаете, сможет ли тестер так же адекватно оценить объем тестирования по уже готовым материалам (диаграммам, псевдокоду, писанию изменений и т.п.)? Я вот думаю, что сможет. И ему не придется переоценивать все промежуточные варианты, который будут отброшены в процессе проектирования.

И моббинг, и парное программирование, и скрам в целом - это не дешево. Но, хотят слухи, что если в результате поставка будет не через пол-года, а через 1-2 недели, то в это даже ок.

если

Как правило, проблема срока поставки не решается простым увеличением количества участников. Если задача действительно настолько мелкая, что можно сделать поставку за 1-2 недели, задержка "на полгода" находится вне команды. Предположу, что это какая-то внешняя зависимость. Она совершенно точно не решается сбором всей команды вокруг единственной задачи.

Так не было речи о простом увеличении

Закрепление всей команды на единственной задаче на весь срок ее жизни, разве не увеличение участников на конкретной задаче? А что тогда?

Предложи более эффективный и быстрый способ т-шейпнуть членов команды.

Скрам говорит о том, что в течение спринта вся команда фокусируется на цели спринта. Везде ли подходит скрам? Я уже вначале говорил, что на этот вопрос отвечает Кеневин фреймворк. Не понимаю вас, чесслово.

Вот опять. Мы обсуждаем моббинг. Его сюда притащил не я, но я пытаюсь понять его границы применения, хоть какие-то аргументы от предлагающих моббинг получить. А ты мне предлагаешь сейчас что-то изобрести "еще лучше". Так мы пока не поняли еще, лучше чего именно надо предложить способ.

А, ну ок.

Увы, Кеневин был изобретен не для выбора способа управления проектом. Это антипаттерн - так его использовать.

Скрам - он тоже не про проекты, чоужтут.

При это пропускная способность будет крайне низкая

Да. Временно. И обычно мы знаем, ради чего такие жертвы.

Ну и в итоге получается что Scrum - это как раз очень дёшево

почему временно?

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

а, понял... сама практика моббинга временная, поэтому и падение временное

Да, именно.

То что описано выше - не моббинг, а какая-то дикая фантазия аффтара, где красивое слово просто притянуто за уши к куче странных идей.

А каков правильный моббинг?

видосик в ютубе смотрят вместе просто. Вообще не верю в эти моббинги, пейринги и прочее. Если человек знает, то решает задачу. Не знает - максимум спросит лида за 5 минут и пойдет ковырять дальше. Тем более мы говорим про наших айтишников, которые являются не самыми социализированными личностями. И собрать в такую группу их мог либо видосик на ютубе, либо показательная фотка типа “давай выложим на фб каком мы крутой коллектив”

Я думаю, что как и с любым термином, введёным в оборот конкретным человеком, стоит придерживаться его собственной формулировки. Конечно, Вуди много чего наговорил, как продуктивный спикер, но максимально каноническое определение будет звучать как-то так: Mob Programming is a development practice where the whole team works on the same thing, at the same time, in the same space, and on the same computer. It is a whole-team approach to doing all the work the team does including designing, coding, testing, and working with the customers, users and other stakeholders. This is an evolutionary step beyond pair programming and accentuates face-to-face communication, team alignment, collaboration, and self-organizing team concepts of the Agile approach to software development.

Я иногда про скрам такое слышу тоже. И про брак мужчины и женщины частенько)

отличие в “натягивании”. Ни скрам, ни брак с воздуха не появится. Всегда кто то придет и скажет типа нам срочно надо или кто то там срочно хочет. В случае с низкоуровневой частью работы (то есть конкретно разработка) мало кто будет натягивать групповую работу за одним компом. Это же простой кучи людей. А если еще и трекеры стоят, то как потом клиенту продать пустые мониторы

Стикер

Бывают компании, в которых следят не простоем людей, а за скоростью поставки и компетенциями. Просто другой опыт.

UML действительно вполне подходит для психологического насилия, так почему бы и нет?

Ну это зависит от того смог ты прочитать и осознать 1-2 книги и 1-2 статьи или нет.

Вот, уже началось

Ну согласись от своих способностей многое зависит. У меня получилось разобраться и для меня UML не насилие. Хотя я чистый гуманитарий. А у кого-то не получилось и это вызывает боль, унижение и страдания. Это всегда нужно держать в голове как параметр в формуле)

Насиловать окружающих можно и сложным инструментом и простым. Это не связанные вещи. А если и связанные, то весьма неочевидным образом. Так, например, я не уверен, доказана ли корреляция между желанием психологически насиловать людей каким-либо инструментом и склонностью гордиться его освоением.

Заказная разработка от продуктовой сильно отличается. Моббинг на галере вряд ли продать.

Работа в паре идёт быстрее. Я проверял. Быстрее просто потому что есть "уточка" с которой можно обсуждать. А режиме кодирования напарник - это штурман. Кроме кодирования это хорошо работает при подготовке документов (договоров и других), потому что штурман видит дальше.