Category

статья

Category

Definition of Ready (DoR) инструмент про который довольно сложно найти информацию в интернете. Строго говоря в Скрам Гайде нет такого термина или описания этого инструмента. Однако если обратиться к Scrum Glossary то можно найти такой термин как Ready.

Ready: a shared understanding by the Product Owner and the Developers regarding the preferred level of description of Product Backlog items introduced at Sprint Planning

Ready — это общее понимание/договоренность между Владельцем Продукта и Командой Разработки о предпочтительном уровне проработки элемента Бэклога Продукта к моменту планирования.

DoR должен быть своеобразным щитом для команды

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

Однако он не должен превращаться в бюрократический барьер. В ситуации когда за 15 минут до планирования в ТОПе Бэклога Продукта появляется задача, по которой не все пункты DoR выполнены, Команда Разрабоки берет такую задачу в работу, а Владелец Продукта принимает на себя риски связанные с этим. Такой подход дает компании ту самую гибкость, которую описывает нам Agile манифест. Конечно такая ситуация не должна повторяться слишком часто. Иначе это может симптомом наличия системной проблемы, связанной с управлением Беклогом Продукта.

Как работать с Definition of Ready

Есть распространенное заблуждение, что работа с DoR заканчивается в тот момент, когда он составлен и команда регулярно его использует. На самом деле некоторые пункты в DoR могут быть дисфункцией. Например, наличие пункта «Архитектура согласована» в DoR у Скрам Команды прямо говорит нам о том, что команда на самом деле не автономна. Что может Скрам Мастер сделать в такой ситуации? Помочь команде затянуть к себе необходимую экспертизу и сократить время на согласования. Другой вариант попросить отдел Архитектуры сформулировать стандарты. Это поможет команде приносить на согласование решения соответствующее этим стандартам и также сократит время на согласование.

Говоря общими словами нам нужно критически посмотреть на каждый пункт DoD и задать себе вопрос: «Как он влияет на Time To Market?»

Для более полного понимание прикрепляю к этой статье Definition of Ready одной из моих команд.

Подробнее вы можете ознакомиться на примере.

Definition of Ready (DoR) пример

До PBR:

  • Impact/value задачи посчитан
  • Есть минимум один сценарий, описывающий успешную работу функционала

Во время PBR:

  • Задача сформулирована как User Story*
  • Сформулированы критерии приемки
  • Задача декомпозирована до уровня достаточного для оценки
  • У задачи есть оценка в Story Points
  • Есть согласованные макеты дизайна интерфейса*
  • Есть список стейкхолдеров, контактных лиц из других команд*
  • Согласованы сроки реализации и API с внешними командами*

    * Если применимо к задаче

Любой инструмент нужно использовать осознанно, в том числе и DoR. Если инструмент не решает никакой проблемы, то есть большая вероятность, что команда бесполезно потратит время на его создание. На практике он станет просто бесполезным артефактом. Опытный Скрам Мастер сможет определить, когда команда достаточно созрела для внедрения DoR.

Гибкая разработка ПО сегодня встречается повсеместно, можно даже назвать это явление мейнстримом. Однако внедрение Agile в различных организациях характеризуется переменным успехом. Мы подозреваем, что одна из причин возможных неудач кроется в изначальной мотивации к внедрению Agile – почему вообще организацию решили трансформировать. Мы расскажем о нескольких основных причинах внедрения Agile в организациях. Кроме того, мы предлагаем порассуждать о возможном влиянии этих причин на успешность трансформации.

Что это вообще значит — «дисциплинированный Agile»? В целом, быть дисциплинированным — это делать вещи, которые полезны для тебя, даже если это тяжело и…

Этот манифест является расширением оригинального Agile-манифеста разработки программного обеспечения, написанного в 2001 году. Дисциплинированный Agile-манифест отражает принципы, лежащие в основе дисциплинированного Agile-фреймворка.

Фреймворк «Дисциплинированный Agile» достаточно лёгок в применении. Он позволяет обеспечить основу для гибкости бизнеса, оптимизируя процессы в зависимости от контекста. Это достигается путем демонстрации совместной работы следующих видов деятельности: Delivery, DevOps, IT, Enterprise. Данный фреймворк описывает, зачем нужна каждая из перечисленных активностей, предоставляет ряд решений для их взаимодействия и описывает преимущества каждого из них.

Сможете ли вы справиться с распространенными проблемными кейсами, возникающими в Скрам Команде? Мы составили тест, с помощью которого вы можете проверить себя!

В условиях постоянных изменений все больше организаций стали применять Agile-практики. Зачастую, они фокусируются на постоянном улучшении процессов и активностях, забывая о реальных целях -…

Цели и жизнь Представьте себе приготовление ужина. Не будем углубляться в тонкости разных предпочтений и рассмотрим два очевидных варианта развития событий. 1. Заглядываем в…

Владелец Продукта (Product Owner) отвечает за достижение максимальной ценности продукта и работы, которую делает команда. Квалификация предполагает хорошее знание потребителя, рынка и бережное отношение к пользовательскому…