Ну это правда жизни такая) аджайл аджайлом, но ближе к реальности быть полезно. Иначе появляются рассуждения, а что если команда задачи брать не хочет или ещё что-то. Если не хочет, значит связь с реальностью потеряна, и пора ее вернуть.

Привет Коллеги, посоветуйте какую-нибудь методологию или фреймворк для описания инициативы или пилотного проекта Например, планируем внедрение SAFe и хочется оценить возможности, риски итп. SWOT не подходит, т.к. здесь нет "внешней среды", конкурентов итп.

Так-то я могу просто текст нафигачить, но был бы фреймворк, который подскажет "учти это, не забудь это.." - было бы здорово Как lean canvas, например, только не для внешней рыночной инициативы, а внутренней командной

Как вы оцениваете применимость эджайл к fixed scope/fixed budget проектам?

Если брать scrum, то scrum-команда в принципе имеет полное право не брать PBI в бэклог. Финальное решение по содержимому бэклога и приоритетам принимает PO, который является частью scrum-команды. Если вам не нравится такой подход и вы считаете его неправильным и отрывом от реальности - лучше не используйте scrum :) Без автономии PO в частонсти и scrum-team в целом получается... плохо.

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

Привет Коллеги, посоветуйте какую-нибудь методологию или фреймворк для описания инициативы или пилотного проекта Например, планируем внедрение SAFe и хочется оценить возможности, риски итп. SWOT не подходит, т.к. здесь нет "внешней среды", конкурентов итп.

Только мнение: пообщаться не со всей командой сразу, а с каждым отдельно, минут по 20, что бы понять ситуацию изнутри. Может быть за вотерфлоу всего 1-2 особо активных коллеги, которые убедили других. А может - реально есть проблемы - и скрам в чистом виде их не решает в данном случае (а может еще и мешает), тогда нужно понять изнутри почему вотерфлоу кажется более привлекательным решением, и адаптировать скрам под потребности коллег

Скрам ведь не ставит цели внедрять его полностью без изменений - Agile призывает адаптировать инструменты и методологии под особенности проекта и команды.

А что можно изменить в скрам?

Слишком абстактный вопрос. Если есть проблема - нужно понять причину и искать уже возможные решения на основе нее. Волшебных таблеток не бывает.

Коллеги, доброго времени суток. Хочу услышать ваше мнение. Что если скрам команда на одной из ретроспектив приходит к мнению, что она (команда) хочет вотерфол, но при этом открыто это не признает, пытаясь удержаться за скрам (т.к. их наняли на скрам-проект и заказчик хочет именно скрам)? Ключевой признак, что команда хочет вотерфол (я сильно обобщаю, но посыл должен быть ясен): «дайте нам детальный vision, все бизнес-процессы, все роли, архитектуру и взаимосвязи - все сразу, иначе мы не можем сделать нормальный солюшен, и переделывать не хотим». И что в такой ситуации делать бизнес-аналитику, который вроде как считается частью дев команды, но по сути исполняет роль прокси-РО в данном конкретном случае? Моя вселенная что-то схлопывается в сингулярность от такого расклада. Может я чего-то не понимаю?

Больше общение. Факт: команду не устраивает скрам в том виде, в котором есть в компании. Более того - она боится это озвучить. 1. Открыто признать тот факт, что команду не устраивает текущая реализация скрам, и нужны изменения 2. Пообщаться с каждым лично - узнать что именно его не устраивает, с какими проблемами сталкивается. Может реально просто руководство только создает имитацию скрама? Или в проекте цена ошибки слишком велика, и там реально больше Waterflow подходит? Или еще что? 3. Проанализировать ситуацию после общения, и совместно договориться о том как работать дальше, что бы всех это плюс/минус устраивало. 3. Если разрабы просто привыкли по вотерфлоу работать, они берут ответственность только за код все остальное спихивая на менеджера, и им удобнее работать с ТЗ, чем принесенная польза - не пожалеть времени на то что бы до каждого лично донести манифест Agile. Скрам можно внедрять сколько угодно - но пока мышление не изменится, это остается только имитацией скрама. Так что - больше общаться. Прийти к плюс/минус общим ценностям, услышать разработчиков и что у них болит, и искать решение совместно.

Скрам ведь не ставит цели внедрять его полностью без изменений - Agile призывает адаптировать инструменты и методологии под особенности проекта и команды.

Доброе утро, хочу заметить, что Scrum не мутабельный инструмент. Т.е. из него нельзя ничего убирать или изменять. Это уже не Scrum будет, и изменить скрам под реальность мы всегда успеем. Кстати, подскажите, где в манифесте написно про изменение и адаптацию методологий под особенности проекта?

Доброе утро, хочу заметить, что Scrum не мутабельный инструмент. Т.е. из него нельзя ничего убирать или изменять. Это уже не Scrum будет, и изменить скрам под реальность мы всегда успеем. Кстати, подскажите, где в манифесте написно про изменение и адаптацию методологий под особенности проекта?

И если она идеально не вписывается в уже устоявшиеся процессы в компании и команды - то она может больше вредить, чем мешать

Что бы Вы добавили в данном кейсе или убрали?

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

Леонид, ответь тогда ты на этот же вопрос.

Может тогда мы лучше друг друга поймем)

Спасибо) А как заставить команду изменить мышление? Какая у нее мотивация к изменениям?

Как ее вовлечь, если у нее нет мотивации такой?

Что понимается под изменяющимся фактором?