управление требованиями

2,029 views

Published on

Published in: Technology, News & Politics
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,029
On SlideShare
0
From Embeds
0
Number of Embeds
38
Actions
Shares
0
Downloads
68
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide

управление требованиями

  1. 1. Управление требованиями Эффективная форма постановки ТЗ
  2. 2. содержание • зачем эта презентация • что такое «требование», примеры • «user strories» - эффективный способ создавать требования – Примеры – Атрибуты User strories – Преимущества • с чего начать (использование подхода на реальном примере) и какой будет процесс • some fun • использование redmine • чек-листы
  3. 3. Что такое требования • Ставя задачу, вы выражаете какие-то требования к системе. Например: • Нужно добавить комментарии к кинотеатрам • Сделать так, чтобы можно было бы подгружать фото, видео или добавлять текст • Нужно добавить кнопку «Редактировать» для комиксов
  4. 4. • http://projects.dvdev.org.ua/projects/signal/wiki
  5. 5. Проблема-то в чем? • Не всегда понятно, зачем система должна позволять что-либо делать и кому позволять. • Часто требование уже включает в себе определенное решение по реализации, не всегда оптимальное или приемлемое • Часто требования описываются в тяжелой для восприятия и понимания форме в виде тяжеловесных спецификаций
  6. 6. Размер спецификации Спецификация Такая же спецификация, но больше страниц
  7. 7. Несущественные детали
  8. 8. «user stories» -эффективный способ создавать требования или короткие высказывания о том, как пользователь будет использовать сайтсистему Mike Cohn “user stories applied”
  9. 9. 1. Простой формат, позволяющий понять «кому» и «зачем» • Как <пользователь>, я могу <действие>, для того, чтобы <цель> • где <пользователь> - одна из пользовательских ролей; • <действие> - действие, выполняемое пользователем посредством взаимодействия с системой; • <цель> - конечная цель текущей задачи, выполняемой пользователем посредством взаимодействия с системой.
  10. 10. Примеры user stories • Как работодатель, я могу добавлять вакансии, чтобы найти сотрудника • Как соискатель, я могу подписаться на рассылку вакансий, чтобы узнавать быстрее о новых вакансиях • Как посетитель сайта, я могу просмотреть видеоролик в более высоком качестве.
  11. 11. Примеры user stories для singnal.tochka • Как посетитель, я могу добавить свою новость («сигнал») в виде текста, аудио или видео, чтобы поделиться ею с другими • Как модератор, я могу предварительно модерировать сигналы пользователей, чтобы не допустить на сайте нелегального или нецензурного контента • Как редактор новостей, я могу использовать «сигнал» пользователя для публикации новости в новостных лентах
  12. 12. 2. User Story подразумевают их обсуждение с командой для определения всех деталей • Заказчик не может учесть всех аспектов реализации • В процессе обсуждения выясняются детали и находятся самые оптимальные решения и реализации
  13. 13. 3. User strories – автономны, а значит управляемы • Упорядочивание, группировка и ранжирование по приоритету • Разбиение более глобальной истории , на две более конкретные истории
  14. 14. 4. создание историй– процесс цикличный
  15. 15. Если писать все требования сразу…
  16. 16. Чтобы делать успешный продукт • Мы принимаем решения на основе той информации которая есть сейчас • …и делаем это часто • Вместо того, чтобы делать один раунд принятия решений • … мы принимаем решения в течении всего жизненного цикла проекта
  17. 17. Преимущества user strories 1. позволяет держать фокус всех участников процесса на конечной цели , на бизнес ценности, которую выполнение эту задачи принесет. 2. детализация требований посредством обсуждений дает возможность всем участникам понять суть требований , расширить область поиска решений и, таким образом, принять самые оптимальные и приемлемые решения; 3. Свобода поиска решений и участие в нем всех участников проекта – отличный мотивирующий механизм 4. Автономность user strories дает мощный инструмент управления требованиями и их приоритетами 5. Цикличный подход дает конечному пользователю и рынку именно, то что нужно, избегая создания ненужных вещей
  18. 18. Уже есть вопросы?
  19. 19. С чего начать (или применение user stories на реальном примере) и какой будет процесс
  20. 20. photobank.tochka.net предположим
  21. 21. workflow
  22. 22. Виденье продукта(vision) • Для (целевой аудитории/заказчик) • Которому нужно (описание нужд или возможностей) • Имя (продукта) в (категория продукта) • Который (ключевые выгоды, повод использовать) • В отличие (главное отличие от конкурентов) • Наш продукт (главное преимущество)
  23. 23. Vision photobank.tochka.net • Система для фотографов, дизайнеров, которая бы позволила им хранить и обмениваться фотографиями, а также продавать их в uanete. Ожидается, что прибыль от системы будет достигаться за счет рекламы третьих компаний, также, возможно, за счет процента с продаж пользователями своих фотографий
  24. 24. Определяем роли • Те, которые хранят и обмениваются своими фотографиями – назовем их «пользователи». • Те, кто размещают свою рекламу, ориентированную на «пользователей» системы – назовем эту группу «рекламодатели». • Хотя видение системы явно и не обговаривает задачи по администрированию системы, но так или иначе у системы будут «администраторы», которые будут обеспечивать поддержку системы для блага других пользователей
  25. 25. Ролей больше чем на первый взгляд
  26. 26. Пишем истории • 1 Как пользователь я могу добавлять и хранить свои фотографии в системе, чтобы иметь возможность показать или продать их другим пользователям. • 2 Как рекламодатель я могу помещать свою рекламу в системе, ориентированную на пользователей. • 3 Как администратор я могу управлять фотографиями пользователей, так чтобы контент сайта был легальным.
  27. 27. workflow: встреча с командой
  28. 28. Генерим истории с командой • 4. Как гость я могу зарегистрироваться в системе, заполнив расширенный список полей для получения пользовательской учетной записи, позволяющей продавать фото. • 5. Как гость я могу войти в систему под ранее созданной учетной записью на tochka.net , заполнив недостающие поля, для последующей работы. • 6. Как пользователь я могу удалить свою учетную запись и перестать быть пользователем системы. • 7. Как пользователь я могу изменить данные своей учетной записи.
  29. 29. Фиксируем детали, критерии готовности • 4. Как гость я могу зарегистрироваться в системе, заполнив расширенный список полей для получения пользовательской учетной записи, позволяющей продавать фото. • Нужен проверенный email и выбранные пользователем имя и пароль. Кроме этого нужны: Полное имя, Адрес, данные кредитной карты … • Нужны чтобы юзер указал профессию: фотограф иили дизайнер • Тест 1: пользователь не может ввести пароль меньше 6 символов • Тест 2: пользователь должен иметь уникальный имейл(логин) для всего портала tochka.net • Тест 3: после регистрации пользователь должен получить имейл для активизации своей учетной записи • Тест 4: пользователь не может войти в систему, если учетная запись не была активизирована • ……
  30. 30. Оцениваем и ставим приоритеты • 4. Как гость я могу зарегистрироваться в системе, заполнив расширенный список полей для получения пользовательской учетной записи, позволяющей продавать фото. • 5. Как гость я могу войти в систему под ранее созданной учетной записью на tochka.net , заполнив недостающие поля, для последующей работы. • 1. Как пользователь я могу добавлять и хранить свои фотографии в системе, чтобы иметь возможность показать или продать их другим пользователям. • 3. Как администратор я могу управлять фотографиями пользователей, так чтобы контент сайта был легальным. • 7. Как пользователь я могу изменить данные своей учетной записи для корректировки измененных или неверных данных. • 2 Как рекламодатель я могу помещать свою рекламу в системе, ориентированную на пользователей. • 8. Как пользователь я могу сделать некоторые поля своей учетной записи видимыми для других пользователей. • 6. Как пользователь я могу удалить свою учетную запись и перестать быть пользователем системы.
  31. 31. workflow
  32. 32. Передаем Веб-архитекторам
  33. 33. Дальше.. • Оценка: Команда говорит сколько она успеет сделать за 2 недели (1ую итерацию) • Разработка: 1ой итерации • Acceptance&QA Пм делает приемку (на тестовом) , тестинг • Релиз на продакшен, если 1ая итерация имеет законченый сет функционала. • 2ая итерация: ПМ готовит следующий сет историй , встречается с командой снова.
  34. 34. workflow Release Iter. # 1 acceptance
  35. 35. Еще раз преимущества user strories 1. позволяет держать фокус всех участников процесса на конечной цели , на бизнес ценности, которую выполнение эту задачи принесет. 2. детализация требований посредством обсуждений дает возможность всем участникам понять суть требований , расширить область поиска решений и, таким образом, принять самые оптимальные и приемлемые решения; 3. Свобода поиска решений и участие в нем всех участников проекта – отличный мотивирующий механизм 4. Автономность user strories дает мощный инструмент управления требованиями и их приоритетами 5. Цикличный подход дает конечному пользователю и рынку именно, то что нужно, избегая создания ненужных вещей
  36. 36. Perfection is a direction, not a place
  37. 37. Неудачная спецификация Спецификация по стандарту IEEE 830: • Продукт должен иметь бензиновый двигатель • Продукт должен иметь 4 колеса – продукт должен иметь резиновые покрышки на каждом колесе • Продукт должен иметь рулевое колесо • Продукт должен иметь металлический корпус Источник: The Inmates are Running the Asylum by Alan Cooper (1999)
  38. 38. Возможные истории • Как садовод я хочу подстричь траву, и мой газон будет красивым • Как садовод, я хочу чтобы мне было удобно, когда я подстригаю траву, и таким образом я бы не уставал • Как неопытный водитель, я могу цеплять кусты и деревья, таким образом косилка должна быть надежной
  39. 39. Результат
  40. 40. В презентации, помимо указанных специально, также были использованы материалы следующих персон: Henrik Kniberg Mary Poppendieck Тим Евграшин Алексей Кривицкий

×