Могу ли я использовать диаграмму использования в SCRUM?

Ответ 1

Могу ли я использовать пользовательскую схему UML для представления пользовательских историй в SCRUM?

Диаграмма использования была бы полезна, потому что она довольно проста и дает представление о том, что представляет собой проект на высоком уровне.

Однако я не буду рекомендовать использовать любую другую UML-диаграмму в scrum. Я согласен с другими в том, что в гибком проекте код изменяется настолько часто, что ваши диаграммы будут устаревшими через несколько дней. В этом случае вы должны перерисовать их, что является отходами.

Например, если вы используете eclipse для разработки, простой шаг рефакторинга может испортить вашу диаграмму классов: - (

Какие другие диаграммы могут использоваться в SCRUM?

Я бы предложил использовать mindmaps. Недавно мы начали создавать собственные истории пользователей, рисуя большие карты разума и помещая их на офисные стены.

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

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

На самом деле мы делаем что-то подобное, описанное в этой гибкой статье dzone, но поскольку вы используете scrum not xp + kanban, я рассказывал об истории пользователей а не MMF.

Ответ 2

Вы можете использовать все, что вам нравится в Scrum, что помогает вашей команде эффективно общаться. Scrum не принимает решений, суждений или рекомендаций относительно того, какие инструменты эффективны для этой команды. Он только просит, чтобы вы задумались о инструментах и ​​методах, используемых при выполнении Sprint, и внесите соответствующие изменения. Это цикл проверки и адаптации.

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

Ответ 3

То, что мне сказали от людей, которые использовали Scrum некоторое время (т.е. это мнение), заключается в том, что выполнение диаграмм UML может занять много времени, потому что, поскольку ваша методология разработки гибкая, ваши требования могут очень легко радикально меняются после первого шоу-шоу, и это означает, что вы можете делать довольно большие редизайны.

Конечно, позаботьтесь о том, как вы будете решать свои задачи в резервном портфеле - вы можете, конечно, документировать, как вы идете, но сохранение центрального хранилища диаграмм классов и т.д. может быть небольшим количеством отходов в ресурсах.

Ответ 4

Я не уверен, какова ваша роль в проекте, я полагаю, что вы - ПО. В этом случае используйте дополнительную документацию, если это имеет смысл. Рассмотрите историю пользователей как напоминание о том, что команда провела беседу с ПО.

Если вы считаете, что диаграмма case пользователя разъяснит функциональность, о которой вы просите, это нормально. Фактически, поместите его на стену рядом с таблицей с надписью и выгоранием.

По моему опыту достаточно указать для каждой истории сценарий "как протестировать" . Например, предположим, что у меня есть история для Stackoverflow:

"Как пользователь я могу опубликовать новый вопрос"

Сценарий "как протестировать" может быть:

"Нажмите кнопку" Задать вопрос ", форма отображается с текстовым полем для текста вопроса и текстовым полем для тегов. После того, как пользователь вводит оба параметра - они обязательны - пользователь перенаправляется в список вопросов. пользователь может увидеть заголовок вопроса в списке, а также теги"

Так что, возможно, диаграмма использования не нужна. Я бы рекомендовал попробовать "как протестировать" и посмотреть, как это происходит. Это очень полезно для команды, потому что они знают, что вы ожидаете от истории, с функциональной точки зрения. И вы не будете делать документацию для каждой истории.

Если вам это не нравится, пойдите с диаграммой использования, но неплохо дать команде нечто большее, чем описание истории.

Теперь о технических историях, которые вы упомянули. Кто они такие? Почему техническое требование смешивается с функциональными требованиями? Возможно, это реальное требование для проекта, но обычно это не так и может быть переписано как функциональная история. Если ваш продукт не похож на структуру или библиотеку.

Например, техническая история "создавать индексы для запроса" получить вопросы "может быть переписана как" ускорить страницу списка вопросов ".

Ответ 5

Я использую только диаграммы классов и последовательности с Scrum, потому что эти две диаграммы синхронизируются в реальном времени с кодом Java. Я, конечно, не создаю UseCase или другие диаграммы или даже пытаюсь сгенерировать код из диаграммы (например, MDD), потому что, как только что-то изменилось в моем проекте и моем коде, очень сложно обновить мои диаграммы. Диаграммы должны автоматически обновляться без какого-либо вмешательства человека. Я сделал много проектов с Omondo EclipseUML, и он работал очень хорошо.

Ответ 6

SCRUM - это среда управления жизненным циклом приложения, а не методология, как вы заявили. Пожалуйста, обратитесь к scrum.org

Случаи использования абстрагированы. Если они помогают вашей команде во время изысканности, то здорово. НО, как только ваша команда посвятила эту историю, смена приветствуется, и после ее завершения мало смысла поддерживать их. Цель - всегда удобное для пользователя рабочее программное обеспечение!

Ответ 7

Графики состояний машины UML полезны в Scrum для проектов, ориентированных на изменение дизайна пользовательского интерфейса при сохранении бизнес-логики:

Моделирование состояния машины - это метод динамического моделирования, который фокусируется на определении поведения внутри вашей системы - в данном случае - поведения, характерного для экземпляров одного класса. Мой стиль состоит в том, чтобы нарисовать одну или несколько диаграмм состояний машины, когда класс демонстрирует различное поведение в зависимости от его состояния. Например, класс Address довольно прост, представляя данные, которые вы будете отображать и манипулировать в вашей системе. С другой стороны, объекты семинара довольно сложны, и поэтому имеет смысл создать для них диаграмму состояний.

Ссылки

• UML 2: машинные диаграммы состояний: Agile Введение