Пользовательские истории имеют смысл для бизнеса. Вот почему мы всегда пытаемся формулировать их просто, чтобы пользователь все понимал и не углублялся в технические дебри.
Это не означает, что при создании наших систем мы не можем использовать объединенное подключение или образцы проектирования. Это означает, что такие детали нужно излагать словами, понятными клиенту.
Вторая характеристика по-настоящему хорошей пользовательской истории заключается в том, что она описывает систему на всех уровнях, так сказать, «прорезает программу по всей толщине».
Большинству сладкоежек не понравится, если от торта им достанется только бисквит, без крема. Так и клиенту не хочется получать всего половину или треть решения. Вот почему хорошая пользовательская история является комплексной, затрагивает все уровни архитектуры приложения и действительно имеет ценность.
Кроме того, хорошие пользовательские истории имеют следующие характеристики:
При реализации проектов обстановка меняется. То, что на прошлой неделе казалось очень важным, на этой неделе становится второстепенным. Если все пользовательские истории тесно взаимосвязаны и зависят друг от друга, компромиссы становятся довольно сложным делом.
Такое разделение не всегда удается (прежде чем создавать отчеты, нужно написать программу), но послойное препарирование историй и собирание пожеланий по конкретной функции позволяет считать абсолютное большинство историй независимыми и при необходимости корректировать функционал приложения.
Любую отдельно взятую историю всегда можно реализовать несколькими способами. Мы можем выполнить любую возможность в версиях, условно соответствующих «Форду-Фокус», «Хонде-Аккорд» и «Порше-911».
Истории, которые клиент готов обсуждать, хороши потому, что предоставляют нам поле для маневра, которое иногда очень требуется, чтобы уложиться в бюджет. Иногда обязательно нужен «Порше». В других случаях можно обойтись более непритязательным «Фордом».
Хорошо, если пользовательские истории поддаются тестированию (в противном случае их называют нетестируемыми (detestable)). Ведь мы должны знать, когда функция работает, а когда – нет. При написании тестов на основании пользовательских пожеланий мы даем ориентиры нашей команде разработчиков и помогаем понять, когда определенная функция готова.
И, если говорить о готовых функциях, как гарантировать, что конкретную историю удастся реализовать за отведенное нам время? Чтобы сроки соблюдались, истории должны быть краткими (каждая – не более чем на пять дней работы). Так с ними будет легко работать в течение недельных или двухнедельных итераций, и наши оценки будут более уверенными.