Проворные истории и задачи
При проектировании серверной системы, какую гранулярность вы обычно даете своим историям и задачам?
Большинство примеров создания историй и задач обычно сосредоточены вокруг приложения с графическим интерфейсом, причем история - это то, что пользователь может сделать (например, поиск книги по ISBN), и каждая задача сосредоточена вокруг включения этой функции графического интерфейса.
При проектировании серверной системы, то есть такой, которая не имеет пользовательского интерфейса, а представляет собой просто набор сервисов, взаимодействующих с базами данных, промежуточным программным обеспечением и т. Д. Как вы решаете задачи и истории?
4 ответа
По сути, я стараюсь, чтобы размер моих пользовательских историй составлял от 1 до 10 человеко-дней. Это мешает мне передавать то, что Майк Кон называет "Эпиками" или "Темами", как пользовательские истории для разработчиков, и, с другой стороны, мешает моим пользовательским историям быть настолько конкретными, чтобы подразумевать решение (они должны описывать проблему, не так, как это надо решать).
Что касается контента, я удостоверяюсь, что мои истории содержат только деловую ценность - он никогда не описывает, как я (должен) удовлетворить спрос, и при этом он не "требует" знаний, не относящихся к пользовательской области, для понимания.
Хороший пример: как менеджер контента, я хочу, чтобы все пользователи должны были войти в систему, прежде чем писать сообщения, чтобы лишить их возможности спама.
Плохой пример: добавьте капчу на сайт.
Задачи, с другой стороны, являются шагами к решению решения - они описывают компоненты и функциональные возможности, которые необходимо добавить / изменить. Вот тут-то и появляется решение "Добавить капчу". Что касается размера, я стараюсь, чтобы размер каждой задачи составлял от 1/2 дня до 2-3 дней работы.
Задачи также включают в себя набор стандартных задач, которые применяются к каждой функции / требованию / проблеме / ошибке, например:
- Документ
- Напишите тестовые случаи
- Ручной тест
- Написать автоматизированные функциональные тесты и т. Д.
Надеюсь, это поможет, Ассаф.
Я основываю истории на общедоступном интерфейсе классов. Для детализации задачи я снимаю за труд от полдня до двух дней.
Пока у вас есть пользователи, пользовательские истории могут быть связаны с тем, что могут делать пользователи. Если вы предоставляете API для других разработчиков, то это ваши пользователи. В этот момент все станет более техническим (т. Е. Пользователь может обновлять записи сотрудников)
Пользователь / субъект может быть системой, а не человеком. Ваши услуги будут иметь API, ожидаемые данные и результаты, а также соглашения об уровне обслуживания (нефункциональные требования). Все это можно указать в карточке истории.
Самое главное, что ваша история должна указывать критерии принятия. Критерии соответствия помогут разработчикам протестировать модульные тесты Deiven Development, автоматизированные функциональные тесты и автоматизированные тесты производительности. Если критерии приемки выполнены, карта принимается и утверждается владельцем продукта.