Так команда вполне может самоорганизоваться, а бизнес, руководство требует именно скрам, требует соблюдения ритуалов, плюсики вон ставят выполнил или нет очередной пункт ритуала, может даже премии дают по количеству плюсиков ).
. А смысл моего первоначального сообщения был в том, что о таких проблемах, когда они возникают, надо сразу говорить человеку, отвечающему за выпуск продукта, а не ждать митингов.
Мне кажется, это вообще не является проблемой.
Если бэк не успел что-то сделать, ты сказал, что у тебя все готово, и ты сможешь заменить фейковые данные на реальные, как только бэк доделает на своей стороне — молодец, именно это и можно озвучить на ежедневном стендапе.
А ты пока можешь сделать что-то еще полезное для себя или для продукта.
Владелец продукта — владелец продукта, он генерируют задачи для улучшения своего продукта. Менеджер, в моем понимании, непосредственный руководитель сотрудников. Я таковым не являюсь.
Видимо, у вас какой-то другой, негативный пример работы с ПО.
Можете поделиться?
Как-то обидно из владельца продукта превратиться в менеджера.
Тогда ответ такой, если команда взяла задачу в спринт — ее реализация является «головной болью» всей команды, в т.ч. и продукт оунера.
Если что-то не готово по задаче, то зачем брать ее в спринт?
Я думал больше проблем чем у нас не бывает :)
Подскажите, пожалуйста, зачем и как у вас началось внедрение Скрама?
Кажется, что основная проблема в том, что это было решение сверху, сотрудники его не приняли, а внедрение проходило без соответствующего сопровождения, в связи с чем накопилось много проблем, которые никто не решает и решать не хочет.
Я могу ошибаться, но сейчас картина выглядит именно так.
На сколько я помню, как основной минус объединения ролей там приводиться в пример, что продукт оунер более заинтересован в качестве, а скрам-мастер в сроках. У меня же физически не хватало времени (и/или опыта). Конфликта интересов не было.
Про скрам ради скрама — не соглашусь, если правильно выстроены процессы CI/CD вполне себе рабочая схема. Сами пока не пробовали, но у коллег из Альфа-банка неплохо получается.
Про объединение, тут надо понимать, что у тим лида тоже есть свои интересы, kpi и т.п. а скрам-мастер в первую очередь слуга самого процесса.
Стендапы нужны, чтобы синхронизировать работу команды, не все изменения видны в гите, и не все заводится в джире, созвониться проще и быстрее. И не надо забывать о ламповости таких мероприятий, живое общение тоже нужно, оно помогает поддерживать командный дух, тем более если не вся команда работает в одном офисе / городе.
«при возникновении таких проблем, их надо сразу говорить менеджеру, чтоб это становилось его головной болью и он пинал всех причастных.» — у нас другой подход, стараемся все вопросы решать сами, без привлечения руководителей.
Рад, что вас зацепило :)
Да, мы еще на пути к Scrum, нельзя сказать, что процесс трансформации завершился.
Неужели разработчик не помнит, что он делал вчера, и что будет делать сегодня?
У нас ребята к стендапам не готовятся.
Мне кажется, это вообще не является проблемой.
Если бэк не успел что-то сделать, ты сказал, что у тебя все готово, и ты сможешь заменить фейковые данные на реальные, как только бэк доделает на своей стороне — молодец, именно это и можно озвучить на ежедневном стендапе.
А ты пока можешь сделать что-то еще полезное для себя или для продукта.
Видимо, у вас какой-то другой, негативный пример работы с ПО.
Можете поделиться?
Тогда ответ такой, если команда взяла задачу в спринт — ее реализация является «головной болью» всей команды, в т.ч. и продукт оунера.
Если что-то не готово по задаче, то зачем брать ее в спринт?
Подскажите, пожалуйста, зачем и как у вас началось внедрение Скрама?
Кажется, что основная проблема в том, что это было решение сверху, сотрудники его не приняли, а внедрение проходило без соответствующего сопровождения, в связи с чем накопилось много проблем, которые никто не решает и решать не хочет.
Я могу ошибаться, но сейчас картина выглядит именно так.
У нас в Банке только ДБО. Хотя может кто-то скрывает :)
Пока нет, но мы стараемся.
Про объединение, тут надо понимать, что у тим лида тоже есть свои интересы, kpi и т.п. а скрам-мастер в первую очередь слуга самого процесса.
Стендапы нужны, чтобы синхронизировать работу команды, не все изменения видны в гите, и не все заводится в джире, созвониться проще и быстрее. И не надо забывать о ламповости таких мероприятий, живое общение тоже нужно, оно помогает поддерживать командный дух, тем более если не вся команда работает в одном офисе / городе.
«при возникновении таких проблем, их надо сразу говорить менеджеру, чтоб это становилось его головной болью и он пинал всех причастных.» — у нас другой подход, стараемся все вопросы решать сами, без привлечения руководителей.