Scrum scale что это
Гибкая методология разработки “Scrum”
Я продолжаю работу над диссертацией по проектному менеджменту. Сегодня мы кратко рассмотрим Scrum, рассмотрим типичные ошибки, приводящие к проблемам. Данный пост не претендует на полноту, он является обзорным и адресуется тем, кто еще не знаком со Scrum, или знаком лишь частично (к примеру, работает в модифицированном Scrum).
В настоящее время, Scrum является одной из наиболее популярных «методологий» разработки ПО. Согласно определению, Scrum — это каркас разработки, с использованием которого люди могут решать появляющиеся проблемы, при этом продуктивно и производя продукты высочайшей значимости (с точки зрения клиента — прим. Автора) [1].
Это говорит о том, что в Scrum невозможно найти ответы на все вопросы и указания к действию во всех ситуациях (к примеру, в официальном описании Scrum лишь указана необходимость оценки времени, необходимой на выполнение работы, но не уточняется вид оценки. Т.е. это может быть и planning poker и другой способ оценки). Таким образом, само наименование топика не верно 🙂
Когда говорят о методологии Scrum, чаще всего имеют ввиду гибкую методологию разработки ПО, построенную на основе правил и практик Scrum, так что вполне может оказаться что ваш Scrum круче моего Scrum, а также быть от него так же далеким, как ВАЗ 7-ка от BMW 7-й серии 🙂
Авторами Scrum заявлены следующие особенности:
-Легкий (англ. Lightweight)
-Понятный, доступный
-Сложный в освоении
(практически взаимоисключающие параграфы)
В классическом Scrum существует 3 базовых роли:
—Product owner
—Scrum master
—Команда разработки (Development team)
Product owner (PO) является связующим звеном между командой разработки и заказчиком. Задача PO — максимальное увеличение ценности разрабатываемого продукта и работы команды.
Одним из основных инструментов PO является Product Backlog. Product Backlog содержит необходимые для выполнения рабочие задачи (такие как Story, Bug, Task и др.), отсортированные в порядке приоритета (срочности).
Scrum master (SM) является «служащим лидером» (англ. servant-leader). Задача Scrum Master — помочь команде максимизировать ее эффективность посредством устранения препятствий, помощи, обучении и мотивации команде, помощи PO
Команда разработки (Development team, DT) состоит из специалистов, производящих непосредственную работу над производимым продуктом. Согласно The Scrum Guide (документу, являющимся официальным описанием Scrum от его авторов), DT должны обладать следующими качествами и характеристиками:
-Быть самоорганизующейся. Никто (включая SM и PO) не может указывать команде, как им преобразовать Product Backlog в работающий продукт
-Быть многофункциональной, обладать всеми необходимыми навыками для выпуска работающего продукта
-За выполняемую работу отвечает вся команда, а не индивидуальные члены команды
Рекомендуемый размер команды — 7 (плюс-минус 2) человека. Согласно идеологам Scrum, команды большего размера требуют слишком больших ресурсов на коммуникации, в то время как команды меньшего размера повышают риски (за счет возможного отсутствия требуемых навыков) и уменьшают размер работы, который команда может выполнить в единицу времени. [1]
Основой Scrum является Sprint, в течении которого выполняется работа над продуктом. По окончанию Sprint должна быть получена новая рабочая версия продукта. Sprint всегда ограничен по времени (1-4 недели) и имеет одинаковую продолжительность на протяжении всей жизни продукта.
Перед началом каждого Sprint производится Sprint Planning, на котором производится оценка содержимого Product Backlog и формирование Sprint Backlog, который содержит задачи (Story, Bugs, Tasks), которые должны быть выполнены в текущем спринте. Каждый спринт должен иметь цель, которая является мотивирующим фактором и достигается с помощью выполнения задач из Sprint Backlog.
Каждый день производится Daily Scrum, на котором каждый член команды отвечает на вопросы «что я сделал вчера?», «что я планирую сделать сегодня?», «какие препятствия на своей работе я встретил?». Задача Daily Scrum — определение статуса и прогресса работы над Sprint, раннее обнаружение возникших препятствий, выработка решений по изменению стратегии, необходимых для достижения целей Sprint’а.
По окончанию Sprint’а производятся Sprint Review и Sprint Retrospective, задача которых оценить эффективность (производительность) команды в прошедшем Sprint’е, спрогнозировать ожидаемую эффективность (производительность) в следующем спринте, выявлении имеющихся проблем, оценки вероятности завершения всех необходимых работ по продукту и другое.
Схематическое изображение процесса приведено на следующем рисунке: 
Важные, часто забываемые особенности
Часто можно услышать, что Scrum не работает, или работает хуже, чем ожидалось. Необходимо заметить, что чаще всего так происходит по одной из следующих причин:
1. Scrum применяется неверно или неполностью.
Согласно авторам Scrum, эмпирический опыт является главным источником достоверной информации. Необходимость полного и точного выполнения Scrum указана в The Scrum Guide и обусловлена нетипичной организацией процесса, отсутствием формального лидера и руководителя.
2. Недооценена важность работы по обеспечению мотивации команды.
Одним из основных принципов Scrum являются самоорганизующиеся, многофункциональные команды. Согласно исследованиям социологов, численность самомотивированных сотрудников, способных на самоорганизацию не превышает 15% от работоспособного населения [2].
Таким образом, лишь небольшая часть сотрудников способно эффективно работать в Scrum без существенных изменений в ролях Scrum master и Product Owner, что противоречит идеологии Scrum, и потенциально приводит к неверному или неполному использованию Scrum.
3. Scrum применяется для продукта, требования к которому противоречат идеологии Scrum.
Scrum относится к семейству Agile, так Scrum приветствует изменения в требованиях в любой момент (Product backlog может быть изменен в любой момент). Это затрудняет использование Scrum в fixed-cost/fixed-time проектах. Идеология Scrum утверждает, что заранее невозможно предусмотреть все изменения, таким образом нет смысла заранее планировать весь проект, ограничившись только just-in-timе планированием, т. е. Планировать только ту работу, которая должна быть выполнена в текущем Sprint. [3] Существуют и иные ограничения.
Достоинства и недостатки
Scrum обладает достаточно привлекательными достоинствами. Scrum ориентирован на клиента, адаптивен. Scrum дает клиенту возможность делать изменения в требованиях в любой момент времени (но не гарантирует того, что эти изменения будут выполнены). Возможность изменения требований привлекательна для многих заказчиков ПО.
Scrum достаточно прост в изучении, позволяет экономить время, за счет исключения не критичных активностей. Scrum позволяет получить потенциально рабочий продукт в конце каждого Sprint’а.
Scrum делает упор на самоорганизующуюся, многофункциональную команду, способную решить необходимые задачи с минимальной координацией. Это особенно привлекательно для малых компаний и стартапов, так как избавляет от необходимости от найма или обучения специализированного персонала руководителей.
Конечно, у Scrum есть и важные недостатки. Ввиду простоты и минималистичности, Scrum задает небольшое количество довольно жестких правил. Однако это вступает в конфликт с идеей клиентоориентированности в принципе, т. к. клиенту не важны внутренние правила команды разработки, особено если они ограничивают клиента. К примеру, в случае необходимости, по решению клиента Sprint backlog может быть изменен, не смотря на явное противоречие с правилами Scrum.
Проблема является большей, чем кажется. Т.к. Scrum относится к семейству Agile, в Scrum не принято, к примеру, создание плана коммуникаций и реагирования на риски. [3] Таким образом, делая сложным или невозможным формальное (юридическое или административное) противодействие нарушениям правил Scrum.
Другой слабой особенностью Scrum является упор на самоорганизующуюся, многофункциональную команду. При кажущемся снижении затрат на координацию команды, это приводит к повышению затрат на отбор персонала, его мотивацию, обучение. При определенных условиях рынка труда, формирование полноценной, эффективной Scrum команды может быть невозможным.
Помимо Scrum, я рекомендую обратить внимание на Канбан. В этом видео я сделал небольшой обзор метода Канбан:
Список использованных источников
[1] The Scrum Guide. The definitive Guide to Scrum: The Rules of the Game. (Ken Schwaber, Jeff Sutherland)
[2] Психология управления, учебное пособие. (А. А. Трусь)
[3] How a Traditional Project Manager Transforms to Scrum: PMBOK vs. Scrum. (Jeff Sutherland, Nafis Ahmad)
Заранее благодарю за указанные ошибки и неточности!
Что такое scrum: преимущества и недостатки
Узнайте больше о том, для чего нужен scrum и как он работает
Scrum (скрам) ― это один из agile-подходов к разработке и управлению проектами. Чаще всего данный метод используют в IT-сфере, однако он применим для разных направлений, включая строительство, образование, производство товаров, ивент-индустрию и другие виды деятельности.
Посмотрите это короткое видео, чтобы лучше понять, что собой представляет методология scrum, как она помогает решать задачи и какие есть основные роли.
Содержание
Зачем нужен scrum?
По словам Джефа Сазерленда, создателя методологии скрам, этот подход является идеальной моделью полного взаимодействия участников команды. Он предполагает регулярное отслеживание процесса работы, что позволяет увидеть результативность прилагаемых усилий, оценить правильность направления движения и решать задачи с меньшими усилиями. При этом, основа планирования по методу scrum — это гибкость. Вы всегда можете внести новые идеи и необходимые изменения.
Скрам нужен для планирования работы, системной организации рабочего процесса, развития ответственности и самоорганизованности в команде. Методология позволяет легко адаптироваться к изменчивым окружающим факторам и постоянно обучаться.
Если говорить о разработке программного обеспечения, то скрам — идеальный подход для реализации идеи, поскольку помогает выстраивать работу без конкретного пошагового плана на начальном этапе. Команда постепенно устраняет неопределенность, выбирает курс дальнейшей работы и анализирует пользу приложенных усилий. В отличие от линейного (каскадного) способа разработки, процесс движется быстрее, требует меньших затрат и легко адаптируется под требования заказчика.
В следующем разделе вы ознакомитесь с преимуществами и главными недостатками методологии scrum.
Преимущества и недостатки scrum
Scrum имеет ряд преимуществ как для команды, так и для компании в целом. Ознакомьтесь с основными сильными сторонами этой методологии:
Скрам — это win-win подход, который обеспечивает такое взаимодействие команды и заказчика, при котором каждая сторона остается в выигрыше и получает желаемое. Однако, несмотря на явные преимущества в планировании, распределение нагрузки внутри команды, прозрачность коммуникации и гибкость работы у этого метода есть и недостатки:
Чтобы лучше понять, что собой представляет методология скрам, ознакомьтесь с правилами организации работы в следующем разделе.
Как работает scrum
Работа по методу скрам предполагает определенный алгоритм действий.
Для визуализации процесса используют scrum-доску, на которой размещают задачи и отслеживают их статус в рамках текущего спринта. Она может быть виртуальной или реальной с использованием канцелярских стикеров. На скриншоте ниже вы видите, как может выглядеть такая доска.
На первый взгляд она схожа с доской, которую используют в методологии канбан. Однако, в них есть отличия. Scrum больше опирается на временные промежутки выполнения работы (длительность спринта), в то время как в канбан более важен сам список задач.
Тем не менее, и в том и в другом инструменте часто используют одинаковое этапы выполнения работы:
Каждой задачи из бэклога присваивают определенный статус путем ее перемещения из одной колонки в другую. Чтобы получить максимальную отдачу от внедрения метода scrum, прежде всего важно его адаптировать под свои рабочие процессы. Помните, любой agile-подход — это метод управления, который еще важно научиться использовать.
Поэтому, не торопитесь сразу использовать подход scrum и кардинально менять рабочий процесс. Сначала проведите предварительную подготовку, изучите кейсы разных компаний и доступную литературу, оцените свою команду, взвесьте все за и против и только после этого приступайте к внедрению.
SCRUM: Гибкое управление продуктовыми направлениями
Статья раскрывает тему гибкости управления продуктом в части доставки бизнес-ценности и мобильность в адаптации к изменяющимся внешним условиям. Чёткое понимание видения продукта помогает синхронизировать разработку продукта с бизнес-стратегией компании для достижения стратегических целей. Понимание ценности задаёт темп непрерывного развития продукта. Ценность продукта включает в себя улучшенную транспарентность для применения и развития ценностно ориентированного подхода для принятия решений. Ключевые постулаты предмета включают в себя непрерывное определение ценности, измерение актуальной доставленной ценности, валидация гипотез и анализ трендов.
В статье предложена система метрик для измерения и дальнейшего анализа атрибутов гибкого управления продуктовыми направлениями.
Прогнозирование и планирование релиза
Разработка программного обеспечения является процессом создания продукта и дальнейшего его вывода на рынок потребителей. Сам процесс разработки программного обеспечения живёт в эмпирическом мире, которому свойственно иметь большую неопределённость и хаос. С целью организации бережливого производства для среды с неопределённостью и хаосом, прогнозирование релиза сводится к следующим ключевым идеям:
Конечным результатом прогнозирования является приверженность команды к объёму работ, а не конечная абстрактная оценка по трудозатратам. Процесс организации разработки вокруг оценки трудозатрат внедряет избыточный объём работ, результаты которого либо не используются, либо не нужны клиенту.
Фокусом прогнозирования является добавочная ценность новых функций продукта. В том случае если фокусом является трудозатраты, то возникают сложности в обосновании целесообразности реализации новых функций продукта для клиента.
Клиент платит не за отдельно взятые функции продукта, клиент платит за ценность продукта. Производителем ценности является продуктовая команда, спонсируемая клиентом. Соответственно, при таком подходе отпадает необходимость проведения оценки трудозатрат, так как есть команда, которая гарантирует доставку инкремента с ценностью каждый релизный цикл. Данная идея будет более подробно рассмотрена в рамках ценностной модели обоснования трансформации, так как является системообразующей.
Наблюдение за наличием ответственного лица, который принимает решение о включении доработки в бэклог спринта.
ответственное лицо на уровне компании не выделяется — 0 баллов.
существуют несколько ответственных лиц за одно продуктовое направление — 1 балл.
есть единственное лицо на продуктовое направление, ответственность доставки ценности инкремента не осознаётся — 3 балла.
есть единственное лицо на продуктовое направление, ответственность доставки ценности инкремента осознаётся — 5 баллов.
Участники планирования содержания продукта
Наблюдение за присутствуем стейкхолдеров и ответственных лиц продуктовых направлений на планировании содержания продукта.
при планировании присутствуют только стейкхолдеры — 0 баллов.
при планировании присутствуют стейкхолдеры и часть ответственных лиц продуктовых направлений — 1 балл.
при планировании присутствуют стейкхолдеры и все ответственные лица продуктовых направлений — 3 балла.
при планировании присутствуют стейкхолдеры и все ответственные лица продуктовых направлений, а также смежные представители по интеграционным вопросам — 5 баллов.
Участники планирования содержания спринта
Наблюдение за присутствуем функциональных исполнителей (разработчиков) на планировании спринта.
исполнители отсутствуют на планировании — 0 баллов.
на планировании присутствуют представители (тимлиды) исполнителей — 1 балл.
на планировании присутствуют исполнители, не объединённых общей командой — 3 балла.
на планировании присутствуют исполнители, объединённые командой — 5 баллов.
Принцип планирования содержания спринта
Наблюдение за принципом включения доработки в состав спринта.
учитываются только приоритеты стейкхолдеров — 0 баллов.
учитываются приоритеты стейкхолдеров и трудозатраты — 1 балл.
учитываются приоритеты стейкхолдеров, полнота существующих знаний — 3 баллов.
учитываются приоритеты стейкхолдеров, полнота существующих знаний, готовность постановок — 5 баллов.
Наблюдение за применяемой техникой при прогнозировании допустимого объёма спринта
прогнозирование не проводится — 0 баллов.
прогнозирование проводит тимлиды функциональных групп — 1 балл.
прогнозирование проводит команда продуктового направления без определённой техники — 3 балла.
прогнозирование проводит команда продуктового направления, используется техника pokerpointing — 5 баллов.
0–17 баллов — низкий результат, характеризующий отсутствие гибкости производства в части синхронизации объёма работа стейкхолдеров и продуктовой команды. Данные ограничения обусловлены наличием нескольких рабочих групп с дублирующими функциями, а также размытой зоной ответственности продуктовой команды. Рекомендуется предусмотреть мероприятия по сокращению рабочих групп с дублирующими функциями и выделить единого ответственного лица за продуктовое направление. В дополнении рекомендуется провести тренинг сессии со стейкхолдерами.
18–21 баллов — средний результат, характеризующий ограниченную гибкость производства в части синхронизации объёма работа стейкхолдеров и продуктовой команды. Данные ограничения обусловлены маршрута объёма работ по принципу «глухого телефона», на этапах которого происходит искажение общего информационного поля. В плане улучшения характеристик рекомендуется рассмотреть мероприятия, направленные на оптимизацию маршрута объёма работ.
22–25 баллов — высокий результат, характеризующий гибкость и устойчивость производства программного обеспечения с точки зрения управления ожиданиями. Стейкхолдеры и продуктовые команды синхронизированы относительно содержания инкрементов. Отсутствуют изолированные от продуктового бэклога работы, что предотвращает производство ненужных результатов.
Видение продукта
Видение продукта, или общая концепция продукта, определяет долгосрочную миссию продуктового направления в части маршрута развития. Видение должно выполнять функцию ориентира для всех стейкхолдеров, вовлечённых в разработку программного обеспечения, для достижения общих целей с выпуском инкремента продукта. Продуктовое видение отвечает на вопрос, почему создаётся данный продукт и что компания надеется достигнуть в ближайшем будущем.
Структура видение может быть описана по следующему шаблону:
Для кого: целевая аудитория продукта.
Потребности: потребности и проблемы клиента для решения.
Продукт: брендовое название продукта.
Категория: описание продукта.
Преимущества: ключевые преимущества продукта, причины приобретения.
Сравнение: особенности от конкурентов.
Характеристика
Метод исследования
Метрика
Наблюдение за наличием единственного сотрудника, владеющего видением продукта (продуктового направления).
отсутствует владелец видения — 0 баллов.
существуют несколько владельцев видения — 1 балл.
существует единственный сотрудник в качестве носителя видения, который его не разделяет — 3 балла.
существует единственный сотрудник в качестве носителя видения, который его разделяет — 5 баллов.
Наблюдение за принципом распространения видения среди стекйхолдеров и продуктовой команды.
видение распространяется только среди продуктовой команды — 0 баллов.
видение распространяется только среди стейкхолдеров — 1 балл.
видение распространяется среди стекйхолдеров и продуктовой команды с использованием одинаковых материалов — 3 балла.
видение распространяется среди стекйхолдеров и продуктовой команды с использованием разных материалов — 5 баллов.
Инкрементность и итеративность видения
Наблюдение за принципом этапного развития и доставки видения.
видение доставляется в виде продукта без промежуточных этапов — 0 баллов.
видение доставляется инкрементно без итеративности — 3 балла.
видение доставляется инкрементно с итеративностью — 5 баллов.
Наблюдение за проявлением свойства адаптировать видение к изменяющимся внешним условиям по мере изучения нового.
видение сложно меняется и является идеологическим монолитом — 0 баллов.
изменение видения продуктового направления ограничено корпоративными бюрократическими барьерами — 1 балл.
изменение видения продуктового направления проводится по регламентированной процедуре — 3 балла.
видение продуктового направления может легко меняться, в компании отсутствуют административные барьеры — 5 баллов.
Наблюдение за проявлением свойства позиционировать видение относительно бизнес-ценности.
позиционирование видения насыщено техническими деталями — 0 баллов.
позиционирование видения находится в плоскости решения проблемы и/или доставки добавочной ценности для бизнеса — 5 баллов.
Наблюдение за механизмами валидации видения продукта со стекйхолдерами, продуктовой командой и рынком.
валидация видения не проводится — 0 баллов.
валидация видения проводится только со стейкхолдерами — 1 балл.
валидация видения проводится со стейкхолдерами и командой — 3 балла.
валидация видения проводится со стейкхолдерами, командой и рынком — 5 баллов.
Отношение видения к стратегии компании
Наблюдение за проявлением принципа соответствия видения продукта со стратегией компании.
отсутствует сопоставление видения продуктового направления со стратегическими целями компании — 0 баллов.
существует косвенное сопоставление видения продуктового направления со стратегическими целями компании — 3 балла.
существует прямое сопоставление видения продуктового направления со стратегическими целями компании (увеличение дохода, рост объёма продаж, увеличение доли рынка, улучшение имиджа) — 5 баллов.
0–24 баллов — низкий результат, характеризующий отсутствие продуктового видения как инструмента определения стратегического вектора развития продуктового направления. Данный результат свойственен компаниям с контрактной моделью предоставления сервиса по заказной разработке. Проявляются высокие риски закрытия целых продуктовых направлений. Рекомендуется разработать полноценную программу развития культуры продуктового видения, включив стратегические сессии, коучинг руководителей и тренинги сессии продуктовых команд.
25–29 баллов — средний результат, характеризующий слабую степень развития продуктового видения, которое выражается в рассинхронизации общего представления вектора движения между стекйхолдерами: заказчик, акционеры, руководство и продуктовая команда. При данном результате преобладает низкая культура корреляции стратегических целей компаний с концепцией продуктовых направлений.
30–35 баллов — высокий результат, характеризующий уверенную степень развития продуктового видения, которое обеспечивает разработку дорожной карты по принципу декомпозиции высокоуровневой концепции на тактические задачи в вид бэклога продукта для продуктовой команды. Наблюдается проявление принципа принятия решений на основании стратегических ориентиров. Продуктовая команда и стейкхолдеры синхронизированы в понимании стратегического вектора движения продукта.
Ценность продукта
Ценность продукта — выгоды, приобретаемые пользователем продукта для удовлетворения потребностей с определёнными затратами на них. Ценность продукта является агентом сделки между пользователем и разработчиком программного обеспечения, при котором происходит перераспределение финансовых благ. Ценность, обеспечиваемая продуктом, зависит от двух аспектов:
Важность цели, которую пользователь собирается достигнуть при использовании продукта. Данный аспект определяет абсолютную ценность, характеризующую степень соответствия потребностям пользователя.
Доступные альтернативные решения на рынке для сравнения конкурентных преимуществ. Данный аспект демонстрирует относительную ценность, которая определяет конкурентные правила и векторы роста продукта.
Характеристика
Метод исследования
Метрика
Наблюдение за проявлением проектного или продуктового мировоззрения.
преобладает мировоззрение в контексте проектного треугольника (состав работ, сроки и ресурсы) — 0 баллов.
выделяется как проектное, так и продуктовое мировоззрение — 3 балла.
преобладает продуктовое мировоззрение в контексте доставки ценности продукта — 5 баллов
Наблюдение за признанием ценностей продуктового направления в разрезе выделенных элементов ценности (The 30 Elements of Consumer Value: A Hierarchy).
продуктовые направления не имеют систему элементов ценности — 0 баллов.
продуктовые направления имеют систему элементов ценности, которые не признаны на всех уровнях компании — 1 баллов.
продуктовые направления имеют систему элементов ценности, которые признаны на всех уровнях компании — 3 баллов.
продуктовые направления имеют систему элементов ценности, которые признаны на всех уровнях компании. Проведено маркетинговое исследование для подтверждения — 5 баллов.
Наблюдение за техникой целеполагания в контексте ценности продуктового направления.
техника отсутствует, целеполагание не проводится — 0 баллов.
техника отсутствует, целеполагание проводится — 1 баллов.
присутствует техника impact mapping, ограниченное использование — 3 балла.
Определение интегральной шкалы оценки свойства «ценность продукта» не целесообразно так, как каждый атрибут является самодостаточной характеристикой и требует индивидуального подхода в интерпретации и разработки мероприятий для развития. Рекомендуется в программе предусмотреть мероприятия стратегических сессий руководителей компании и владельцев продуктовых направлений, тренинг сессии владельцев продуктов для развития культуры целеполагания.
Управление продуктовым бэклогом
Эффективное управление продуктовым бэклогом гарантирует разработку продукта согласно видению с целью доставки добавочной ценности. Более того, повышается транспарентность информационного поля, выстраивается эмпирический механизм валидации ценности и сокращаются зависимости.
Характеристика
Метод исследования
Метрика
Наблюдение за единым местом хранения всех задач, направленных на развитие продукта.
бэклог продукта отсутствует — 0 баллов.
бэклог продукта имеет вид разбросанных задач — 1 балл.
бэклог имеет вид отфильтрованного списка по предмету — 3 балла.
бэклог единое место хранения всех задач по продукту — 5 баллов.
Наблюдение за наличием единственного сотрудника, являющимся владельцем бэклога продуктового направления.
отсутствует владелец бэклога — 0 баллов.
существуют несколько владельцев бэклога — 1 балл.
существует единственный сотрудник в качестве владельца бэклога, на уровне компании не признаётся — 3 балла.
существует единственный сотрудник в качестве владельца бэклога, на уровне компании признаётся — 5 баллов.
Наблюдение за проявлением принципа доступности бэклога всем заинтересованным сторонам.
бэклог не доступен команде продуктового направления и стейкхолдерам или существуют ограничения в части получения доступа — 0 баллов.
бэклог доступен команде продуктового направления и стейкхолдерам по ссылке — 5 баллов.
Наблюдение за принципом организации структуры элементов бэклога.
бэклог включает в себя элементы, отличные от Agile-подхода — 0 баллов.
бэклог включает в себя: EPIC (эпик), user story (пользовательская история), task (задача), subtask (подзадача), bug (дефект) — 5 баллов.
Определение интегральной шкалы оценки свойства «управление продуктовым бэклогом» не целесообразно так, как каждый атрибут является самодостаточной характеристикой и требует индивидуального подхода в интерпретации и разработки мероприятий для развития. Рекомендуется в программе предусмотреть мероприятия с включением коучинг и тренинг сессий владельцев продуктов для развития культуры целеполагания.