Владелец продукта.Работа с требованиями в Agile

Обоснование• Agile – бесспорный лидер по популярности среди

методологий• Работа с требованиями в Agile отличается от традиционной

модели работы с требованиями• В тренинге рассматривается весь процесc работы над

требованиями в Agile: от понимания концепции продукта до создания User Stories

• Особое внимание уделяется определению реальных потребностей пользователя

• Рассматриваются различные инструменты систематизации и анализа представлений о потребностях пользователя

Гибкая разработка

Почему Agile?

Эффективность выполнения проектов

Source: Standish Group Chaos Report 1995-2008

Эффективность управления требованиями

Up to 50%

35%

65%

Процент от общего календарного времени проекта, который тратится на сбор, разработку и передачу требований

Процент требований, меняющихся в ходе проекта

Процент реализованных возможностей, которые редко или никогда не используются пользователями

Традиционное управление разработкой ПО

Scope

Time Cost (resources)Es

timat

eFi

x

Ключевые препятствия для повышения эффективности

Неопределенность +

Функциональный подход =

Эффект Ряби

Ключевые препятствия для повышения эффективности

Сложность +

Тщательный анализ =

Аналитический Паралич

Agile – общие принципы

Почему Agile?

TimeBoxing. Фиксация времени

Scope

Time Cost

Estim

ate

Fix

Scope

Time CostAgile Software Development

Traditional Software Development

Agile ManifestoМенее важно Более важно

Процессы Люди

Инструментарий Общение

Документация Код

Проект Заказчик

План Изменения

Agile-принципы

Инкрементальный подход

Итерационный подход

Гибкость процесса добавляет около 40% трудозатрат на управление

продуктом

Scrum Процесс

Особенности Scrum•Backlog ранжированных задач•Фиксация и последовательное выполнение серии задач «быстрыми» итерациями – спринтами•Короткое ежедневное собрание для анализа результатов, проблем и перспектив•Короткая «планерка» по выбору задач для спринта из backlog`a•Краткий «разбор полетов» по прошедшему спринту с участием всей команды

Team

•Отвечает за результат

•Самоорганизующаяся

•Принимает решение по дизайну и имплементации

SCRUM-master

•Создает атмосферу прозрачности

•Управляет конфликтами

•Фасилитатор (модератор) митингов

•Отвечает за процесс

Product BackLog

Высокоуровневый план разработки:

-Адекватно детализирован-Оценен-Приоритезирован

Product Owner

•Владелец Product Backlog

•Управление ожиданиями заинтересованных лиц•Представляет пользователя•Взаимодействует с командой•Принимает продукт

Product Owner. ПроцессСоздает и

поддерживает

Участвует ВСЕГДА

Доступен для ответов на вопросы

Участвует в оценках

результатов разработки

Верифицирует достижение целей в

историях

Определяет цели, ценности и критерии их достижения в

Пользовательских Историях

Product Owner и команда•Создает и поддерживает Product BackLog

•Определяет Цели, Ценность и Критерии достижения в User Stories

•Верифицирует достижение целей в историях

•Участвует в оценке результатов разработки

Product Owner. Предметная область

•Эксперт в предметной области-Понимает область достаточно хорошо, чтобы представить продукт целиком-Отвечает на технические вопросы тех, кто создает продукт

•Адвокат конечного пользователя-Понимает все нюансы и детали использования продукта

•Адвокат Клиента-Понимает потребности бизнеса и выбирает возможности наиболее ценные для клиента

Product Owner. Бизнес•Адвокат Бизнеса

-Понимает цели и задачи компании, которая оплачивает создание ПО, и выбирает набор возможностей наиболее подходящий для их удовлетворения

•Коммуникатор-Способен донести видение и детали реализации точно и вовремя

•Принимает решения-Имея множество противоречивых целей, способен принять наиболее оптимальное решение

Традиционная разработка

Гибкая разработка

Понимание проблемы

Каковы причины «провала» продуктов?

Каковы причины?•24% - ошибочный анализ потребителя и его нужд•16% - проблемы продукта и дефекты•14% - недостаточность маркетинговых усилий•10% - затраты выше запланированных•9% - конкуренция•8% - неверное время запуска на рынок•6% - технические/производственные проблемы•13% - совокупность иных причин

Source: Robert Cooper, Winning at New Products

Генри ФордЕсли бы я слушал своих клиентов, то вряд ли должен был бы им дать что-то большее, чем немного более быстрая и выносливая лошадь.

Подход: пространство проблем и пространство решений

Задача аналитика

Упражняемся!

5 почему (5 WHYs, 5W)

Инструмент 5 WHY

-Используется для поиска первопричин

-Помогает найти корень проблемы

-5 вопросов «почему», заданных последовательно

-Возможность выделять ключевые и неключевые причины

Еще раз. Теперь в Excel

Упражняемся!

Диаграмма Исикавы (Fishbone Diagram, Рыбий Скелет, Cause &

Effect diagram)

Инструмент Диаграмма Исикавы

- Используя мозговой штурм, определить основные причины возникновения проблемы

-Разбить причины по категориям

-Выделить те, на которые есть возможность повлиять

-Устранить «подвластные» причины

И еще для разнообразия

Нулевая итерация

• Концепция решения (Vision)

• Высокоуровневое планирование

• Осуществимость решения

• Оценка

Концепция. Vision.

Системы мышления человека

By Malcolm Gladwell, ‘Blink’

Конвергентное и дивергентное мышление

Осуществление выбора

Design Thinking Process

ЭМПАТИЯ

Создание персон

-имя и фотография

-тип личности: темперамент, жизненная позиция

-краткая биография

-навыки

- сентиментальности

Создание персон

На что обращать внимание?

Поиск проблемы

•ЭМПАТИЯ

- Что говорит?- Что думает?- Что чувствует?- Что делает?

•ИНТЕРПРЕТАЦИЯ

- Что хочет?- Что для него важно?

•ФОКУС

- В чем состоит проблема/задача?- Что будет решением?

Процесс разработки персон

-Синтезируется на основе интервью реальных людей

-Суммарное описание одержит:

ПоведениеЦелиНавыкиОтношение

Упражняемся!

Моделирование персон

Карта опыта. Experience Map

Задачи и активности.Шаги создания

Активности и задачи

• Задачи требуют преднамеренных действий от пользователя инструмента

• Задачи имеют цель, которая должна быть достигнута• Задачи распадаются на более мелкие задачи

• Задачи часто группируются вместе в activity

Шаги создания Карты Опыта

Карта Опыта

Упражняемся!

Создание карты опыта

Определение проблемы

Да, это удовлетворяет моим требованиям,

но не решает мою ПРОБЛЕМУ

Девушке нужна не дрель, а отверстие

Девушке нужны не отверстия, а полка на стене

Девушке нужна не полка на стене, а место, где можно хранить вещи

Формулировка Проблемы: Почему и Как?

Помогает найти причину проблемы

Помогает найтирешение проблемы

Формирование определения проблемы

Упражняемся!

Формирование определения проблемы

Формирование позиционирования продукта

Упражняемся!

Формирование позиционирования продукта

Понимание проблемы

Концепция решения (Vision)

Персоны (Pragmatic Personas)

Карта Опыта (Experience Map)

Формулировка проблемы (Problem Statement)

Планирование

User Story. Story Mapping.

Требования являются многоцелевым элементомПотребности ПользователяОписание продуктаЭлемент планированияИдентификатор темы (token) для обсужденияИдентификатор темы, чтобыотложить обсуждение

Двухуровневое планирование

Гибкая разработка основана на двух видах планов:

Высокоуровневого внешнего плана: Product Backlog

Серия внутренних планов: Iteration Backlog

Requirements Workshop

•Значительно ускоряет процесс выявления требований•Собирает всех заинтересованных лиц вместе для интенсивного общения•Ведущий направляет семинар•Высказываются все•Результаты становятся доступными мгновенно•Обеспечивает контекст для применения других техник

Мозговой штурм•Подготовка

-Post-Its, Маркеры

• Сбор идей- Написать- Озвучить- Ведущий клеит на доску

•Очистка идей- Комбинировать похожие- Удалять неприменимые

•Систематизация

•Правила - Четко определить цели- Генерировать максимум идей- Любые фантастические идеи- Не позволять критиковать идеи

Упражняемся!

Генерация возможностей

•Бизнес цели (Epic)

•Активности «Кайт уровень»Longer Term goals often with no precise ending. I`ll perform several functional tasks in the context of the activity

•Задачи «Уровень поверхности»I`d reasonably expect to complete this in a single sitting

•Подфункции «Рыбы»Small tasks that by themselves don`t mean much. I`ll do several of these before I reach a functional level goal

•Марианская впадина

Уровни абстракции

Agile customers or product owner prioritize stories into a backlog

• Весь набор историй для программного продукта называется Product Backlog

• Backlog упорядочивается таким образом, чтобы наиболее ценные элементы были первыми

Story Map• Задачи размещаются вертикально, если пользователь

выполняет их в одно и то же время• Распределяя карту в пространстве, можно описать очень

большие истории

Формирование Решения

Планирование релизов. Приоритезация.

Планирование продуктов.

Планирование внутренних релизов

Формирование Решения

Люди: персоны и ролиUser Story

Roles and ActorsРоль и актер называют взаимоотношения персоны с

некоторой сущностью

Персоны (actors) определяют индивидуальные особенности определенного сегмента пользователей.

Роли определяют определяют функциональные особенности использования ПО с точки зрения зон ответственности.

Моделирование пользователей это простой первый шаг для обеспечения

максимально эффективной коммуникации целей проектирования

User StoriesПостепенное наращивание деталей:

Назавние (+ ID)

Сжатое описание:Как [type of user]Я хочу [выполнить некоторую работу/задачу]Для того чтобы [достичь конкретной цели]

Комментарий, детали или модели

До процесса планирования - Acceptance criteria (Definition Of Done)

User Story Template

Продукт который будет нравиться пользователям

Модель Кано

Привлекательные (Attractive)

• Возможности, которые обеспечивают удовлетворение, когда реализованы в полной мере. Но не вызывают недовольства, когда они не реализованы.

• Возможности, которые потребители не ожидают в продукте

• Пример:- Термометр на пакете молока

Так как задача этих возможностей приятно удивить пользователя, они могут быть не

афишированы

Одномерные (One-Dimensional)

• Характеристики продукта, которые приводят в удовлетворению, когда реализованы, и к недовольству, когда отсутствуют.

• Возможности, в области которых разворачивается конкурентная борьба

• Пример:- Если задекларировано, что пакет молока содержит на 10% больше молока за те же деньги, это приведет к удовлетворению клиентов- Но если молока окажется всего на 6% больше, клиент будет чувствовать себя обманутым

Обязательные (Must-be)

• Характеристики продукта, которые являются само собой разумеющимися и не приносят удовлетворения при реализации, но их отсутствие приводит к сильному недовольству.

• Пример:- Пакет молока течет

Нейтральные (Indifferent)

• Возможности, которые относятся к аспектам, которые не являются ни положительными, ни отрицательными. И явно не ведут к удовлетворению или неудовлетворению клиента.

• Пример:-Разные формы упаковок для молока

Обратное воздействие (Reverse)

• Эти возможности при высокой степени реализации ведут к высокой степени неудовлетворенности (не все клиенты одинковы)

• Пример:- Некоторые клиенты предпочитают высокотехнологичную продукцию, в то время как другие будут недовольны если продукт имеет слишком много дополнительных функций.

Спасибо за внимание