(1) Это наверно хорошо. А как же ваш коллега, уходящий в декрет и уносящий с собой сакральное знание? ...

(1) ...

(1) Проблема может и не их, но чем-то заниматъся как минимум оден день надо. У нас таких ситуаций не было, потому что ПО таких фокусов себе не позволяет, но иногда бывают небольшие простои и непонятки, и члены команды сами решают, чем им заняться в это время. Правда у нас всегда есть кто-то в доступе, с кем можно посолветоватъся и кто возьмет на себя ответственность за это решение. ...

(1) Совершенно согласна! ПO обязан составить концепцию для разработчиков и организовать составление технических концепций для бэкенда, а также макетов для фронтенда. Потом проверить, соответствует ли реализованное командой этим четким требованиям. А не писать команде "реализация не соответствеут требованиям клиента". Это вообще знак того, что ПО сел в лужу.Заранее озаботиться передачей дел от уходящего в декрет коллеги должен бы был скраммастер, но и члены команды конечно тоже. В общем, ощущения, что ни ПО, ни скраммастер самый минимум своих функций не выполняют. ...

(1) А с какой целью ПО написал вам "Ребята, косяк, тот проект, что мы устанавливаем 1.07 и уже протестировали - не соответствует заявленным требованиям клиента"?Цhего он от вас ожидает? ...

(1) Так вы ж вроде жаловались недавно, что только скрам-мастер решает, что включить в спринт...Решает он в том, смысле, что следит за тем, чтобы ПО не решал, что включать в спринт. Сам он решать не может по причине отсутствия нужной информации. ...

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

(1) Да! Опасное сочетание избытка свободного времени, недостатка знаний и желания оправдать свое существования несет нехорошие плоды ...

(1) Тестирование это отдельная тема. Вообще-то тесты должны быть интегральной частью разработки. И каждая фича должна перед деплойментом быть протестирована всеми возможными способами. Юнит-тесты вообще часть разработки, насколько я понимаю. В Build-Pipeline проходят тесты. Акцептанc-тесты, автоматические и мануальные. Автоматические систем-тесты, UI-Тесты. Это все должно быть частью процесса. То есть многое тестируют прямо разработчики. И после всех этих тестов и отправки апдейта клиентам, не должно обнаруживаться множества багов. Естественно, на системе клиента что-то может пойти не так из-за и ...

(1) Так вот, тот, который fachlich (и с которым мы работали до сегодняшнего дня), тоже, как и Алла, удивлен, что до продукта, собственно, задачи не доходят. Все какие-то организационные моменты и технические необходимости. Я, как разработчик, понимаю, что если не починим основание, колдовать над фичами по меньшей мере нерационально.Да я как раз понимаю необходимость чинить технику, инвестироватъ время в архитектуру итд. Я не понимаю, какие претензии могут быть о мне как к ПО, если в результате фичи продукта имплементируются очень медленно. Если мне выдали машину, которая ездит с максимально 50 ...

(1) Скраммастер зато у нас золото. И парень хороший, и в проекте не замешан (то есть реально беспристрастный), и сам из разработчиков, и опыт немалый (хоть и не в скраме). Уверена, что со своей ролью он справится. И да, ещё один плюс - команда дружная и сработанная, лёгкое и открытое общение должно помочь нам пережить это недоразумение, как скрам)))Ну это уже очень классно. В нашей расстановке меня бесит скраммастер, ведущий себя как гуру и шеф, но не понимающий ничего в теме.При этом роль ПО почему-то поделили на две части (не, в теории оно неплохо, в нашей реальности сейчас совсем лишнее), ...

(1) Роли все важные.Но естественно ПО определяет тематическое развитие продукта. Этими задачами в порядке приоризации он и наполняет бэклог. ...

(1) Господи, как маленькие дети. Полюбовно-то нельзя вопрос решить, создав процесс в котором учитываются все мнения? Приоритетность задач знает только ПО, взаимосвязи между задачами - команда. Дело СМ - вообще десятое.Конкретно у нас проблема в том, что на команду падают дополнительные технические задания. Например какие-то техические расширения типа необходимости подстроиться по дновые типы баз данных, облак итд. Или какая-то копмпонента перестала справлятъся с нагрузкой. Или какую-то аркитектуру сделали по-простому на скорую руку, а теперь она вызывает проблемы, и все надо переделывать. И все ...

(1) А что тогда ПО решает, если не вопрос что делать?Типа, ПО наполняет бэклог, а что оттуда взять в спринт, решает команда ...

(1) Не знаю, мне понятно желание иметь "свой код", чтобы никто кроме тебя в нем никто ничего не мастерил. И чтобы иметь возможность нести полную ответственность за него и пронимать решения. ...

(1) 1. Скрам-мастер - это обслуга. Его должно быть как хорошего официанта не видно и не слышно, но при этом он должен возникать из небытия при первой же организационной проблеме и решать её.Мечта! Но обычно такие типы не любят держаться в тени. Codeownership и не должно быть, но при наличии специализаций их надо просто учитывать при планировании. В итоге мы планировали достаточное количество пунктов для бекенда, фронтенда, и для меня отдельно, если были сложные темы.Мне кажется, чем лучше специалист, тем меньше ему нравится метаться между отдельными карточками, а хочется заниматъся своим прое ...

(1) Нет, я тоже замечаю что немцы те ещё терпилы. Я сам вежливо обясняю, что уважаемая мастерица, ты несёшь херню, я буду делать так как правильно, а не как ты придумала. Она "сложила уши" очень быстроВот у нас я единственная не-терпила, но толку малоНо только скрам не должен касаться принципиальных продуктовых вопросов.Но только скрам не должен касаться принципиальных продуктовых вопросов.Например по скраму ПО не имеет права решать, какие войдут в спринт, а какие нет. А это принципиальный вопрос ...

(1) 1,2 - все так. Прошли это лет 5-10 назад. Нанимается скрам-мастер за кучу денег, который создаёт видимость бурной деятельности, генерит кучу бесполезных митингов и всем мешает. В итоге через примерно год этой суеты руководство понимает, что лучше не стало, и от него избавляются.Эх, хорошо бы. Часто сначала уходят все полезные люди, прежде чем всем станет ясно, что от бесполезных людей и процессов надо избавляться ...

(1) Я видел скрам-мастерицу, после курсиков-шмурсиков, облающая нулевыми знаниями в ИТ и в people management, возомнила себя начальницей. Пыталась командовать закалёнными в боях ИТ-шниками, в т.ч. с 15-ти летним опытом. Пришлось ставить на место. Но допускаю, что встречаются мастера и поумнее.Речь о немцах? Давно я не видела немцев, ставящих кого-то, кто это заслужил, на место. У нас матерые специалисты сидят и молчат в ответ на произвол скрам-публикМногое зависит от product owner, он должен быть лидером, а скрам-мастер как помощник без лишнего гонора.Скрам-мастер аргументирует правилами скрам ...

(1) Я тут собрала негативные отзывы про скрам, что скажете?:1. Скрам-менеджеры, которые закончила трехнедельные курсы и мнят себя гуру, при этом не в курсе специфики разработки и не интересуются судьбой продукта, а пытаются укрепить свое влияние.2. Ритуалы как самоцель - митинги как например ретро, где каждый должен что-то сказать, даже если по сути ему сказать нечего, и поэтому изрекает что-то вроде "мне понравилась взаимопомощь в команде и не понравилась гетерогенность команды". А потом скрам-мастер важно зачитывает с листочка все эти реплики.3. Искусственные деадлайны (конец спринта), ...