Я обычно вижу истории, которые имеют внутреннее и внешнее развитие. Например, рассмотрим большой диалог с несколькими таблицами и некоторыми динамическими элементами управления. Мы сделаем несколько историй (возможно, одну для каждой таблицы и другую для динамической системы управления).
Затем команда разработчиков разделится с одним человеком на бэкэнде и другим на фронтэнде. Это позволяет фоновому специалисту просто беспокоиться о структуре уровня SQL, в то время как интерфейсный специалист фокусируется на таких вещах, как макет. После того, как начальный интерфейс между back-и front-end согласован, разработчики могут сфокусировать свое внимание, чтобы выполнить свою часть к концу спринта.
Затем наступает хаос. Кто "владеет" какой историей? Что означает «в процессе» или «сделано»? Должны ли мы сделать две отдельные истории для back-end и front-end? Если так, разве это не нарушает идею пользовательских историй, основанных на функции? В нашей системе есть понятие «подзадачи», что облегчает некоторые из этих проблем. Но подзадачи добавляют дополнительную сложность. Есть ли способ лучше? Это «плохой» способ использования Scrum?
За последние несколько лет я использовал несколько форм Agile в нескольких местах. У меня пока нет официальной подготовки, поэтому, пожалуйста, прости любую неправильную терминологию или идеологию. Я просто пытаюсь изучить практические способы улучшить наш процесс.
Ответы:
«История» названа так, потому что она представляет собой полную историю с точки зрения клиента. Без внешнего или внутреннего интерфейса клиент не может выполнить ни одного сценария использования.
В вашем случае, я думаю, что и передний и задний план должны быть одной историей. Разделите это на задачи. Разработчики имеют свои разные задачи. Эти задачи могут отслеживаться по отдельности по их этапам: «Выполняется», «Выполнено кодирование», «Выполнено тестирование модуля» и т. Д.
Убедитесь, что вы включили задачи QA в одну и ту же историю - без проверки история бесполезна. QA проверит комплексную историю, которую увидит клиент. Только тогда общая история должна быть помечена как выполненная. В идеальной среде Agile реальный клиент или прокси-клиент также пробует историю в запущенном приложении и помечает историю как принятую, если она соответствует согласованным требованиям.
Если вам нужны более быстрые циклы обратной связи, попробуйте разбить сценарий использования на более мелкие сквозные функции. Например, вместо варианта использования, такого как «Клиент может купить товар с помощью корзины для покупок», разделите его на «Клиент может добавить продукт в корзину» и т. Д. Затем заполните каждый меньший вариант использования. конец в конец, как описано выше.
РЕДАКТИРОВАТЬ: Я хотел бы подкрепить пункты выше с некоторыми источниками. Характеристики хорошей пользовательской истории представлены в сжатой форме под аббревиатурой « ИНВЕСТ ». Он был создан Биллом Уэйком и популяризирован Scrum-движением. Особо обратите внимание на статьи на истории, которые являются независимыми и вертикальными.
Еще немного информации здесь и здесь .
источник
Кто бы ни схватил историю. Они ключ с организационной точки зрения, это один человек несет ответственность за работу. Как только у вас появятся два человека, это слишком просто.
Это зависит. Я видел оба способа работы. Если история достаточно велика, чтобы над ней работали два разработчика, возможно, ее стоит разделить. Если два разработчика являются частью двух разных команд, то, возможно, их следует разделить. Если два разработчика будут работать над ним во время разных спринтов, то, возможно, его следует разделить.
Ключ, который нужно помнить, заключается в том, что этот процесс служит вам, а не наоборот. Пользовательские истории - это способ для технических и нетехнических людей облегчить общение. Они пишут, что им нравится, все договариваются, а затем вы предоставляете обратную связь в истории о ее прогрессе.
Пока процесс работает для вас, это не может быть так плохо.
источник
Там, где мы реализовали модели Scrum, вполне ожидаемо, что в одной истории пользователя могут участвовать несколько разработчиков. Может быть работа над уровнем данных, интеграцией, интерфейсным CSS, инфраструктурой и т. Д. Команда может объединиться для выполнения различных подзадач для истории, чтобы сделать это.
Тем не менее, один человек владеет историей и несет ответственность за обновление ее прогресса и обеспечение того, чтобы все выполнили свою работу и чтобы она работала вместе. Это человек для нас, который сообщает, что история «сделана».
источник
Как и другие, моя команда также делит наши пользовательские истории на задачи. Как правило, это легко сделать, если вы управляете своими пользовательскими историями с помощью программного обеспечения (такого как JIRA или Rally). Тогда легко сказать, какие части истории движутся вместе.
Но альтернативой для задач было бы просто переназначить право собственности, поскольку каждый человек заканчивает свою часть. Таким образом, история распространяется - возможно, разработчик 1 начинает ее с серверной работы, а затем передает ее разработчику 2 для создания пользовательского интерфейса. Затем он передается вашему QA-тестеру для проверки. Этот метод должен хорошо работать в средах, где вы используете настоящие карты на стене или если ваше программное обеспечение не отслеживает задачи.
Но в любом случае, я рекомендую никогда не называть историю «готово», пока команда не согласится, что это сделано, включая тестирование. Таким образом, каждый может внести свой вклад. И если вы объедините это с идеями о коллективном владении кодом и обзорами кода, тогда каждая история действительно «принадлежит» команде в любом случае. Он может быть «назначен» разным людям по пути, но если кто-то отсутствует (больной / отпуск / слишком много встреч? / Другое), работа все равно может быть выполнена.
Моя команда часто принимает пользовательские истории как часть нашей утренней встречи / SCRUM. Таким образом, каждый может легко признать или оспорить, действительно ли это «сделано». В других случаях мы просто позволяем нашему инженеру по контролю качества делать это - если она удовлетворена тем, что он протестирован и работает, и все задачи выполнены, то мы называем это выполненным.
источник
Там, где я нахожусь сегодня, мы называем этот крупный проект «эпическим». Эпос состоит из нескольких историй и может охватывать несколько спринтов / итераций. Для нас история всегда дается одному разработчику и должна соответствовать одному спринту. Одна история затем подразделяется на задачи. Каждая из задач выполняется одним и тем же разработчиком в этой истории. Задачи призваны дать представление о ходе истории во время спринта / итерации. Когда каждая история завершена, каждый разработчик показывает прогресс.
Смысл эпоса в том, чтобы иметь большую цель, которая не обязательно вписывается в один спринт / итерацию. Со временем все истории завершены, и эпопея закончена. Эпосы помещены в выпуск.
Каждую две недели мы демо-код, где истории для этого спринта / итерации должны быть показаны заинтересованным сторонам и утверждены. В этом контексте «сделано» для истории означает, что я могу показать вам, что она делает. Разработчик владеет своей историей и несет ответственность за ее показ (эта часть отчасти упрощена, но достаточно хороша для этого ответа; мы координируем наши демонстрации через одного человека). «Готово» означает, что это может быть успешно продемонстрировано. «В процессе» означает, что у меня есть нерешенные задачи, и история не завершена. Эпос завершен, когда все истории для этого эпоса были успешно продемонстрированы.
Теперь это идеальный случай прогрессии. У нас есть истории и демонстрации, которые терпят неудачу, пользователи, которые хотят чего-то другого, и т. Д. Выше - цель, и по большей части это работает.
источник