коллективная ответственность складывается из личной ответственности членов команды. и не нужно забывать, что в компаниях отсутствуют бонусы за колективный вклад в работу. так что на словал менеджеры декларируют командную работу, а по факту — работает группа разработчиков. с постоянной текучкой, по другому и не получиться.
задача уже давно могла пройти DoD. а при наличии какой-нибудь новой задачи может потребоваться пересмотреть ее решение. в таком случае PO не поможет. нужна техническая экспертиза, и решение каким образом реализация новой задачи должна повлиять на текущую имплементацию.
например, задачу можно сделать за 1 неделю, но тех лид советует потратить 1-2 недели на рефакторинг существующего кода, а потом приступить к реализации задачи. PO как правило выбирают первый вариант.
у скрама есть 2 проблемы:
1. постоянные дедлайны.
как результат — постоянный стресс в разработке. менеджеры предпочитают игнорировать этот момент, как несущественный. как по мне, многие выгорания в среде разработчиков происходят, по этой причине.
2. сертифицированные скрам-мастера. встречаются достаточно агрессивные поборники скрама, слепо следующие канонам учения. при этом слабо понимающие почему скрам предписывает что-то делать. и даже не догадываются, что еще много чего в скраме просто не описано. постоянный пушшинг разработчиков. давай, давай, давай. манипуляции.
по первому пункту я бы советовал разработчикам работать над снижением личной ответственности и лучше планировать задачи на спринт. например, веделять неделю на бизнес задачи, неделю — на ревью и исправление реализованой части.
второй пункт исправить не возможно.
чего мне в скраме не хватает, так это Tech Owner-ра. который мог бы корректировать разработку с технической стороны. кто-то пытается это делать, но как правило на уровне Team Lead/Tech Lead/Architect.
splatt похоже тебя сертифицированные скрам-мастера не понимают о чем ты спрашиваешь. думают что это само-собой как-то делается. или добавим 2 ревьювера на один PR и этого достаточно.
лично мне приходилось отвечать за данные вопросы, но опять же по личной инициативе.
либо все уйдет в тех долг, который не известно, кто и когда будет разгребать.
задача уже давно могла пройти DoD. а при наличии какой-нибудь новой задачи может потребоваться пересмотреть ее решение. в таком случае PO не поможет. нужна техническая экспертиза, и решение каким образом реализация новой задачи должна повлиять на текущую имплементацию.
например, задачу можно сделать за 1 неделю, но тех лид советует потратить 1-2 недели на рефакторинг существующего кода, а потом приступить к реализации задачи. PO как правило выбирают первый вариант.
1. постоянные дедлайны.
как результат — постоянный стресс в разработке. менеджеры предпочитают игнорировать этот момент, как несущественный. как по мне, многие выгорания в среде разработчиков происходят, по этой причине.
2. сертифицированные скрам-мастера. встречаются достаточно агрессивные поборники скрама, слепо следующие канонам учения. при этом слабо понимающие почему скрам предписывает что-то делать. и даже не догадываются, что еще много чего в скраме просто не описано. постоянный пушшинг разработчиков. давай, давай, давай. манипуляции.
по первому пункту я бы советовал разработчикам работать над снижением личной ответственности и лучше планировать задачи на спринт. например, веделять неделю на бизнес задачи, неделю — на ревью и исправление реализованой части.
второй пункт исправить не возможно.
чего мне в скраме не хватает, так это Tech Owner-ра. который мог бы корректировать разработку с технической стороны. кто-то пытается это делать, но как правило на уровне Team Lead/Tech Lead/Architect.
лично мне приходилось отвечать за данные вопросы, но опять же по личной инициативе.