Гибкое управление проектами и продуктами. Борис Вольфсон

      История пользователя для авторизации на сайте

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

       Подробное описание – текстовое и графическое описание истории пользователя. Применяется прежде всего в распределенных командах для хранения знаний о функционале продукта.

       Демонстрация – достаточно подробный сценарий, позволяющий провести демонстрацию истории пользователя. Например, для приведенной выше истории пользователя с авторизацией можно использовать следующие краткие сценарии для демонстрации:

      ♦ пользователь вводит логин root и пароль pass и переходит на страницу личного профиля на сайте;

      ♦ пользователь вводит логин root и пароль wrongpass и получает сообщение Введен неправильный логин или пароль.

       Категория – используется для повышения управляемости с помощью категоризации задач. В качестве категорий могут выступать как продуктовые категории (темы и эпики в терминологии Scrum), так и категории типа «оптимизация производительности», «техническая история» и т. п.

      Размер журнала пожеланий и стратегическое планирование

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

      Противоречие между тактическим и стратегическим планированием

      Какой бы размер журнала пожеланий мы ни выбрали, все равно не получится разрешить конфликт – нужно прорывное решение. Оно достаточно просто и лежит на поверхности: использовать метод набегающий волны. В рамках Scrum такой подход означает, что мы разбиваем очень подробно истории пользователей на несколько ближайших спринтов, а остальные истории пользователей храним в виде больших фрагментов функциональности, подробно не описывая их. Такие большие истории пользователей, которые в дальнейшем будут разбиты на маленькие, называются эпиками (epic).

      Более важные элементы журнала пожеланий определены точнее

      Как видите, чем позднее планируется реализация того или иного функционала, тем более крупные фрагменты функционала берутся. Отмечу, что это также согласуется полностью с принципами KISS (Keep it simple, stupid – «Не усложняй, тупица») и YAGNI (You аin’t gonna need it – «Вам это не понадобится»).

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

      • рефакторинг модуля;

      • оптимизация производительности;

      • исправления сложного дефекта;

      • настройка инфраструктуры.

      Технические истории крайне желательно вносить в журнал пожеланий, чтобы