владелец продукта

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

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

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

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

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

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

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

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

Почему Agile?

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

31%

52%

17 %Остановлены

В среднем 172% превышения бюджета

Успешны

Source: Standish Group Chaos Report 1995-2008

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

Up to 50%

35%

65%

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

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

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

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

Scope

Time Cost (resources)Es

tim

ate

Fix

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

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

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

Эффект Ряби

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

Сложность +

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

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

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

Почему Agile?

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

Scope

Time Cost

Esti

mat

eFi

x

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

ЭМПАТИЯ

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

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

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

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

-навыки

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

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

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

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

•ЭМПАТИЯ

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

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

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

•ФОКУС

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

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

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

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

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

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

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

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