Post #1892

Частые ошибки в работе с бэклогом В теоретической идеальной системе никакой продуктовый бэклог не нужен – каждый программист и сам знает, какую самую большую пользовательскую проблему надо решить следующей. Несовершенство человеческих коммуникаций и другие проблемы реальной жизни ведут к тому, что появляются дополнительные процессы и артефакты, которые понижают риск потери информации при передаче ее от пользователя к программисту, в том числе продуктовый бэклог и разные танцы вокруг него. Они часто необходимы, но важно помнить, что сам по себе продуктовый бэклог ценности никакой не приносит, поэтому вам нужно стремиться к тому, чтобы уменьшать время на работу с ним, а не увеличивать. Так вот, держите несколько конкретных антипаттернов, которые показывают, что вы сбились с пути: 👉Бэклог-вишлист, куда вы просто включаете хотелки всех, кто приходит к вашей команде, вместо того, чтобы держать там задачи с понятной ценностью. 👉Вы пытаетесь идеально описывать все юзер-стори – и на груминге вместо обсуждения проблемы пользователя закапываетесь в детали реализации вроде критериев приемки и оценки сроков. 👉У вас несколько бэклогов вместо одного – например, один для фичей, другой для техдолга. 👉Права создавать или менять что-то в бэклоге есть только у одного человека, который в итоге становится бутылочным горлышком. 👉Перед тем, как приступить к решению новой пользовательской проблемы, вы заранее все планируете и создаете десятки задач, вместо того, чтобы принять неизвестность и быть готовыми менять требования на ходу. 👉Возраст самых старых тикетов насчитывает годы. 👉Бэклог формируется вокруг фичей, а не вокруг проблем, которые надо решить.