Здравствуйте, _ABC_, Вы писали:


P>>Подробнее. Вот завтра, скажем, у юзеров нашего апи упадёт стейджинг. А может не завтра, а в четверг. А может и не упадёт. Вопрос — как мне это занести в баклог?
_AB>Никак. "У юзеров" — это не часть проекта. Это эксплуатация. Решается в рамках операционной деятельности, SLA и т.д. и т.п.

Откуда SLA возьмется на стейджинге?

_AB>Ты же, вроде, говорил о создании того, что никто раньше не делал? Откуда юзеры взялись?

Я процитирую чуть выше, вы говорили про багфикс. Я вам про него и ответил

Не столько сам багфикс, а разновидности суппорта, траблшутинга, и прочие всевозможные срочные активности. Т.е. когда тикеты нужно фиксить сразу по мере их появления. Здесь нечего пихнуть в спринт — баклог пустой. Завтра уже чтото появится, и завтра его снова выкачаем досуха. В понедельник все что знаем, это что будет тикетов от 1 до N.

А если багфикс не срочный, скажем, с выдержкой в пару месяцев, то разницы с фичами особо никакой нет, аномалии выстреливают довольно редко. Накидал в спринт десятка два тикетов, из них закрыл 15, остальные передвинулись в следующий спринт, и сверх этого вылезло три срочных бага. В таком варианте скрам вполне себе работает.

Упал стейджинг — срочная активность, т.к. и девелоперы, и тестировщики, и даже кучка юзеров в превью — все заблокированы.

Если у вас только такие срочные активности, то непонятно, что в планирование спринта выносить. И разницы нет, багфикс это, траблшутинг, суппорт или еще чего.

А если не срочно, то можно и траблшутинг отложить на время. Тогда можно и спринты, и снова не важно, что это — багфикс, траблшутинг, суппорт.

То есть, скрамать вы можете в том случае, когда доля срочных задач и прочей операционной деятельности невысока, и цель спринта достижима и это условие не ломается.