ли скрам при внедрении крупной системы где заранее известны все требования к ней?
2. Следовательно, возможен ли гибридный скрам или скрам наполовину? (Понятно что это будет не скрам но останется ли эффективность)
3. Ну и совсем частный вопрос. Представитель бизнеса хочет посещать утренний Daily Scrum. Был ли у вас такой опыт, это было хорошо или плохо?
1) нет, но так чтобы при крупной системе прям все требования были известны, это редкость. Они точно не поменяются ни на сколько? 2) нет 3) плохо, для него другой митинг есть. Тем более если все требования известны уже
Даже если не все требования известны, то их все равно проще прояснит запустив пилотный проект и сделав майлстоуны по внедрению. Внедряем на один департамент, документируем, внедряем везде. Создаём селф-сервис и тд. Вы уедите куда дальше, наняв толкового прожект, менеджера, а не скрам мастера.
Спасибо за ответ. Что остальные думают? Если согласны с уже написанным мнением, поставьте ему лайк)
насчёт 2 и 3 соглашусь с ответом
2) Некоторая разновидность гибрида возможна. Например, рассматривать прописанные требования как минимальные, и самые приоритетные задачи. Оставить воздушную подушку на возможность того, что заказчик или внешняя среда "передумают". 3) daily нужен для разработчиков, чтобы синхронизироваться по работе спринта между собой. Заказчикам и всяческим руководителям лучше бы не ходить. Обычно они так хотят контролировать. А это мешает самоорганизации и самоуправлению команды
1. можно , но скорее всего будет экономически неэффективно. 2. Если выполнены все требования то почему бы и не быть ему скрамом.зачастую для улучшения бывает достаточно завезти ценности из скрама и навести прозрачность - а остальное менее важно. 3. В режиме read only может. Это может быть индикатором низкой прозрачности либо слишком большой тревожности у стейкхолдера. Это лечится но не быстро. В плохой реализации скрама - остаётся на всегда да ещё и пытается рулить командой превращая Дейли в Статусный отчет
3. Поэтому кмк такие вещи надо рубить на корню. Посторонним там не место
Скрам вообще не нужен, но полезен. Если требования 100% известны заранее, польза будет от итеративной поставки готовых к использованию частей решения. Гибридный скрам - не скрам. Это не значит, что не получится его элементы использовать, просто целиком скрам эффективней будет (даже если требования на 100% предопределены). Если команда не против - пусть посещает. Вопрос в том, какая у него цель: дейли это локальный тактический митинг и сильно много информации от присутствия там не члену команды обычно не получить. Прозрачность происходящего можно по другому обеспечить.
Смотря от кого. Если от пользователей, то лишь после первого релиза. Если от стейков/зауазчиков, то после того момента, как им что-то показали. В случае, когда требования определены, показывать что-то в середине, кроме прототипов гуя, смысла немного и мало кто этим заморачивается.
Не показывать - это один из методов игнорировать обратную связь. Big Bang релизы, огромные пакеты, куча незавершёнка в производстве. С точки зрения _проекта_ - нормально, с точки зрения _решения_ и экономики предприятия/заказчика - так себе. Другое дело, что с обратной связью надо уметь работать, это не всегда комфортно, проще избегать и делать вид, что обратной связи не будет и в е идёт по плану.
Обсуждают сегодня