«Оседлать хаос»: Как 1000+ инженеров повысили сходимость бэклога до 95%. Часть 2
100 команд. Это 1000 инженеров, которые ежедневно развитивают 90 продуктов и сервисов интернет-банка. У каждой команды свои амбиции и насмотренность, своя скорость и опыт. Все они вместе генерируют более 7000 релизов в год. Это полный хаос, но мы смогли его оседлать и синхронизировать работу команды. В этой статье я хочу рассказать вам о производст…
Про Discovery бы подробнее узнать, а то эта стадия напоминает waterfall с железобетонным планом и последующей реализацией скрамовскими итерациями.
Что в Discovery стадии и как у вас работает, если, по вашим словам, на этапе реализации не приходится от слова совсем возвращаться назад и вносить коррективы? Или коррективы все-таки вносятся в Discovery части, но на этапе Scrum?
Какие метрики, по каждому из этапов, вы используете, как измеряете, где фиксируете?
Discovery - это элемент проектирования продукта (создание образа и требований), waterfall - это подход к реализации. Мне сложно между ними поставить равенство. Сейчас модно хейтить waterfall, но по факту все большие продукты создаются по модели waterfall. Всегда есть план, зависимости, сроки, бюджеты и ресурсы. Проект в котором участвует 50 команд, это 500 инженеров, без четкого образа результата никогда не будет запущен :))
А коррективы всегда есть, даже если провести эталонный discovery, то все равно по ходу реализации выплывет много нюансов, которые в рамках итеративной разработки можно поправить. По метрикам все очень просто: есть продуктовые метрики, у каждого продукта они свои, есть управленческие, это сходимость бэклога, количество багов, nps/csi. Есть отдельные метрики самого производственного процесса: capacity, velocity. Это насколько эффективно конкретная команда производит ценность. Все это в живет в jira или bi.