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

Плюшки управления требованиями в гибких методологиях разработки в том, что изменения требований максимально приветствуются на любой стадии разработки проекта (=фичи). Инструменты управления требованиями в Agile (сбор, анализ, приоритезация, верификация) заточены под постоянное внесение изменений в требования к продукту, прототипирование и быстрое внедрение на прод для получения фидбэка.
Предполагается, что с первого раза невозможно “угадать” потребности пользователей поэтому нужно уметь быстро доставлять фичи на прод (для проверки концепций) и быстро модифицировать функциональность не зарываясь при этом в техническом долге.

Терминология:

1. Проект – процесс по созданию продукта (=фича).
   • Имеет четкое начало и конец, т.е. ограничение по времени. Время выполнения проекта может быть хоть один день, хоть два года. У нас чаще всего – это “пока не сделаем” или “не устанем делать”, но вот такой у нас time management:).
   • Ограниченный функционал (функционал может уточнятся/ изменяться на каждой фазе (=итерации) проекта).
2. Продукт – некий функционал, который доступен пользователю.

1. Бизнес требования

На этом этапе принимается решение влазим мы в проект (= разработку фичи) или нет. Для этого кратко указываются общие цели проекта, накидываются альтернативные возможности и препятствия. В нашем случае на сбор этих требований тратится минимум времени 2 – 3 часа, но это позволяет уточнить видение и цель проекта(=фичи) и прикинуть обходные пути.

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

Бизнес требования (Устав проекта по PMI, Project Vision)

Для чего: бизнес требования выводятся непосредственно “заказчиком” продукта, в нашем случае это учредители компании или менеджер. Бизнес требования это некое видение продукта (=фичи), концепция (которая конечно может и будет корректироваться после релиза продукта). Некая идея, почему мы вообще собираемся вбухать время, силы и деньги в текущий проект. А так же очень общее направление работы для команды продукта куда развивать проект.

• Обоснование проекта. Зачем нужен проект. Желательно по SMART (Specific, Measurable, Attainable, Relevant, Time-related – https://en.wikipedia.org/wiki/SMART_criteria). Полезно иметь некую цель, чтобы можно было постфактум проанализировать что в итоге получилось сделать, что пошло не так и какие предположения были не верны в начале. Такой подход позволяет давольно быстро набирать опыт и накапливать экспертные знания.
• Возможные альтернативные цели проекта. В случае, если проект “забуксует” в одном из направлений всегда можно будет переключится на альтернативное.

Бизнес правила (Ограничения проекта по PMI)

• Privacy Policies (Пример: обработка и хранение персональных данных )
• Brand Uniformity requirement (Пример: Единый стиль оформления VL.ru, из за несоблюдения этого правила каждый новый дизайнер рисует новый вид влрушечки и в итоге у нас вакханалия в проектах)
• Government Regulation (Пример: ограничения на рекламу табака, хранение паспортных данных)
• …

2. Пользовательские требования

Пользовательские требования это требования конечных пользователей продукта (End Users) к разрабатываемому продукту.

Инструменты для представления требований Agile:

Use Case (Use Case Diagram)

Концепт был разработан в 1982 Иваром Якобсоном и значительно популяризирован Алистером Коберном. Способ определения, уточнения и организации деталий задачи.
Элементы :

• Название пользовательского сценария
• Актеры (роли)
• Цель
• Триггеры – то что позволяет сценарию начаться. Например: нажатие кнопки.
• Предусловия (pre-conditions) – условия, которые должны быть выполнены перед тем, как случится условие
• Постусловия (post-conditions)
• Основной сценарий – “Sunny Day” scenario. Сценарий когда все идет “как надо”.
• Альтернативные сценарии
• Исключения
• Параметры (qualities).

Литература:

• Use Case Examples – Effective Samples and Tips
• Use case definition – ссылки на подробные описания
• Алистер Коберн – Современные методы описания функциональных требований

Wireframes (mockups)

Визуальное представление продукта. Только основные элементы и общие наброски, что – где будет располагаться. Некоторые источники говорят, что мокапы – это тоже, что и ваерфреймы. некоторые их разделяют. В мокапах больше интерактива.

Литература

• A Beginner’s Guide to Wireframing
• Examples of wireframes on Tumblr
• Мы используем Wireframe Sketcher.

Story Boards

В нашем случае (мое мнение) очень избыточная практика. Обычно используется для презентации проекта заказчикам или для генерации идей. Визуализирует прохождение по “sunny day” сценарию.

User Stories (Story Maps)

Простой способ для представления требований к системе. Благодаря определенной форме все требования приводятся к единому формату. Их легко писать, легко читать, легко оценивать и прериотизировать.

Формат описания: Как ______, я хочу ____,   для того чтобы _____ .

Как ________ роль для кого применяется это требование “кто?” (пример: авторизованный пользователь; модератор; менеджер билетов онлайн; бухгалтер)_____________,
Я хочу _______ задача или функция которую хотят сделать  “что?” (пример: видеть список идущих сегодня фильмов в порядке популярности; ) ___________,
Для того чтобы _______ указываем цель, зачем эта пользовательская история вообще нужна “зачем?” (пример: я могу быстро выбрать куда сходить в кино)________________________.

Story #1 Как водитель с загоревшейся лампочкой я хочу просмотреть все ближайшие заправки, чтобы найти более удобную в данный момент.Epic: Как водитель с загоревшейся лампочкой бензина я хочу быстро найти ближайшую хорошую заправку, чтобы заправиться качественным бензином.

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

Проверка качества написанной истории (Bill Wake)

INVEST

• Independent (Независимая) – нужно следить, чтобы истории были независимы друг от друга, чтобы можно было реализовать каждую отдельно от остальных. Это позволяет выкинуть любую историю из спринта или изменить порядок выполнения историй.
• Negotiable (Обсуждаемая) – должна быть достаточно общей, чтобы команда могла предлагать реализации, подходы и решения.
• Valuable (Полезная) – должна добавлять ценность проекту, чтобы команда не делала всякой бесполезной фигни.
• Estimable (Оцененная) – должна быть возможность оценить сколько реализация займет времени. Если нельзя сказать за сколько история будет реализована, значит это скорее всего не история, а эпик (Epic). И его можно побить на меньшие истории, которые уже можно оценить.
• Small (Компактная) – даже если мы смогли оценить историю в 3 месяца, это не значит, что она маленькая. Небольшие куски значимого функционала легче оценивать, деплоить и быстрее собирается фидбэк.
• Testable (Тестируемая) – обычно покрывается приемочными тестами.

Epic – большой кусок функционала, который невозможно сделать за относительно короткий период времени (например неделю). Обычно появляются вначале разработки фичи, дальше дробится на истории.

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

Testable / Definition of Done / Acceptance Tests

Приемочные тесты служат для проверки, что требования выполняются и для проверки адекватности пользовательской истории. Критерии приемки (acceptance criteria) пишутся на основе пользовательских историй и служат для уточнения требований к системе.

Пользовательская история #1: Как пользователь, я хочу ввести данные моей банковской карты (Visa или MasterCard), чтобы оплатить билеты удобным способом.

Критерии приемки (Acceptance Criteria):

1. Оплата может производится карточкой Visa
2. Оплата может производится карточкой Master Card
3. При вводе номера карты, тип карты должен вычисляться автоматически
4. Пользователь должен видеть только поля соответсвующие выбранному методу оплаты

Приемочные тесты для критерия приемки #1 (Acceptance Tests):

• Ввести данные карты Visa в поля ввода
• Ввести 3ds код
• Подтверждение, что оплата поступила
• и т.д.

3. Функциональные требования

Behaviour that product should do or support. Поведение, которое продукт должен выполнять и поддерживать. https://en.wikipedia.org/wiki/Functional_requirement

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

Information Flow Diagram (http://myyee.tripod.com/cs457/dfd.htm)

4. Не функциональные требования (Сорт продукта, управление качеством по PMI)

“How well” a product must perform. Как хорошо продукт должен выглядеть и функционировать. Доп. требования к функциональным требованиям. Функциональные требования – что должен делать продукт, не функциональные – как хорошо продукт должен это делать.

• Accuracy Requirements – точность вычислений, параметров, сенсоров. Пример: вычисляя сумму мы должны округлять до N знаков запятой,
• Dependability Requirements  – система логирования изменений при редактировании событий на Афише.
• Security Requirements
• Usability Requirements
• Efficiency Requirements – приложение, навигатор по городу не должно жрать батарейку и должно позволять использовать навигатор N часов без подзарядки (Space, Time, Power, Resource ).
• Performance Requirements – response time, hitrate
• Maintainability Requirements – требования к расширяемости превоначального функционала.

5. Дополнительные требования

External Interface Requirements – если продукт является частью большой системы, то требования к внешним интерфейсам позволяют обозначить как продукт взаимодействует с другими системами. Например: Продукт “Продажа билетов в кино на kino.vl.ru”, является частью системы в которую входят сервера кинотеатров и театров, платежные системы, биллинг барахолки, тикет система VL.ru, конечные пользователи, операторы call центра и так далее.  (Примеры инструментов для описания: Data Flow Diagram, System context diagram)

Physical Setting Requirements – Считывания штрих кода на билетах для приложения контроллер должно быть возможно в темных подвальных клубах со стробоскопами, громкой музыкой и нестабильной связью.

Development Constraints – технологии, конвенции, стандарты и процесс. Например: мы используем фреймворк Symfony2 для разработки новых продуктов.

6. Управление качеством требований

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

If you want to elicit business requirements

• What problem are you trying to solve?
• What’s the motivation for solving this problem?
• What would a highly successful solution do for you?
• What’s a successful solution worth?
• Who could influence this project?
• Who could be influenced by this project?
• Are there any related projects to this one?
• Which activities should be included in the scope?
• Could there be any unintended consequences of the new system?

If you want to to elicit business rules

• What policies must the product conform to?

If you want to elicit user requirements

• What goals could this product help you accomplish?
• What problems do you expect this product to solve?
• What words would you use to describe the product?
• What aspect of the product excites you?
• What aspects are most/least valuable to the users?

If you want to elicit non-­functional requirements…

• What qualities (e.g., efficiency, security, reliability, etc.) are critical for the specific parts of the product?

If you want to elicit external interfaces features…

• What events must the product respond to?
• Can you describe the environment in which the product will be used? If you want to reveal exception conditions…
• Would anyone ever want to …?
• Could … ever occur?
• What should happen if …?

If you want to reveal more constraints…

• What is most important to you about the product?
• How would you judge whether the product is a success?
• How should the product be different from the way things are done now?
• Is there anything else we should be asking you?

If you want to dig to reveal assumptions, rationale, real needs…

• Please could you help me to understand why …? ○ e.g., why something applies, is relevant, is really required, is high priority, is the way it is, etc. 

Признаки качественных требований

• Correct – пользовательские истории должны описывать тот функционал, который нужен.
• Complete – должны быть учтены все необходимые требования. Для проверки удобно использовать Story Maps
• Clear – историю легко понять и она имеет только одну интерпретацию. Для проверки требований используется Requirements Technical Review and Repair или Wireframes.
• Consistent – требования не должны противоречить друг другу.
• Verifiable – должны быть тестируемы и проверяемы с достижимой целью.
• Feasible – история должна быть возможна для реализации доступными команде технологиями, инструментами и навыками.
• Traceable – только необходимый и достаточный код будет написан для каждой истории и функционал будет протестирован.
• Manageable – каждый элемент требований (пользовательские истории) может быть изменен не влияя на другие элементы. Не достижимо, но стоит стремиться. Решение: треччить зависимости пользовательских историй.
• Simple – без ненужных деталей реализации и не перегружены предлагаемыми решениями проблемы. Пользовательские истории служат для определения “что” за фичу нужно реализовать, но не “как” она должна быть реализована.

Слова для выявления неопределенности в формулировке требований:

• Количество. Пример: Как пользователь, я хочу купить билет, чтобы сходить в кино. Вопросы: один пользователь может купить только один билет?
• До / после / следующий. Пример: “как пользователь я могу удалить последний комментарий, чтобы…” -> “как пользователь я могу удалить последний созданный мною комментарий, …”
• Все / никто
• И / или. Пример: Как модератор, я хочу иметь возможность удалить комментарий и заблокировать пользователя, чтобы комментарии не соответствующего содержания не появлялись на сайте. Вопрос: это два отдельных действия? или при удалении нужно блочить пользователя.
• Оба / каждый

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

• Creating a lean, mean requirements machine from Atlassian
• Four techniques for defining project scope
• Business Requirements vs. Functional Requirements
• Agile PMO – сравнение гибких и классических методологий
• Ambiguous-Requirements-Checklist.pdf – пример чеклиста для требований на анлийском, из которого можно получить представление как пишутся требования.
• Информационный стиль в написании текстов – сайт Ильяхова, он больше заточен под продающие тексты, но идею и принципы оттуда можно почерпнуть. И, на сколько я знаю – это лучшее, что есть на русском.