Автор перевода Толкачёва Валерия, Scrum Master (Telegram: @Val1eriya)
…Scrum Team регулярно создает инкременты продукта. На порядок элементов в Product Backlog влияет множество факторов, которые команда может не до конца понимать при определении этого порядка. Например, Development Team не знает точного объема работы, необходимого для завершения Product Backlog Item (PBI), пока не закончит его. Кроме того, Product Owner не может точно определить, какую ценность создаст новый Product Backlog Item за время своего существования.
✥ ✥ ✥
Большие идеи - это здорово, но дьявол кроется в деталях.
Очень легко генерировать грандиозные идеи и использовать их для составления Product Backlog. Грандиозные идеи имеют свое место в Скраме (в виде Vision) и, в некоторой степени, в Product Backlog (Granularity Gradient). Однако всей команде сложно точно сформировать представление о крупных Product Backlog Item, что может ограничить способность Product Owner представлять их Developers в качестве функциональной спецификации (Enabling Specification). Ключевым фактором для успешной совместной работы Product Owner и Development Team является коммуникация и взаимопонимание. Product Backlog - это связующее звено для этой работы, поэтому он должен состоять из элементов, которые способствуют коммуникации и формированию общего понимания.
Независимо от того, содержит ли крупный элемент слишком много информации или, наоборот, слишком мало деталей, он несет в себе высокий риск. Если элемент представляет собой масштабную, но расплывчатую идею, успешная реализация практически невозможна, что может привести к бесконечным переделкам со стороны Development Team. Это, очевидно, пустая трата времени и ресурсов. Если же крупный элемент содержит много информации (например, сценариев или критериев приемки), Development Team рискует не завершить работу по всем указанным требованиям в течение Sprint. С этими ситуациями часто сталкиваются Scrum Team. Development Team может испытывать “информационный голод”, если взаимодействует с Product Owner слишком редко или поверхностно. Обстоятельства могут вынудить Development Team действовать “на авось”, полагаясь на ту информацию, которая у них есть.
Увеличение размера рабочих элементов увеличивает разброс и ошибки в их оценках. По определению, оценка - это предположение, поэтому она несовершенна. Мы знаем, что при измерении чего-либо полученный результат представляет собой комбинацию фактического значения и некоторой величины погрешности. В случае с оценками, можно ожидать, что составляющая погрешности будет большой и сильно различаться для разных элементов. Если эта погрешность составляет 20 процентов (что, вероятно, является относительно небольшим значением), то для большого элемента эта погрешность пропорционально больше, чем для маленького. Например, оценка большого элемента в 20 дней имеет погрешность в 4 дня, тогда как оценка меньшего элемента в 5 дней имеет погрешность всего в 1 день. Маловероятно, что погрешность оценки будет одинаковой для больших и маленьких элементов или для любых двух элементов в Product Backlog или Sprint Backlog. Как было сказано выше, разработчикам сложнее досконально разобраться в более крупных элементах, что может привести к большей процентной погрешности в оценке. Если мы суммируем оценки по всему Product Backlog (для Release Plan), то мы складываем эти погрешности вместе. Всегда можно исправить это с помощью какой-либо “подушки безопасности” или других непредвиденных обстоятельств, а также усложнить режим оценки, чтобы снизить риск срыва сроков - за счет точности. Возможно, лучшим подходом будет выпустить новую версию продукта, вместо того, чтобы тратить все время на планирование.
Обратная связь является неотъемлемой частью Скрама; Sprint Review - это официальная возможность для Scrum Team получить обратную связь о ходе разработки продукта. Sprint Review наиболее эффективен для получения такой обратной связи, когда существует потенциально готовый к выпуску Product Increment. Работа с крупными элементами может ограничить возможность Development Team завершить этот Product Increment, в результате чего Scrum Team нечего будет обозревать. Это существенно ограничивает обратную связь, которая является жизненной силой гибкой команды, поскольку продукт находится в состоянии между планированием и поставкой в подвешенном состоянии. Более того, помимо обратной связи, такое состояние не дает никакой прозрачности в отношении прогресса, поскольку Scrum Team не может точно знать, где находится продукт по отношению к Product Backlog или Roadmap; его положение остается лишь догадкой до момента развертывания.
Привычка накапливать работу или защищать свою способность ее выполнять, может быть сильной и трудно изменяемой во многих организационных культурах. Такие культуры могут не видеть пользы в усилиях по созданию более мелких Product Backlog Item (SBI). Если Development Team создает SBI, которые настолько велики, что каждый из них занимает много дней для выполнения в течение Sprint, Daily Scrum превращается в бессмысленный ритуал. Без видимого прогресса или изменений в направлении, Daily Scrum с таким же успехом может стать ежедневными коллективными объятиями, за исключением того, что объятия, возможно, были бы лучшим использованием времени.
Когда команде не удается поставить элементы Бэклога спринта (довести их до состояния “Готово”: см. Definition of Done), даже если команда “почти закончила”, ей будет сложно достичь Sprint Goal и предоставить ценность. Команда обнаруживает, что небольшие незавершенные элементы имеют серьезные последствия. Этот симптом чаще всего указывает на более глубокую проблему - непонимание элементов Бэклога продукта (PBI) и элементов Бэклога спринта (SBI) командой. Scrum Team может не понимать масштаб необходимой работы или связанные с ней риски. Кроме того, команда может не понимать сам PBI.
Команды обычно оценивают необходимую работу с точки зрения детального определения размеров отдельных задач. Однако Scrum Team нуждается в достаточно точных совокупных оценках для планирования релиза. Если команда не может полагаться на оценки, она не может полагаться на планы. Фактически, оценки являются показателем того, насколько хорошо Development Team понимает данный элемент: если оценки крайне неточны, это показатель того, что команда недостаточно хорошо понимает элемент. Неточно оцененный PBI может быть трудно упорядочивать с другими PBI, так как оценочная стоимость и возврат инвестиций (см. “Value and ROI”) отражают сочетание как коммерческой ценности, так и оценочных усилий, необходимых для поставки.
Крупные элементы по своей природе трудно понять, оценить и надежно поставить.
Поэтому:
Разбивайте работу на Small Items, которые являются шагами к реализации больших идей, чтобы Development Team могла овладеть пониманием каждого мелкого элемента в отдельности. Крупные элементы затрудняют понимание важных деталей, а непонимание приводит к неожиданностям. Команда может сократить количество неожиданностей в плане, используя в работе Small Items.
Мелкий элемент - это Product Backlog Item (PBI) или Sprint Backlog Item (SBI), который Development Team может легко понять и быстро (в случае PBI) довести до состояния “Готово”. “Быстро” для SBI означает в течение двух дней работы от начала до “Готово”; сроки произвольны и зависят от вашего горизонта планирования, но для надежной реализации этого паттерна рекомендуется максимум два дня. Хотя мы настоятельно рекомендуем использовать относительную оценку (см. “Estimation Points”) для PBI, а не оценку на основе времени, Development Team выработает представление о том, чего она может достичь за данный период времени; установка двухдневного лимита позволяет использовать этот опыт.
Оценка более мелких элементов выигрывает от закона больших чисел и лучше подходит для сложной и неопределенной работы, чем оценка сверху вниз. Эксперт по оценке Магне Йоргенсен рекомендует использовать оценку снизу вверх для новых проектов, разрабатываемых экспертами в данной области.
Декомпозиция элементов помогает нам понять зависимости между ними. Например, если у вас есть два элемента, которые зависят друг от друга, вы можете разложить каждый из них на более мелкие элементы, которые разорвут циклическую зависимость. Это может дать Product Owner больше свободы в упорядочивании Product Backlog, и может позволить более гибко упорядочивать SBI в Sprint.
Наличие небольших и более понятных элементов для оценки повысит общую точность и прецизионность оценки. Однако цель этого паттерна - не получение высокоточных оценок. Для того, чтобы процесс работал, нужно все равно играть в игру оценки: а именно понимать элемент достаточно хорошо, чтобы правильно его реализовать. Основной результат этого паттерна заключается в том, что члены команды тщательно понимают элементы, чтобы они могли сначала надежно их поставить, а затем улучшить прогнозирование. Совокупная оценка полезна при составлении Release Plan, а также во время Sprint Planning.
Нас больше интересуют комбинированные оценки элементов и тенденции во времени, чем оценки отдельных элементов.
Чтобы иметь Small Items, Scrum Team необходимо тратить больше времени на уточнение Product Backlog с повышенным вниманием к дизайну продукта. Как следствие, на оценку будет уходить меньше времени. Scrum Teams и организации, не знакомые со Скрамом, найдут это нервирующим, поскольку оценки, особенно стоимости, являются движущей силой традиционной практики разработки продуктов. С большим потоком, который может возникнуть при использовании Small Items, значительно снижается риск того, что Development Team не поставит PBI, и это стабилизирует стоимость (которая становится стоимостью Sprint), поэтому движущей силой разработки продукта должна быть ценность или результат для клиента, а не стоимость поставки. Это культурное изменение в разработке продукта, которое потребует поддержки для его реализации.
Разбиение больших PBI и SBI помогает разработчикам понять их, поскольку это обязательно включает в себя работу над дизайном. Small Items помогают команде повысить вероятность того, что она достигнет своего прогноза.
✥ ✥ ✥
Small Items в Product Backlog позволяют осуществлять более регулярную поставку и получать более качественную обратную связь о направлении развития продукта. Product Owner должен не только создавать возможности для изменения продукта с целью максимизации ценности, но и активно взаимодействовать со Scrum Team и продуктом, чтобы в полной мере воспользоваться преимуществами обратной связи. Этот уровень вовлеченности может потребовать от Product Owner поддержки Product Owner Team, чтобы покрыть весь необходимый объем работ, но преимущества этой ситуации должны явно перевешивать дополнительные расходы.
Использование Small Items в Sprint Backlog помогает сократить “утечку”, которая возникает в результате неспособности поставить какой-либо конкретный SBI. Использование Small Items в Product Backlog позволяет получить представление о PBI на более раннем этапе, чтобы команда могла довести его до состояния “Ready” (см. Definition of Ready), увеличивая шансы на то, что они станут действительно Enabling Specifications. Сосредоточьтесь на элементах верхней части Product Backlog, как описано в Granularity Gradient.
Некоторые команды, которые внедрили Small Items, обнаружили, что для управления большим количеством элементов в Product Backlog или Sprint Backlog требуется больше усилий. Granularity Gradient помогает решить эту проблему для PBI. В случае с SBI вина часто лежит на инструменте, который команды приняли для управления своим бэклогом. Использование стикеров для SBI вместо онлайн-инструмента, похоже, решает эту проблему с инструментом.
Джефф Сазерленд сообщает, что наблюдал значительное снижение количества Estimation Points (стори поинтов), поставленных по мере увеличения размера PBI.