Как они помогают нам создавать качественные спецификации

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

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

Давайте посмотрим на пример:

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

Процесс маршрутизации платежа

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

Scenario 1: France
When the card is Visawhen the payment is made the selected gateway is FR_A1.
Scenario 2: FranceWhen the card is Visa, the payment amount is less than 150€ and the payment occurs in saturday selected gateway is FR_A2.
Scenario 3: France
When the card is Visa, the payment amount is greater than 150€
and the payment occurs in saturday selected gateway is FR_A3.
Scenario 4: France
When the card is Visa, the payment amount is greater than 150€
and the payment occurs in monday selected gateway is FR_A3.
Scenario 5: France
When the card is Mastercard when the payment is made the selected gateway is FR_A4.
Scenario 6: France
When the card is Mastercard silver when the payment is made the selected gateway is FR_A5.
Scenario 7: France
When the card is Mastercard and the payment amount is less than 150€ selected gateway is FR_A1.
Scenario 8: USA
When the card is Mastercard and the payment amount is less than 150$ selected gateway is A_USA_1.
Scenario 9: USA
When the payment method is Paypal selected gateway is A_USA_2.
Scenario 10: USA
When the payment method is Paypal but the product is on sale selected gateway is A_USA_3

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

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

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

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

И где другие концепции, такие как риски безопасности транзакций, возможности мошенничества или выбор лучшего способа группировки платежей для снижения комиссий?

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

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

Мы можем использовать разные стратегии, чтобы справиться с этой сложностью:

  1. Создавайте примеры вместе.
  2. Напишите краткий описательный заголовок для каждого примера.
  3. Ищите ключевые понятия.
  4. Делайте примеры простыми и краткими.
  5. Пусть ваши примеры будут видны всем, кто участвует в разработке.
  6. Ищите недостающие понятия.
  7. Ищите границы.
  8. Сгруппируйте по общему функционалу, а затем сосредоточьтесь на вариациях.
  9. Определите приемочное испытание с клиентом для каждого примера.
  10. При необходимости разделите историю на более мелкие.
  11. Игнорируйте примеры, не улучшающие понимание.
  12. Сравните примеры с контрпримерами.
  13. Используйте примеры, чтобы описать, что делать, а не как.
  14. Говорите напрямую с клиентом и избегайте писем, потому что они будут тратить ваше время и усложнять каждое письмо.
  15. Постарайтесь максимально упростить функцию. Неужели так много нужно делать?
  16. Используйте доску или любой другой носитель, чтобы объяснить, что вы поняли, а затем спросите их, правильно ли это.

Вывод

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

Короче, сделайте это просто.

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