Комментарии 6
Как ни странно, но кроме предсказуемости бизнес ещё волнует и скорость разработки/доставки. Можно очень сильно перезакладываться в оценках и иметь очень высокую предсказуемость, но бизнес от этого вряд ли будет счастлив.
Ну и не раскрыта тема, как без багов можно управлять качеством продуктов.
Привет, спасибо за хороший комментарий.
Отвечу по порядку, постараюсь кратко, ответ тянет на еще два лонгрида
Бизнес ещё волнует и скорость разработки/доставки. Можно очень сильно перезакладываться в оценках и иметь очень высокую предсказуемость, но бизнес от этого вряд ли будет счастлив.
Перед стартом планирования Бизнес формирует Бизнес-контекст (Business Context) — это часть повестки PI-планирования, когда Бизнеса рассказывают о текущем состоянии бизнеса, и говорят что нужно сделать в этом квартале чтобы бизнес рос.
Если его интересует высокая скорость доставки, но срочно сделать MVP чтобы договор подписать, он об этом скажет. Если нужно небыстро но с супер качеством - тоже. И это круто, потому что каждый сотрудник видит Бизнес-контекст.
Одна из целей PI - планирования - покрыть задачи бизнес-контекста. Если он покрыт, вопросов к командам быть не должно
Перед PI планированием команда проводит PBR (Product Backlog Refinement)
На PBR команда в присутствии PM (Product Manager), SA (System Architect), SH (Stake Holders), показывает свою емкость, и на какие фичи эта емкость будет потрачена. Они подскажут команде, если будет видно где команда перезакладывается в оценках.
не раскрыта тема, как без багов можно управлять качеством продуктов
Без багов найденных тестировщиком?
Есть, как минимум, Предсказуемость, Внешние дефекты (только не надо их ни на что делить) и Лояльность пользователей. Это хорошие цифры для анализа.
Спасибо за ответы!
С моей точки зрения, велосити команды - это компенсирующая метрика для предсказуемости, а не цель какого-то спринта.
Внешние дефекты и лояльность пользователей (выраженная через nps, csat) - это запаздывающие метрики. А управление качеством, по моему мнению, должно базироваться на упреждающих. Как выразился один из моих руководителей: I wish I never released this shit. Но фарш обратно не прокрутить...
Если так реагировать на процессы и на тестировщика, который 'о боги' делает свою работу, то вообще не стоит работать, метрики по багам в целом полезны, позволяют оценить в целом продуктивность, bottlenecks, качество и прочее. На проде НЕ должно быть критических багов, поэтому их искать нужно ДО
Привет, спасибо за комментарий.
Если так реагировать на процессы и на тестировщика, который 'о боги' делает свою работу, то вообще не стоит работать, метрики по багам в целом полезны, позволяют оценить в целом продуктивность, bottlenecks, качество и прочее
Я хочу чтобы мы сконцентрировались на качественных процессах команды в целом, потому что в SAFe за качество отвечает вся команда. И нет никакой разницы как они трекают дефекты тестера - могут на дейли обсудить и поправить сразу, а на ретро обсудить и принять здравые решения "кто виноват и что делать". Кому нужна эта информация за пределами команды?
На проде НЕ должно быть критических багов, поэтому их искать нужно ДО
С этим я не спорю
Статистика багов, найденных тестером, не нужна. SAFe predictability