43
Управление требованиями Эффективная форма постановки ТЗ

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

Embed Size (px)

DESCRIPTION

 

Citation preview

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

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

Эффективная форма постановки ТЗ

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

содержание• зачем эта презентация• что такое «требование», примеры• «user strories» - эффективный способ создавать требования

– Примеры– Атрибуты User strories– Преимущества

• с чего начать (использование подхода на реальном примере) и какой будет процесс

• some fun • использование redmine• чек-листы

Page 3: управление требованиями
Page 4: управление требованиями
Page 5: управление требованиями

Что такое требования

• Ставя задачу, вы выражаете какие-то требования к системе. Например:

• Нужно добавить комментарии к кинотеатрам

• Сделать так, чтобы можно было бы подгружать фото, видео или добавлять текст

• Нужно добавить кнопку «Редактировать» для комиксов

Page 6: управление требованиями
Page 8: управление требованиями

Проблема-то в чем?

• Не всегда понятно, зачем система должна позволять что-либо делать и кому позволять.

• Часто требование уже включает в себе определенное решение по реализации, не всегда оптимальное или приемлемое

• Часто требования описываются в тяжелой для восприятия и понимания форме в виде тяжеловесных спецификаций

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

Размер спецификации

СпецификацияТакая же спецификация, но больше страниц

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

Несущественные детали

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

«user stories» -эффективный способ создавать требования или короткие высказывания о том, как

пользователь будет использовать сайт\систему

Mike Cohn “user stories applied”

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

1. Простой формат, позволяющий понять «кому» и «зачем»

• Как <пользователь>, я могу <действие>, для того, чтобы <цель>

• где<пользователь> - одна из пользовательских ролей;

• <действие> - действие, выполняемое пользователем посредством взаимодействия с системой;

• <цель> - конечная цель текущей задачи, выполняемой пользователем посредством взаимодействия с системой.

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

Примеры user stories

• Как работодатель, я могу добавлять вакансии, чтобы найти сотрудника

• Как соискатель, я могу подписаться на рассылку вакансий, чтобы узнавать быстрее о новых вакансиях

• Как посетитель сайта, я могу просмотреть видеоролик в более высоком качестве.

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

Примеры user stories для singnal.tochka

• Как посетитель, я могу добавить свою новость («сигнал») в виде текста, аудио или видео, чтобы поделиться ею с другими

• Как модератор, я могу предварительно модерировать сигналы пользователей, чтобы не допустить на сайте нелегального или нецензурного контента

• Как редактор новостей, я могу использовать «сигнал» пользователя для публикации новости в новостных лентах портала

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

2. User Story подразумевают их обсуждение с командой для определения всех деталей

• Заказчик не может учесть всех аспектов реализации

• В процессе обсуждения выясняются детали и находятся самые оптимальные решения и реализации

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

3. User strories – автономны, а значит управляемы

• Упорядочивание, группировка и ранжирование по приоритету

• Разбиение более глобальной истории , на две более конкретные истории

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

4. создание историй– процесс цикличный

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

Если писать все требования сразу…

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

Чтобы делать успешный продукт

• Мы принимаем решения на основе той информации которая есть сейчас

• …и делаем это часто

• Вместо того, чтобы делать один раунд принятия решений

• … мы принимаем решения в течении всего жизненного цикла проекта

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

Преимущества user strories

1. позволяет держать фокус всех участников процесса на конечной цели , на бизнес ценности, которую выполнение эту задачи принесет.

2. детализация требований посредством обсуждений дает возможность всем участникам понять суть требований , расширить область поиска решений и, таким образом, принять самые оптимальные и приемлемые решения;

3. Свобода поиска решений и участие в нем всех участников проекта – отличный мотивирующий механизм

4. Автономность user strories дает мощный инструмент управления требованиями и их приоритетами

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

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

Уже есть вопросы?

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

С чего начать (или применение user stories на реальном

примере) и какой будет процесс

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

photobank.tochka.net

предположим

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

workflow

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

Виденье продукта(vision)

• Для (целевой аудитории/заказчик)• Которому нужно (описание нужд или

возможностей)• Имя (продукта) в (категория продукта)• Который (ключевые выгоды, повод

использовать)• В отличие (главное отличие от конкурентов)• Наш продукт (главное преимущество)

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

Vision photobank.tochka.net

• Система для фотографов, дизайнеров, которая бы позволила им хранить и обмениваться фотографиями, а также продавать их в uanete.

Ожидается, что прибыль от системы будет достигаться за счет рекламы третьих компаний, также, возможно, за счет процента с продаж пользователями своих фотографий

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

Определяем роли

• Те, которые хранят и обмениваются своими фотографиями – назовем их «пользователи».

• Те, кто размещают свою рекламу, ориентированную на «пользователей» системы – назовем эту группу «рекламодатели».

• Хотя видение системы явно и не обговаривает задачи по администрированию системы, но так или иначе у системы будут «администраторы», которые будут обеспечивать поддержку системы для блага других пользователей

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

Ролей больше чем на первый взгляд

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

Пишем истории

• 1 Как пользователь я могу добавлять и хранить свои фотографии в системе, чтобы иметь возможность показать или продать их другим пользователям.

• 2 Как рекламодатель я могу помещать свою рекламу в системе, ориентированную на пользователей.

• 3 Как администратор я могу управлять фотографиями пользователей, так чтобы контент сайта был легальным.

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

workflow: встреча с командой

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

Генерим истории с командой• 4. Как гость я могу зарегистрироваться в системе, заполнив

расширенный список полей для получения пользовательской учетной записи, позволяющей продавать фото.

• 5. Как гость я могу войти в систему под ранее созданной учетной записью на tochka.net , заполнив недостающие поля, для последующей работы.

• 6. Как пользователь я могу удалить свою учетную запись и перестать быть пользователем системы.

• 7. Как пользователь я могу изменить данные своей учетной записи.

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

Фиксируем детали, критерии готовности

• 4. Как гость я могу зарегистрироваться в системе, заполнив расширенный список полей для получения пользовательской учетной записи, позволяющей продавать фото.

• Нужен проверенный email и выбранные пользователем имя и пароль. Кроме этого нужны: Полное имя, Адрес, данные кредитной карты …

• Нужны чтобы юзер указал профессию: фотограф и\или дизайнер• Тест 1: пользователь не может ввести пароль меньше 6 символов• Тест 2: пользователь должен иметь уникальный имейл(логин) для всего

портала tochka.net• Тест 3: после регистрации пользователь должен получить имейл для

активизации своей учетной записи• Тест 4: пользователь не может войти в систему, если учетная запись не была

активизирована• ……• Тест Х: при успешном входе система приветствует пользователя текстом

«Добро пожаловать, <имя пользователя>»

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

Оцениваем и ставим приоритеты • 4. Как гость я могу зарегистрироваться в системе, заполнив расширенный список

полей для получения пользовательской учетной записи, позволяющей продавать фото.

• 5. Как гость я могу войти в систему под ранее созданной учетной записью на tochka.net , заполнив недостающие поля, для последующей работы.

• 1. Как пользователь я могу добавлять и хранить свои фотографии в системе, чтобы иметь возможность показать или продать их другим пользователям.

• 3. Как администратор я могу управлять фотографиями пользователей, так чтобы контент сайта был легальным.

• 7. Как пользователь я могу изменить данные своей учетной записи для корректировки измененных или неверных данных.

• 2 Как рекламодатель я могу помещать свою рекламу в системе, ориентированную на пользователей.

• 8. Как пользователь я могу сделать некоторые поля своей учетной записи видимыми для других пользователей.

• 6. Как пользователь я могу удалить свою учетную запись и перестать быть пользователем системы.

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

workflow

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

Передаем Веб-архитекторам

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

Дальше..

• Оценка: Команда говорит сколько она успеет сделать за 2 недели (1ую итерацию)

• Разработка: 1ой итерации• Acceptance&QA Пм делает приемку (на

тестовом) , тестинг• Релиз на продакшен, если 1ая итерация

имеет законченый сет функционала. • 2ая итерация: ПМ готовит следующий сет

историй , встречается с командой снова.

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

workflow

Release Iter. # 1

acceptance

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

Еще раз преимущества user strories 1. позволяет держать фокус всех участников процесса на конечной

цели , на бизнес ценности, которую выполнение эту задачи принесет.

2. детализация требований посредством обсуждений дает возможность всем участникам понять суть требований , расширить область поиска решений и, таким образом, принять самые оптимальные и приемлемые решения;

3. Свобода поиска решений и участие в нем всех участников проекта – отличный мотивирующий механизм

4. Автономность user strories дает мощный инструмент управления требованиями и их приоритетами

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

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

Perfection is a direction, not a place

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

Неудачная спецификация

Спецификация по стандарту IEEE 830:• Продукт должен иметь бензиновый двигатель• Продукт должен иметь 4 колеса – продукт должен иметь резиновые покрышки

на каждом колесе• Продукт должен иметь рулевое колесо• Продукт должен иметь металлический корпус

Источник: The Inmates are Running the Asylum by Alan Cooper (1999)

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

Возможные истории

• Как садовод я хочу подстричь траву, и мой газон будет красивым

• Как садовод, я хочу чтобы мне было удобно, когда я подстригаю траву, и таким образом я бы не уставал

• Как неопытный водитель, я могу цеплять кусты и деревья, таким образом косилка должна быть надежной

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

Результат

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

В презентации, помимо указанных специально, также

были использованы материалы следующих персон:

Henrik KnibergMary Poppendieck

Тим ЕвграшинАлексей Кривицкий