DG
Для таких случаев как раз со стороны лучше. Если от него многого не ждут.
Size: a a a
2021 April 11
DG
PO приходят и уходят, а команда едет дальше.
PD
Эталонных паттернов быть не может, это сразу каргокульт получится.
Но тут можно взять любой пункт, подумать над тем, какие задачи он решает и нельзя ли эти задачи решить эффективнее. И переделать процесс.
Если команда не видит проблем в текущем процессе - значит надо перестаь поощрять ее глупости и нанять лида, наконец.
Но тут можно взять любой пункт, подумать над тем, какие задачи он решает и нельзя ли эти задачи решить эффективнее. И переделать процесс.
Если команда не видит проблем в текущем процессе - значит надо перестаь поощрять ее глупости и нанять лида, наконец.
DG
Тут некоторое описание нашего Scrum процесса, которому мы следуем.
Мы плохо делаем Scrum или Scrum по определению плохо?
Можешь на примере одного любого пункта рассказать?
Мы плохо делаем Scrum или Scrum по определению плохо?
Можешь на примере одного любого пункта рассказать?
АВ
Компания говорит - мы набираем сильных разработчиков которые смогут работать без начальника и самоорганизовыватся.
Команда говорит - нам нужен тимлид а то мы не справляемся.
Команда говорит - нам нужен тимлид а то мы не справляемся.
PD
Скрам обычно плохо. У вас, судя по симптомам, очень средние разработчики, о сильных даже близко речь не идёт
DG
Команда такого не говорит. Есть проблема, с которой возможно кто-то уже сталкивался, в примерных условиях. Может быть у кого-то были успешные решения и он готов ими поделиться.
ЕК
Я если честно тоже не понял что не так в общем и целом. И то что скрам обычно плохо - сильноя заявление.
АВ
Ну так тут чат тим.лидов просто.
ЕК
Тоже не понятно почему скрам обычно плохо.
АВ
Тим.лида нет
ЕК
Ну ок, кто мешает изменить процессы и выбрать? Скрам чисто по книжке - плохо 100%.
Люди и взаимодействие важнее процессов и инструментовAS
Не тимлида нет
АВ
С меня пиво, я в СПб обитаю
АВ
Адаптации ещё чаще скрамно
ЕК
Как раз наоборот. В моем представлении скрам дает набор инструментариев, которые хорошо бы знать каждый отдельно и как они работают между собой.
ЕК
Но выстраивать процессы исходя и специфики проекта и команды.
П
Скрам по книжке про агил?
AS
Есть очень грубо 3 части команды: требования, ядро и фронт (вместе с беком) примерно раз в 2 я с продактом и аналитиком сажусь и смотрим в роадмап что мы «берем в релиз» на эти 2 месяца. По факту это уточнение «а точно топ роадмапа еще актуален или приоритеты поменялись»
DG
Ничто не мешает. Но команда не хочет. Как раз при найме PO, бывшего PM сразу были поставлены границы, что PM нам не нужен. С тим.лидом примерно такая же ситуация. Чем он поможет?