Пользовательская история (user story) содержит описание функциональности которая будет представлять ценность для пользователя или покупателя программного продукта. Концепция пользовательской истории охватывает три аспекта:
Пользовательские истории:
INVEST
Уже написанные истории впоследствии можно обсуждать и вносить в них изменения. Истории не являются формальными требованиями, которые программное обеспечение должно реализовать. Карточки историй - это краткие описания функциональности, детали которых должны уточняться в ходе устных обсуждений между командами заказчика и разработчиков.
Поскольку карточки историй призваны лишь напоминать нам о том, что еще подлежит дальнейшему обсуждению, и вовсе не обязаны содержать подробное изложение требований, их не следует излишне перегружать деталями.
Но если в ходе составления истории вам стали известны какие-то важные подробности, их можно включить в карточку истории в виде примечаний. Вся трудность состоит в том, чтобы научиться ограничивать себя лишь минимально необходимым уровнем детализации.
Но если в историю включено избыточное количество детальных описаний, то ее обсуждение может восприниматься как конкретное и максимально исчерпывающее. Это может создать ошибочное впечатление.
Детали, уже прошедшие обсуждение, становятся тестами. Тесты могут записываться в виде примечаний на оборотной стороне карточки истории, если она бумажная, или сохраняться в любой ее электронной версии, если она используется.
Существует соблазн сказать нечто вроде "Каждая история должна представлять определенную ценность с точки зрения пользователей". Но такое утверждение было бы неверным. Многие проекты включают истории, не представляющие для пользователей никакого интереса.
Чего следует избегать, так это историй, которые имеют ценность только в глазах раз-работчиков. Примеры подобных историй приводятся ниже:
Примеры того как плохие истории превратить в хорошие
Важно, чтобы разработчики были в состоянии оценить (или, по крайней мере, обоснованно спрогнозировать) размер истории, т.е. количество времени, которое понадобится для того, чтобы превратить историю в работающий код.
Существуют три основные причины, по которым трудоемкость истории может не поддаваться количественной:
В методологии экстремального программирования такая исследовательская история называется спайком (spike). Полученных в процессе выполнения спайка дополнительных сведений разработчикам должно быть достаточно для того, чтобы суметь оценить трудоемкость предстоящей задачи. Эксперимент всегда ограничивается фиксированными временными рамками, что позволяет присвоить ему количественную оценку. С учетом всего вышесказанного не поддающаяся оценке история преобразуется в две: историю, описывающую проведение быстрого исследования для сбора информации, и историю, соответствующую реальной работе.
Пользовательская роль (user role) - это собрание описательных атрибутов, характеризующих некоторую совокупность пользователей и предполагаемые типы их взаимодействия с системой.
Чтобы определить пользовательские роли, заказчик и как можно больше разработчиков собираются в одной комнате, где в их распоряжении будет большой стол или стены, на которые можно наклеивать или прикалывать кнопками карточки историй. Будет идеально, если в процессе моделирования пользовательских ролей в начале проекта принимает участие вся команда, однако это необязательно. Коль скоро наряду с заказчиком собралось достаточно представительное количество разработчиков, собрание может пройти успешно.
Объединение ролей
Уточнение
В книгах о требованиях при описании методов их определения используются понятия выявление (elicitation) и фиксация (capture). Это подразумевает, что сами по себе требования объективно существуют, но находятся вне нашего поля зрения. Нужно лишь попросить, чтобы нам их разъяснили, а затем зафиксировать их. Однако, требования не витают где-то в пространстве проекта в ожидании появления того, кому они нужны, а рассчитывать на то, что все требования уже известны пользователям и нам остается лишь выявить их, также не приходится.
Поскольку истории появляются, развиваются и исчезают, нам необходим набор методов их сбора, который бы мог работать в итеративном подходе. Методы должны быть простыми, чтобы можно было их применять непрерывно.
Эти методы:
PS: в 2004 году держать связь с реальными пользователями было сложнее, поэтому, хотя здесь даются советы по тому как обходиться без пользователей, в современную эпоху интернета не общаться с пользователями - великая глупость.
Для проекта жизненно важно, чтобы в состав команды заказчика входил хотя бы один реальный пользователь. В то время как другие люди могут лишь догадываться о том, какое поведение программного обеспечения было бы желательным для пользователя, достоверно об этом знает только он сам. В тех случаях, когда организовать обсуждение продукта с нужными пользователями не удается, мы вынуждены привлекать уполномоченных представителей пользователей (user proxies), которые, сами не являясь пользователями, все же могут представлять их интересы в проекте.
У каждого вида представителей пользователей есть свои минусы. Поэтому их нужно комбинировать.
Целесообразно установить связь с реально работающими пользователями. Лучше всего это сделать, создав специальную пользовательскую группу (user task force). В эту группу может входить произвольное число реальных пользователей - от небольшого их количества до двух десятков человек. Любые идеи отрабатываются на этой группе, но окончательное решение остается за представителем пользователей. Такая группа создаст своего рода "подушку безопасности", защищающую от принятия неверных решений.
Написание приемочных тестов (acceptance tests) - способ выразить в концентрированном виде детали, выясненные в результате обсуждений истории. Вместо составления длинных списков требований к проекту для наполнения пользовательских историй деталями используются тесты.
Тестирование лучше всего представлять в виде двухэтапного процесса.
История должна обеспечивать определенный уровень сквозной функциональности. Любая история должна содержать хоть немного от каждого уровня.
Если история содержит все слои пирога:
ps: Весь раздел очень странный даже для того времени. В текущих же реалиях выглядит совсем дико. Однако некоторые базовые понятия применимы и сейчас.
Согласно центральной предельной теореме теории вероятностей, сумма достаточно большого количества независимых, одинаково распределенных случайных величин приблизительно описывается законом нормального распределения
Вместе со смещением акцентов от письменной документации к устному обсуждению приходит свобода действий, рожденная осознанием того факта, что ничто не может быть истиной в последней инстанции. Документы, подготовленные в виде контрактов, воспринимаются как нечто незыблемое. Иное дело обсуждения. Если сегодня мы все обговорили, а месяц спустя узнали нечто новое, мы возобновляем обсуждение.