1.
Управление требованиями в Agile проектах Agile Ukraine Gathering 7 2009-04-25

2.
О докладчике <ul><li>Тимофей Евграшин </li></ul><ul><li>Опыт разработки ПО 12+ лет </li></ul><ul><li>Лидер команд и менеджер проектов 8+ лет </li></ul><ul><li>Certified ScrumMaster </li></ul><ul><li>«Евангелист» и тренер по внедрению гибких методологий управления проектами ( Agile/Scrum ) </li></ul><ul><li>email: tim@tim.com.ua </li></ul><ul><li>http://www.tim.com.ua </li></ul>

3.
Об источниках информации... <ul><li>Майк Кон </li></ul><ul><ul><li> Agile Estimating and Planning User Stories Applied </li></ul></ul><ul><ul><li>http://www.mountaingoatsoftware.com/articles-user-stories </li></ul></ul>

4.
«Дерево ожиданий» http://www.jacobsen.no/anders/blog/archives/images/project-thumb.jpg

5.
Проблемы коммуникации <ul><li>Требования и особенно процесс «Управление требованиями» – это общая проблема </li></ul><ul><ul><li>Те, кто «хотят» (заказчики), должны общаться с теми кто «может» (разработчики), чтобы достигнуть максимального результата </li></ul></ul><ul><li>Часто говорят во всем виноват плохой процесс «Управления требованиями» </li></ul><ul><ul><li>Что по вашему значит плохой процесс управления требованиями? </li></ul></ul><ul><ul><li>Какие проблемы появляются в результате плохого управления требованиями? </li></ul></ul>

6.
Ужасающая статистика

7.
Если разработчикам дать волю... <ul><li>... они перестанут слушать и учиться понимать нужды заказчика </li></ul><ul><li>«технический жаргон» заглушит «голос бизнеса» </li></ul><ul><li>Качество будет пожертвовано в пользу дополнительных «прибамбасов» </li></ul><ul><li>«Фичи» могут быть реализованы частично </li></ul><ul><li>Будут приниматься решения о функциональности без привлечения заказчиков </li></ul>

8.
Если заказчикам дать волю... <ul><li>Функциональность и даты будут обещаться без всякого учета реалий </li></ul><ul><li>Будут затяжные сессии предварительного сбора требований и их согласования </li></ul><ul><li>По мере наступления «дня Д» будут выкидываться первые попавшие под руку «фичи». </li></ul><ul><li>Мало кто будет интересоваться тем , как хорошо разработчики понимают нужды заказчика </li></ul>

9.
<ul><li>Последовательный </li></ul><ul><li>Итеративный </li></ul>О жизненном цикле проекта Feasibility Definition Design Construction Release Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 Release 1 Release 2 Iteration…

10.
Чтобы быть Agile ... <ul><li>Мы принимаем решения на основе той информации, которая есть сейчас </li></ul><ul><li>Вместо того, чтобы делать один раунд принятия всех решений </li></ul><ul><li>... и мы делаем это часто </li></ul><ul><li>... мы принимаем решения в течении жизни всего проекта </li></ul>При таком подходе, нам необходим простой инструмент работы с требованиями Истории Пользователя ( User Stories) помогут нам

11.
Еще планы на сегодня <ul><li>Что такое Истории Пользователей </li></ul><ul><li>Концепция – хорошая отправная точка </li></ul><ul><li>Роли </li></ul><ul><li>Как писать Истории Пользователей </li></ul><ul><li>Пишем истории для нашего приложения </li></ul><ul><li>Признаки хороших историй </li></ul><ul><li>Чем Истории Пользователей не являются </li></ul>

12.
Что такое Истории Пользователей <ul><li>User Story (Истории Пользователя) - это нужды конкретного пользователя выраженные в простой форме </li></ul><ul><li>Как < тип пользователя > я хочу < сделать > и тем самым получить < выгоды >. </li></ul><ul><li>Примеры : </li></ul><ul><ul><li>Как гость, я хочу зарезервировать номер, тем самым иметь гарантии размещения во время приезда </li></ul></ul><ul><ul><li>Как работник гостиницы, я хочу просматривать отчеты, тем самым получать информацию о работе гостиницы </li></ul></ul>

13.
3 « C » от Рона Джеффриса Card Conversation Confirmation Source: XP Magazine 8/30/01, Ron Jeffries. <ul><li>Истории пишутся на карточке </li></ul><ul><li>Вся служебная информация и комментарии должны вместиться на маленьком куске бумаги </li></ul><ul><li>Детали опущены до тех пор , когда они понадобятся </li></ul><ul><li>Когда понадобится , Product Owner расскажет их </li></ul><ul><li>Acceptance tests подтверждают, что история сделана </li></ul>

14.
А где детали? <ul><li>Как пользователь, я хочу отменить резервацию </li></ul><ul><ul><li>Полный или частичный возврат денег? </li></ul></ul><ul><ul><li>Какой лимит во времени? </li></ul></ul><ul><ul><ul><li>Единый для всех пользователей? </li></ul></ul></ul><ul><ul><ul><li>Единый для всех отелей? </li></ul></ul></ul><ul><ul><li>Следует ли слать подтверждение пользователю? </li></ul></ul>

15.
Детали как более мелкие Истории <ul><li>Как пользователь, я хочу отменить резервацию </li></ul><ul><li>Как Премиум пользователь я могу отменить резервацию вплоть до последней минуты </li></ul><ul><li>Как Не Премиум Пользователь я могу отменить резервацию минимум за 24 часа </li></ul><ul><li>Как посетитель сайта я хочу получить по e-mail уведомление об отмененной резервации </li></ul>

16.
Детали как критерии приемки <ul><li>Критерии приемки, которые подразумевает Владелец Продукта, могут быть добавлены для уточнения деталей. </li></ul><ul><ul><li>Как пользователь, я хочу отменить резервацию </li></ul></ul><ul><ul><ul><li>Проверить, что Премиум пользователи отменяют резервацию без штрафов </li></ul></ul></ul><ul><ul><ul><li>Проверить, что все Не Премиум пользователи платят 10% , если отменяют резервацию меньше чем за 24 часа </li></ul></ul></ul><ul><ul><ul><li>Проверить, что все пользователи получают уведомления по e-mail </li></ul></ul></ul><ul><ul><ul><li>Проверить, что Отели уведомляются об отмене резервации </li></ul></ul></ul>

17.
Жизненный цикл историй

18.
Концепция продукта / релиза <ul><li>Концепция - несколько предложений, описывающих идею, цели, ожидания </li></ul><ul><ul><li>Основа для понимания кто и как будет использовать продукт </li></ul></ul><ul><ul><li>Основа для расстановки приоритетов и планирования релизов </li></ul></ul><ul><ul><li>Постоянное напоминание о целях и инструмент поддержания фокуса команды и всех заинтересованных лиц </li></ul></ul>

19.
Роли <ul><li>Не думайте, что пользователь только один – расширьте кругозор </li></ul><ul><li>Попробуйте различать пользователей по: </li></ul><ul><ul><li>Целям использования приложения </li></ul></ul><ul><ul><li>Стилю использования приложения </li></ul></ul><ul><ul><li>Знаниям предметной области </li></ul></ul><ul><ul><li>Знаниям компьютеров, других приложений и т.п. </li></ul></ul><ul><ul><li>Общим атрибутам и т.п. </li></ul></ul><ul><li>Все это может помочь при создании дизайна интерфейсов и архитектуры приложения , ориентированных , в первую очередь , НА ПОЛЬЗОВАТЕЛЕЙ </li></ul>

20.
Айсберг требований

21.
Истории, Темы и Эпосы

22.
<ul><li>I ndependent - Независимые должна быть возможность приоритизировать истории независимо одну от другой </li></ul><ul><li>N egotiable - Обсуждаемые Истории – лишь напоминание - обсудить детали, когда придет время. Не думайте о них, как о спецификации или контракте </li></ul><ul><li>V aluable - Ценные Каждая история должна иметь ценность для пользователя </li></ul><ul><li>E stimatable - Оцениваемые должно быть достаточно информации, чтобы оценить каждую историю </li></ul><ul><li>S ized appropriately - Соразмерные Комплексные истории тяжело оценить, а связанные тяжело приоритезировать </li></ul><ul><li>T estable - Тестируемые Нужно четко знать, когда история закончена </li></ul>Хорошие Истории – это INVEST Спасибо William Wake за акроним www.xp123.com