Давайте рассмотрим простую историю для экрана аутентификации пользователя:
Как пользователь,
я хочу иметь возможность войти в систему со своим именем пользователя и паролем
, чтобы я мог делать xyz.
Это выглядит хорошо, но все детали, связанные с тем, что должно произойти, когда пароль неверен, сколько повторных попыток должно быть разрешено, проверки и куча других вещей, которые должны быть в этой истории, отсутствуют.
Куда должна поступать вся эта информация в гибкой настройке Scrum? Это FRS (или любой другой эквивалентный монолитный документ, содержащий подробную информацию обо всех функциональных спецификациях)? Если да, учитывая, что таких крошечных историй будут сотни или тысячи, как должны синхронизироваться ссылки на соответствующие им разделы FRS? Как лучше всего управлять таким уровнем детализации в гибком мире Scrum?
Вы в основном попали в цель пользовательских историй. Видите ли, пользовательские истории возникли, когда у нас были большие документы с требованиями, в которых были все детали, которые могли понадобиться команде разработчиков для разработки программного обеспечения. Проблема в том, что для документирования этих деталей требуется много времени, и оказывается, что они часто не то, что хочет пользователь (или, по крайней мере, не попадает в цель). Теперь все это время потрачено впустую. Вместо этого мы пишем пользовательскую историю, которая дает нам достаточно информации, чтобы поговорить с человеком, который ее написал. Команда разработчиков может задавать вопросы и лучше понимать свои потребности, а затем создавать то, что им соответствует. Они будут где-то писать свои заметки, и в зависимости от вашего приложения может даже иметь смысл хранить их в особом месте. Так, цель пользовательских историй заключалась в том, чтобы уйти от монолитных документов и перейти к личным беседам. Если вы привязываете пользовательскую историю к деталям в большом документе с требованиями, вы убираете ценность пользовательских историй.
Краткий ответ заключается в том, что вы этого не сделаете. Масштабное предварительное планирование несовместимо с гибкой разработкой. Вместо этого вы должны сосредоточиться на итеративной и поэтапной разработке с жесткими циклами обратной связи, чтобы убедиться, что вы создаете правильные вещи и принимаете изменения на протяжении всего жизненного цикла проекта.
Выполнение подробных или крупномасштабных требований в начале проекта — анти-паттерн Agile. В частности, ценности «Манифеста гибкой разработки программного обеспечения »:
Рабочее программное обеспечение над исчерпывающей документацией[.]
Точно так же теория Scrum явно избегает использования фиксированного предварительного планирования:
Scrum использует итеративный, поэтапный подход для оптимизации предсказуемости и контроля рисков.
Хотя ничто не мешает вам связать пользовательские истории или другие типы Элементов Бэклога Продукта с функциональными требованиями, это часто является «запахом проекта», который вы фиксируете в объеме, который в идеале является подвижной частью Железного Треугольника в Scrum. Кроме того, это часто указывает на то, что вы слишком рано принимаете решения о внедрении. Бережливые практики требуют, чтобы вы принимали архитектурные и дизайнерские решения в последний ответственный момент , что почти никогда не бывает в самом начале проекта, когда обычно собираются спецификации функциональных требований.
В среде Scrum вы должны использовать ее для выполнения планирования «точно в срок» с надлежащим уровнем детализации. В частности:
Хотя Scrum и не требует этого, гибкие методы обычно требуют интеграции проектирования на основе тестирования или разработки на основе поведения (часто в сотрудничестве с заинтересованными сторонами или клиентами), чтобы гарантировать, что любые функциональные требования, относящиеся к текущей итерации, четко определены и поддаются тестированию . Этот тип «живой документации» часто бывает более полезным, более точным, удобным в сопровождении и более эффективным, чем обычные документы с функциональными требованиями.
Я думаю, что часть проблемы заключается в том, что это:
войти с моим именем пользователя и паролем
не является требованием. Это выбор дизайна, маскирующийся под требование. Настоящим требованием является что-то вроде: «Как пользователю мне нужно (безопасно и уникально) пройти аутентификацию в системе, чтобы я мог…» Выбор имени пользователя и пароля немедленно исключает другие, более простые средства аутентификации. Уже вошли в Active Directory/G Suite/Office 365/другого поставщика Oauth? Можем ли мы это использовать? А как насчет распознавания лиц и отпечатков пальцев? Этого достаточно?
Помните об этом, когда будете просматривать свои пользовательские истории. Они говорят вам , как что-то должно быть сделано вместо того, что нужно сделать? Довольно часто это нормально; они расширяют/уточняют более ранние варианты дизайна. Но иногда стоит сделать шаг назад, спросить себя, какую проблему они действительно решают, и есть ли лучший способ?
Как говорят другие, детали должны быть прояснены в последний ответственный момент, иногда в момент реализации в тесном сотрудничестве между разработчиками и, например, деловыми людьми или экспертами по UX. Тем не менее, конкретная информация может быть указана в качестве критерия приемлемости. Более общие и повторяющиеся критерии могут быть лучше помещены в определение «Готово» команды (или организации).
Для критериев приемки вы также можете взглянуть на синтаксис, такой как Gherkin , и вы можете захотеть автоматизировать тестирование с помощью таких вещей, как Cucumber , в качестве живой, более полезной документации и базы для регрессионного тестирования.
«Сколько повторных попыток должно быть разрешено, проверок и кучи других вещей, которые должны быть включены в эту историю, отсутствуют. Где вся эта информация должна находиться в гибкой настройке Scrum?»
Вот почему у вас есть критерии приемлемости .
Но мне кажется, у вас другая проблема: кто написал ваш ФРС? Зачем вы сделали эти инвестиции, если знали, что это будет гибкий проект? В Agile команда решает технические детали. Если вы внимательно прочитаете agile-манифест, то увидите, что это разработчики призывают к революции.
Тодд А. Джейкобс