3_Вимоги_1 / 09.17.12 / ! / Управление требованиями в Agile

Управление требованиями в Agile. Пользовательские истории

http://www.uml2.ru/index.php?option=com_content&task=view&id=416&Itemid=64

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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