Scrum. Работа с историями с низким приоритетом, которые представят изменения архитектуры
Сегодня в университете у нас было упражнение Scrum (имитирующее весь процесс создания программного решения), и я столкнулся с проблемой, которая не совсем понятна.
Допустим, мы определили наши истории и даем им правильную расстановку приоритетов. И есть история с очень небольшим приоритетом... возможно, это будет сделано из последних спринтов.
Проблема в том, что если эта история привнесет огромные изменения в архитектуру нашего решения? Например, из автономного приложения вам придется перейти на архитектуру клиент-сервер только из-за этой истории.
С моей точки зрения: не естественно ли каким-то образом отмечать, какие истории наверняка должны быть сделаны (в определенный момент времени), те, которые необходимо сделать критически, но это не критично, когда, поэтому команда должна иметь им в голову и принимать лучшие решения, разрабатывая свое решение. Или как вы справляетесь с этой проблемой? Если это проблема.
Заранее спасибо! И извините за мой, вероятно, хромой вопрос.
6 ответов
Потому что ты сказал:
сделано в одном из последних спринтов, может быть.
Я склонен согласиться с нечетким леденцом на палочке (и +1 от меня).
Однако, если что-то, что вы знаете, должно быть сделано, но это было сделано в самом конце, это просто не в том месте, если это может оказать серьезное архитектурное влияние.
Вы можете разделить задачу на анализ и реализацию, чтобы (воздействие) анализ выполнялся очень рано, чтобы определить, действительно ли будет архитектурное воздействие, а затем запланировать реализацию соответствующим образом в зависимости от результата анализа.
В реальном мире с $$$ на линии, вещи с низким приоритетом, вероятно, никогда не будут выполнены. И если у них высокий фактор риска, который в реальном мире означает еще больший риск и низкий приоритет, они точно не справятся. В вашем случае, если вы знаете, что это будет сделано наверняка, тогда на ваших сессиях по дизайну просто убедитесь, что ваши проекты будут легко приспосабливаться к необходимым изменениям с минимальными усилиями в текущей истории.
Проблема в том, что, если эта история привнесет огромные изменения в архитектуру нашего решения? Например, из автономного приложения вам придется перейти на архитектуру клиент-сервер, только из-за этой истории.
Я не думаю, что ваш пример реалистичен, такая функция должна как-то быть частью видения продукта, вы не можете обнаружить такое изменение в последней менее важной истории, это нужно учесть в какой-то момент перед последним спринтом. и последняя история. Другими словами, я согласен с @fuzzy и @Eric здесь:
- Если история не важна и рискованна, она, скорее всего, никогда не будет реализована.
- Если история важна и рискованна, то, скорее всего, она не имеет такого низкого приоритета (т.е. имеет неправильный приоритет).
Похоже, это вопрос последнего ответственного момента.
Если все участники уверены, что это требование, и оно повлияет на архитектуру, ставить его в последний спринт неразумно.
Более вероятным случаем является то, что это может потребоваться. Если вы скорректируете свой дизайн, чтобы приспособить его на ранней стадии, вы будете поддерживать эту сложность с помощью нескольких спринтов, чтобы поддерживать функцию, которая может никогда не быть добавлена. (Деловые требования меняются.)
Благодаря гибкой развязанной конструкции (например, разработанной с помощью TDD) можно сохранить стоимость изменений с течением времени на относительно низком уровне.
Если это должно быть сделано, и это повлечет за собой большие архитектурные изменения, то это, вероятно, не должно быть низким приоритетом.
Единственный раз, когда я вижу, что его следует классифицировать как низкоприоритетный, - это если допустимо либо полностью отбросить его, либо допустимо отложить его, даже если в будущем это будет стоить намного дороже (скажем, продукт должен покончим с этим, чтобы потом было больше денег на будущее)
Хотя приоритет в основном зависит от желания клиента, это не совсем так. Могут быть некоторые технические аспекты, которые, по мнению команды, должны быть выполнены ранее. Например, выбор ORM может мало что значить для клиента, но это может быть важным дизайнерским решением с точки зрения команды.
Мы несколько раз сталкивались с этим в моем текущем проекте, связанном с CMS, где такие вещи, как интернационализация, должны были решаться на ранних этапах, но это не обязательно был мудрый шаг, поскольку позже произошли изменения, такие как внедрение программного обеспечения другой компании для обработки некоторых перевода, который может повлиять на часть нашего кода.
РЕДАКТИРОВАТЬ: Технический долговой квадрант также может быть полезен для изучения таких рисков, чтобы увидеть, что вы можете получить, если намеренно получить большой удар долга в конце.