Владелец продукта.Работа с требованиями в 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)