Agile-истории и задачи [закрыто]

Question

При разработке серверной системы, какую степень детализации вы обычно придаете своим историям и задачам?

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

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

Answer 1

По сути, я стараюсь поддерживать размер моих пользовательских историй в пределах от 1 до 10 человеко-дней на завершение.Это не позволяет мне передавать разработчикам то, что Майк Кон называет «Эпиками» или «Темами», в качестве пользовательских историй, а с другой стороны, не позволяет моим пользовательским историям быть настолько конкретными, чтобы подразумевать решение (они должны описывать проблему, не то, как это должно быть решено).

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

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

Плохой пример: Добавьте капчу на сайт.

С другой стороны, задачи — это шаги на пути к решению решения — они описывают компоненты и функциональность, которые необходимо добавить/изменить.Здесь на помощь приходит решение «Добавить капчу».Что касается размера, я стараюсь иметь каждый задачаРазмер будет от 1/2 дня до 2-3 дней работы.

Задачи также включают в себя набор стандартных задач, применимых к каждой функции/требованию/проблеме/ошибке, например:

• Документ
• Написание тестовых примеров
• Ручной тест
• Напишите автоматические функциональные тесты и т. Д.

Надеюсь, это поможет, Ассаф.

Answer 2

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

Answer 3

Я основываю истории на общедоступном интерфейсе классов.Для детализации задач я рассчитываю на трудозатраты от полдня до двух дней.

Answer 4

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

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