Это хорошая идея написать спецификации требований по истории?

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

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

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

Как мы сделали это до сих пор - выбираем самые важные истории в каждом спринте и разрабатываем их в виде ряда формальных спецификаций требований (мы группируем некоторые истории, которые похожи друг на друга в одной спецификации). В зависимости от истории, это может быть просто кнопка на экране или весь рабочий процесс.

Проблема сейчас в том, что из-за того, что существует так много историй, не сразу понятно, для какой части системы какие истории связаны с ней.

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

Является ли написание спекуляций на основе историй хорошей идеей? Мы написали истории неправильно?

Это может быть спорным, но здесь это идет!

Мы работали над системами реального времени, где один из моих прошлых боссов предложил делать AGILE! Это было легко выиграть управление на самом деле; Однако это было легче сказать, чем сделать.

Концепция историй хороша, но, чтобы быть очень искренней, она довольно расплывчата. Что это за история, правда? Реальная проблема заключается в том, что использование историй alone(и почти то же самое относится и к сценариям использования) имеет несколько проблем:

1. Требования не могут быть вне контекста (если вы не делаете грубые повторения так много раз). Существуют предположения, базовые знания и другие требования, которые также связаны с данным требованием; они имеют смысл только в контексте и только в определенном порядке. Реализация самого важного вначале имеет деловой смысл, но, по крайней мере, когда вы подаете их, сохраняйте полную ссылку с самого начала, когда собираете их. Слово «требование» само по себе сложно и не ограничивается прецедентами / историями. Действительно, истории являются действенными, но есть и такие требования, которые могут быть неосуществимыми, такие как производительность, ограничения, которые необходимо соблюдать, бизнес-правила и т. Д.

2. Требования должны соответствовать размеру и количественно, иначе вам никогда не понадобится более 1 большой истории! Что формирует ровно 1 история?

   • это один полный подробный сценарий? (например, одна история, когда банкомат отклоняет транзакцию)
   • это один набор действий, которые выполняет пользователь? (например, полная история о снятии)
   • или это один экран в интерфейсе пользователя? (например, экран вывода в виде полной истории).
   • Как на самом деле измерить очень четкие бизнес-правила с историями? Честно говоря, это может быть любой из вышеперечисленных. Дело в том, насколько вы ограничены и гранулированы, это очень личный стиль. Если это работает - это нормально;

3. Знание предметной области - это действительно требование! Простой пример архитектора, который знает различные свойства стекла, стали и дерева. это знание не является частью документа о требованиях для здания, скажем так! Точно так же, если вы пишете банковское программное обеспечение - существует целый ряд концепций банковского дела. Сформулировав их, каксамо Требование делает его невосприимчивым, потому что оно не говорит вам, что должно делать программное обеспечение, в отличие от того, как устроен мир . Есть ли в истории такие доменные тонкости? или это исключает?

4. Моделирование мира является предпосылкой, не вполне поддерживаемой.
   Было много литературы по моделированию, которая фокусируется на том, чтобы просто понять, как устроен мир, это базовые знания. Моделирование формирует прочную основу, на которой требования приобретают четкое значение; Однако такая вещь должна быть заранее. К сожалению, большинство гибких методов отказывается от первоначального моделирования в интересах более быстрой и более быстрой доставки; но то, что я все еще думаю, - главный ограничитель показа, когда вещи должны масштабироваться. Многие проекты достигают успеха не потому, что моделирование не имеет значения - но опытные инженеры знают их в своей голове и не нуждаются в подробном руководстве.

Итак, подходим к вашему вопросу:

Является ли написание спекуляций на основе историй хорошей идеей? Мы написали истории неправильно?

Я думаю, что пользовательские истории имеют ценность как явный вердикт, данный клиентом. Но если они плохо организованы и недостаточно детализированы (или расплывчаты), возникает проблема. Если у вас нет более широкой структуры для накопления более широкого понимания (знание предметной области) и области действия (общая спецификация). Пользовательские истории только для сегментов или элементов в более крупной такой системе.

PS: У меня есть точное мнение относительно вариантов использования (как они изображены в овальных диаграммах), что если вы не поместите их в соответствующий контекст и с соответствующей детализацией, они не сделают никакой хорошей работы. (Я называю их бесполезными делами ). Единственный надежный источником я нахожу , чтобы сделать использование случаем написания действительно масштабируемым и значимым является написание эффективных Прецедентов по Кокберна

> Writing specs by stories? a good idea?

Да, если вы можете управлять взаимозависимостями и приоритетами своих историй.

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

На момент написания этого ответа я понял, что дело не в тестировании, а в документации. Вы должны сначала прочитать проворный манифест :

[Мы ценим] рабочее программное обеспечение, а не полную документацию

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

Является ли написание спекуляций на основе историй хорошей идеей?

Да, имхо, это так. Это называется «поведенческая разработка» или «спецификация на примере». В рубине есть отличный инструмент огурец, который очень помогает.

Проблема сейчас в том, что из-за того, что существует так много историй, не сразу понятно, для какой части системы какие истории связаны с ней.

Почему вы хотите, чтобы это было понятно? Я имею в виду, вам действительно нужна матрица отслеживания "тест / код"? Преимущество написания тестов в качестве спецификации состоит в том, что вам не нужна отдельная трассируемость «требования / тесты», потому что тесты становятся требованиями. В целях интеграционного тестирования вы должны рассматривать свое программное обеспечение в целом, а не как отдельные части.

Вам может понадобиться инструмент покрытия, чтобы увидеть, есть ли «мертвые» модули, части вашей системы, не охваченные тестами спецификаций. Но вам действительно не важно, какой спецификации соответствует этот конкретный код. Должно быть наоборот: из конкретной спецификации вы должны знать, какая часть системы ей соответствует. Вам не нужно беспокоиться о дублировании ваших спецификаций. И если вы примените принцип DRY к своему коду, будут десятки спецификаций, выполняющих один и тот же код.

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

Нередко сотни интеграционных тестов ломаются из-за одного небольшого изменения в критическом модуле. Вот где начинается модульное тестирование.

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

Мы написали истории неправильно?

Я думаю, вам просто нужно организовать свои истории в эпопею либо по пользователю, например, «Клиент», «Помощник», либо по функциям / экранам / рабочим процессам («Покупка», «Возврат»).

И снова, тесты спецификаций не являются заменой юнит-тестированию. Читать далее

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

Написание спецификаций по рассказам? хорошая идея?

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

Ваш пример показывает две пользовательские истории. Возможно, они как-то связаны с вашей бизнес-логикой, но это очень распространенный сценарий.

Если вам нужно создать функциональность для пользовательских историй, вы можете снова использовать все, что вам больше подходит, включая документацию, некоторые диаграммы или ваши «спецификации», но вы должны быть готовы к тому, что поддержание этих артефактов обойдется вам дороже по мере увеличения сложности разрабатываемого приложения. Таким образом, единственный вопрос, на который вы должны ответить в этом случае: если я не использую свои спецификации, это будет стоить нам дороже? Если ответ «да», вы выбрали лучший вариант.

Гибкая работа лучше всего подходит для небольших и средних проектов с небольшой командой, где вся архитектура хранится как скрытое знание, которым делятся в команде. Во время планирования итерации вы пройдете по выбранным вами историям, обсудите влияние на текущую реализацию и напишите некоторые задачи, необходимые для завершения истории. Реальной документацией в таком случае будет набор тестов, в котором будут проводиться автоматические приемочные и интеграционные / модульные тесты. По мере роста вашего ПО или команды молчаливые знания должны будут частично перейти к некоторой документации.

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

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