Истории Пользователей (User Stories) - семинар на AgileUkraine 7, 2009-04-25

6,108 views

Published on

Семинар на тему Историй Пользователя (User Stories) прошел в рамках седьмой конференции AgileUkraine.

Первоначально задуманный как практическое упражнение для 20 человек, он превратился в захватывающую тематическую дискуссию с аудиторией в 50 человек.
Судя по отзывам, участникам было о чем пообщаться.

Published in: Technology

Истории Пользователей (User Stories) - семинар на AgileUkraine 7, 2009-04-25

  1. 1. Управление требованиями в Agile проектах Agile Ukraine Gathering 7 2009-04-25
  2. 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. 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. 4. «Дерево ожиданий» http://www.jacobsen.no/anders/blog/archives/images/project-thumb.jpg
  5. 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. 6. Ужасающая статистика
  7. 7. Если разработчикам дать волю... <ul><li>... они перестанут слушать и учиться понимать нужды заказчика </li></ul><ul><li>«технический жаргон» заглушит «голос бизнеса» </li></ul><ul><li>Качество будет пожертвовано в пользу дополнительных «прибамбасов» </li></ul><ul><li>«Фичи» могут быть реализованы частично </li></ul><ul><li>Будут приниматься решения о функциональности без привлечения заказчиков </li></ul>
  8. 8. Если заказчикам дать волю... <ul><li>Функциональность и даты будут обещаться без всякого учета реалий </li></ul><ul><li>Будут затяжные сессии предварительного сбора требований и их согласования </li></ul><ul><li>По мере наступления «дня Д» будут выкидываться первые попавшие под руку «фичи». </li></ul><ul><li>Мало кто будет интересоваться тем , как хорошо разработчики понимают нужды заказчика </li></ul>
  9. 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. 10. Чтобы быть Agile ... <ul><li>Мы принимаем решения на основе той информации, которая есть сейчас </li></ul><ul><li>Вместо того, чтобы делать один раунд принятия всех решений </li></ul><ul><li>... и мы делаем это часто </li></ul><ul><li>... мы принимаем решения в течении жизни всего проекта </li></ul>При таком подходе, нам необходим простой инструмент работы с требованиями Истории Пользователя ( User Stories) помогут нам
  11. 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. 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. 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. 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. 15. Детали как более мелкие Истории <ul><li>Как пользователь, я хочу отменить резервацию </li></ul><ul><li>Как Премиум пользователь я могу отменить резервацию вплоть до последней минуты </li></ul><ul><li>Как Не Премиум Пользователь я могу отменить резервацию минимум за 24 часа </li></ul><ul><li>Как посетитель сайта я хочу получить по e-mail уведомление об отмененной резервации </li></ul>
  16. 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. 17. Жизненный цикл историй
  18. 18. Концепция продукта / релиза <ul><li>Концепция - несколько предложений, описывающих идею, цели, ожидания </li></ul><ul><ul><li>Основа для понимания кто и как будет использовать продукт </li></ul></ul><ul><ul><li>Основа для расстановки приоритетов и планирования релизов </li></ul></ul><ul><ul><li>Постоянное напоминание о целях и инструмент поддержания фокуса команды и всех заинтересованных лиц </li></ul></ul>
  19. 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. 20. Айсберг требований
  21. 21. Истории, Темы и Эпосы
  22. 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

×