Scrum. Работа с низкоприоритетными историями, которые приведут к изменению архитектуры

Сегодня в университете у нас было упражнение Scrum (имитация всего процесса создания программного решения), и я придумал проблему, которая не могла понять.

Скажем, мы определили наши истории и дали им правильную приоритизацию. И есть история с очень небольшим приоритетом... возможно, это будет сделано в последние спринты.

Проблема в том, что, если эта история представляет собой огромную архитектуру для нашего решения? Например, из автономного приложения вам придется перейти на архитектуру клиент-сервер из-за этой истории.

В моей точке зрения: не естественно ли каким-либо образом указывать, какие истории наверняка будут сделаны (в какой-то конкретный момент времени), те, которые необходимы для совершения, но это не критично, когда чтобы они имели в виду и принимали лучшие решения, разрабатывая свое решение. Или как вы справляетесь с этой проблемой? Если это проблема.

Спасибо заранее! И извините мой, наверное, хромой вопрос.

Ответ 1

Потому что вы сказали:

выполненный последними спринтами, возможно.

Я склонен соглашаться с нечетким леденец (и +1 от меня).

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

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

Ответ 2

в реальном мире с $$$ на линии, вещи, которые получают низкий приоритет, вероятно, никогда не будут выполнены. И если у них есть высокий фактор риска, который в реальном мире означает еще больше $$$ с риском и низким приоритетом, они не будут сделаны наверняка. В вашем случае, если вы знаете, что это будет сделано точно, то на ваших проектных сессиях просто убедитесь, что ваши проекты легко адаптируются к необходимым изменениям с минимальными усилиями по текущей истории.

Ответ 3

Проблема в том, что, если эта история представляет огромное изменение архитектуры для нашего решения? Например, из автономного приложения вам придется перейти к архитектуре клиент-сервер из-за этой истории.

Я не думаю, что ваш пример реалистичен, такая особенность должна быть как-то частью видения продукта, вы не можете обнаружить такого изменения в последней менее важной истории, ее нужно учитывать в какой-то момент раньше последний спринт и последний рассказ. Другими словами, я согласен с @fuzzy и @Eric здесь:

Если история не важна и является рискованной, она, скорее всего, никогда не будет реализована.
Если история важна и рискованна, она, скорее всего, не так низкоприоритета (т.е. неправильно установлена приоритетность).

Ответ 4

Этот вопрос представляет собой вопрос Last Responsible Moment.

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

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

С гибкой, развязанной конструкцией (например, с помощью TDD), можно сохранить стоимость изменения с течением времени относительно плоской.

Ответ 5

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

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

Ответ 6

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

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

EDIT: Технический долговой квадрант также может быть полезен для изучения таких рисков, чтобы увидеть, к чему вы можете попасть, если это преднамеренно, чтобы получить большой успех долга в конце.