Embed Size (px)
DESCRIPTION
Управление проектом/продуктом в Agile в первую очередь связано с эффективным управлением требованиями. Хорошие требования = ценный для заказчика продукт. Для любого менеджера продуктов существует две основных преграды к реализации продукта: — Что делать в первую очередь? Как управлять приоритетами?— Как интегрировать сбор требований в итеративный процесс разработки.В этом докладе мы поговорим о том, чем отличается классический сбор требований от организации требований в Agile разработке. Поговорим о способах эффективного сбора требований, метриках и т.д. Обсудим роль Product Owner'a.
Citation preview
Agile-управление требованиями
Филиппов Никита, ScrumTrek
вторник, 8 июня 2010 г.
2
!"#"$%&'"("))*+&• ,-.-/0./&1-23.42&-3&56278924:&
• ;/0<4&=>-6?@&;/0<4&1,A&
вторник, 8 июня 2010 г.
Давным, давно... люди думали, что все очень сложно...
3
вторник, 8 июня 2010 г.
Потом, что все просто...
4
вторник, 8 июня 2010 г.
Потом появился Scrum и XP
5
вторник, 8 июня 2010 г.
Мы Agile!!! Мы Agile!
6
вторник, 8 июня 2010 г.
Мы Agile!!! Мы Agile!
6
Мы сделали
демонстрацию!!!
вторник, 8 июня 2010 г.
Мы Agile!!! Мы Agile!
6
Мы сделали
демонстрацию!!!
ТаскБорд!!!
вторник, 8 июня 2010 г.
Мы Agile!!! Мы Agile!
6
Мы сделали
демонстрацию!!!
ТаскБорд!!!Командная ответственность!
вторник, 8 июня 2010 г.
Мы Agile!!! Мы Agile!
6
Мы сделали
демонстрацию!!!
ТаскБорд!!!Командная ответственность!
Рефакторинг и регулярное CodeReview
вторник, 8 июня 2010 г.
Мы Agile!!! Мы Agile!
6
Мы сделали
демонстрацию!!!
ТаскБорд!!!Командная ответственность!
TDD, Полное покрытие Тестами.
Рефакторинг и регулярное CodeReview
вторник, 8 июня 2010 г.
Мы Agile!!! Мы Agile!
6
Мы сделали
демонстрацию!!!
ТаскБорд!!!Командная ответственность!
TDD, Полное покрытие Тестами.
Рефакторинг и регулярное CodeReview
Автоматизация тестирования
вторник, 8 июня 2010 г.
Мы Agile!!! Мы Agile!
6
Мы сделали
демонстрацию!!!
ТаскБорд!!!Командная ответственность!
TDD, Полное покрытие Тестами.
Рефакторинг и регулярное CodeReview
Автоматизация тестирования
А мы работаем в Парах :)
вторник, 8 июня 2010 г.
Мы внедрили ScrumНО
7
вторник, 8 июня 2010 г.
Т.З.
Мы внедрили ScrumНО
7
вторник, 8 июня 2010 г.
Т.З.
Мы внедрили ScrumНО
7
Мы не успеваем писать Т.З. - Слишком много и слишком долго
30д.
вторник, 8 июня 2010 г.
Т.З.
Мы внедрили ScrumНО
Все задачи очень приоритетные
7
Мы не успеваем писать Т.З. - Слишком много и слишком долго
30д.
вторник, 8 июня 2010 г.
Заказчики считают нас Гиками, которые играют в игры
Они не понимают «крутость» Agile
Заказчики нас не любят ;)
8
Ваш Аджайл, отстой.
вторник, 8 июня 2010 г.
Наверное с вашим Agile что-то не так...
9
вторник, 8 июня 2010 г.
Agile-Manifesto principles
We follow these principles:Our highest priority is to satisfy the customer
through early and continuous delivery of valuable software.
Business people and developers must work together daily through out the project.
www.Agilemanifesto.org 10
вторник, 8 июня 2010 г.
Это не Agile!
Вы делаете Scrum или XP, но заказчик недоволен результатами.
Вы делаете Scrum, но бизнес не хочет с вами сотрудничать
Это не Agile, если практики есть, а заказчик недоволен
11
вторник, 8 июня 2010 г.
Это не Agile!
Вы делаете Scrum или XP, но заказчик недоволен результатами.
Вы делаете Scrum, но бизнес не хочет с вами сотрудничать
Это не Agile, если практики есть, а заказчик недоволен
11
вторник, 8 июня 2010 г.
Это не Agile!
Вы делаете Scrum или XP, но заказчик недоволен результатами.
Вы делаете Scrum, но бизнес не хочет с вами сотрудничать
Это не Agile, если практики есть, а заказчик недоволен
Scrumbutt
©Ken Schwaber
11
вторник, 8 июня 2010 г.
Все дело в управлении продуктом
12
вторник, 8 июня 2010 г.
Что нужно делать?Не писать лишнего
Уметь развивать продукт инкрементально
Прорабатывать требования детально
Доставлять самое нужное и важное в первую очередь
Понимать, что ценно для заказчика (или конечного пользователя)
Понимать развитие продукта в среднесрочной и долгосрочной перспективе.
Знать когда сможем поставить ту или иную функциональность (или что войдет в релиз), зная что мы живем в мире изменений. 13
вторник, 8 июня 2010 г.
Параллельная разработка
!"# $%&$%'#"%"(?)
*%+ $%&$%'#"%"(?)
*%+ ,#--.$/01%"(?)
Процесс сбора требований размывается на весь проект 14
вторник, 8 июня 2010 г.
Agile Product Development
• !"#$"%&'()*)+,'-.'"/0/1/'2/32/4.$56'• 789:;<=89:;'>'$2?4.@/"6#'A.$.@%'5'"/0/1B'6$?2/C66'
• !.@1?0?"6?'5.D/"-%'@'E.-A.$.@5B'$2?4.@/"6&' ()*)+,'
F2?4.@/"6#'
F?G$%'15
вторник, 8 июня 2010 г.
Agile Product Development
Innovation GamesStory MappingCrafting the Vision Backlog prioritizing Creating User StoriesWorking with Focus
GroupsUX
!"#
$%&'()*+&#,*-)#
16
Ускорение сбора требований, через специальные Workshop’ы
вторник, 8 июня 2010 г.
Vision Crafting: Personas & Product Box
17
вторник, 8 июня 2010 г.
Agile Product Development - Инкрементальная разработка
Итерация
Релиз
Будущие релизы
18
вторник, 8 июня 2010 г.
Айсберг Product Backlog’a
User Stories
Epic Stories
Theme
19
вторник, 8 июня 2010 г.
Детализация историй
Тема
Эпическая история (epic)
История пользователя (user story)
Приемочные тесты
20
• Я, как <роль>, могу <действие> для того, чтобы <достичь целей>
вторник, 8 июня 2010 г.
StoryMapping
21
вторник, 8 июня 2010 г.
StoryMapping & Release Planning
22
вторник, 8 июня 2010 г.
StoryMapping & Prioritizing
23
Hi
Low
вторник, 8 июня 2010 г.
Выводы
• Чтобы сделать хороший продукт- Частое взаимодействие с заказчиком- Использование современных практик сбора требований и приоритезации
- Инкрементальное развитие Backlog’a- Не обманывать заказчика по поводу выпусков релиза :)
24
вторник, 8 июня 2010 г.
Выводы
25
Не писать лишнего
Уметь развивать продукт инкрементально
Прорабатывать требования детально
Доставлять самое нужное и важное в первую очередь
Понимать, что ценно для заказчика (или конечного пользователя)
Понимать развитие продукта в среднесрочной и долгосрочной перспективе.
Знать когда сможем поставить ту или иную функциональность (или что войдет в релиз), зная что мы живем в мире изменений.
вторник, 8 июня 2010 г.
Выводы
25
Не писать лишнего
Уметь развивать продукт инкрементально
Прорабатывать требования детально
Доставлять самое нужное и важное в первую очередь
Понимать, что ценно для заказчика (или конечного пользователя)
Понимать развитие продукта в среднесрочной и долгосрочной перспективе.
Знать когда сможем поставить ту или иную функциональность (или что войдет в релиз), зная что мы живем в мире изменений.
Используем UserStory
вторник, 8 июня 2010 г.
Выводы
25
Не писать лишнего
Уметь развивать продукт инкрементально
Прорабатывать требования детально
Доставлять самое нужное и важное в первую очередь
Понимать, что ценно для заказчика (или конечного пользователя)
Понимать развитие продукта в среднесрочной и долгосрочной перспективе.
Знать когда сможем поставить ту или иную функциональность (или что войдет в релиз), зная что мы живем в мире изменений.
Используем UserStory
Планирование релизов
вторник, 8 июня 2010 г.
Выводы
25
Не писать лишнего
Уметь развивать продукт инкрементально
Прорабатывать требования детально
Доставлять самое нужное и важное в первую очередь
Понимать, что ценно для заказчика (или конечного пользователя)
Понимать развитие продукта в среднесрочной и долгосрочной перспективе.
Знать когда сможем поставить ту или иную функциональность (или что войдет в релиз), зная что мы живем в мире изменений.
Используем UserStory Приоритезация
Планирование релизов
вторник, 8 июня 2010 г.
Выводы
25
Не писать лишнего
Уметь развивать продукт инкрементально
Прорабатывать требования детально
Доставлять самое нужное и важное в первую очередь
Понимать, что ценно для заказчика (или конечного пользователя)
Понимать развитие продукта в среднесрочной и долгосрочной перспективе.
Знать когда сможем поставить ту или иную функциональность (или что войдет в релиз), зная что мы живем в мире изменений.
Используем UserStory
StoryMappingПриоритезация
Планирование релизов
вторник, 8 июня 2010 г.
Выводы
25
Не писать лишнего
Уметь развивать продукт инкрементально
Прорабатывать требования детально
Доставлять самое нужное и важное в первую очередь
Понимать, что ценно для заказчика (или конечного пользователя)
Понимать развитие продукта в среднесрочной и долгосрочной перспективе.
Знать когда сможем поставить ту или иную функциональность (или что войдет в релиз), зная что мы живем в мире изменений.
Используем UserStory
Пишем и
согласуе
м Vision
StoryMappingПриоритезация
Планирование релизов
вторник, 8 июня 2010 г.
Думайте о продукте, а не об Agile
26
• Вопросы?
• [email protected]• Skype: nikita_filippov
• Больше на тренинге Agile Requirements Analysis
Agile - это искусство делать продукты, которые нравятся заказчикам, а не конкретные практики Scrum или XP!
вторник, 8 июня 2010 г.
