как вы поступаете с историями, которым требуется более одного месяца, чтобы достичь состояния ГОТОВО-ГОТОВО? Конечно, их всегда можно разделить на несколько так называемых «технических историй», но они, за исключением всплесков рефакторинга, являются большим табу в Agile, не так ли?
Во-первых, делайте то, что действительно имеет смысл. Если имеет смысл разделить большую историю на несколько более мелких, даже если вы не можете донести эти части до клиента по отдельности, почему бы вам не сделать это? Вам не платят за то, что вы идеально приспосабливаетесь к тому, что говорят некоторые лидеры мнений.
Во-вторых, если ситуация является скорее исключением, относиться к ней следует как к одному. Если вы не хотите разбивать историю на более мелкие куски, вы можете выдвинуть одну историю среди пары итераций и договориться, что на этот раз она будет выглядеть вот так.
В-третьих, если ситуация довольно распространена , подумайте, как вы можете настроить процесс, которому вы следуете, таким образом, чтобы такие истории действительно допускались . Одна вещь, которая приходит мне на ум, это Канбан, когда вы полностью отказываетесь от итераций и можете заниматься одной историей XXL и в то же время строить множество меньших, так как вы не ограничиваете работу по времени, а ограничиваете количество параллельных задач. В этом случае одна огромная история заняла бы только один слот, но использовала бы его в течение более длительного времени.
В- четвертых, не будьте ортодоксальны в предоставлении ценности клиенту . Если бы вы хотели и нуждались в хозяйственной работе в архитектуре, которая не принесла бы вашим клиентам никакой ценности, но помогла бы вам ограничить затраты на обслуживание, вы бы отказались от такой задачи? Вероятно, не. И все же вы бы как-то занесли его в свой бэклог.
В конце концов, Agile — это гибкость, реакция на изменения, а не соблюдение правил любой ценой, верно?
Цепляться за пользовательские истории как за наименьшую единицу планирования — одна из отвратительных ошибок, которых придерживаются агилисты.
Какова история пользователя для моста? Где учитывается конструкция простенков, пролетов, балок и т.п., составляющих подконструкцию? Конструкция настила (проезжей части) имеет столь незначительное значение (условно говоря), что в данном повествовании она даже не детализирована.
Сколько пользовательских историй для дома связаны с фундаментом и крышей? Тем не менее, они являются самыми дорогими частями здания.
Пользовательские истории — это фундаментальный инструмент для определения масштаба и постановки целей проекта, но это не единственный инструмент, который можно использовать. Они помогают определить цель проекта и время его завершения. Они не отражают всего объема прилагаемых усилий. Они помогают начать процесс планирования. Они не окончательный план.
Если вы действительно не можете разделить историю на ценные фрагменты, я бы выбрал «наименьший тестируемый компонент», чтобы нарезать его.
Можете ли вы привести пример истории?
Отличный ответ от Павла. Некоторые другие вещи, которые следует учитывать:
Сделано должно быть с точки зрения того, кому доставляется история. Это не всегда конечный пользователь.
Существует разница между потенциально отгружаемым и отгружаемым. Работа, которую мы делаем, мы стараемся сделать функционально полной, хотя она может быть неполной.
Все истории можно разбить. Теоретически при планировании это сделать сложно.
Старайтесь не разбивать истории по измерению процесса. Например, не стройте в одной итерации, а тестируйте в следующей. Это повлияет на пропускную способность и может привести к техническому долгу.
Кен дал хороший совет. Мы обнаружили, что самое важное, о чем следует помнить, это то, что...
Точно так же, как вы беретесь за любую эпопею: разбивайте ее на более мелкие части.
Есть много разных способов сделать это. Например, если в вашем проекте есть много других (устаревших) систем для взаимодействия, попробуйте найти пользовательскую историю более низкого уровня, которая имеет дело с ОДНОЙ устаревшей системой. И посмотрите, как реализация этого повлияет на общую эпическую историю.
Другой подход заключается в том, чтобы решать проблемы с точки зрения заинтересованных сторон.
Проверьте этот пост для еще одного способа справиться с этим .
Можно попробовать разделить на технические истории или запустить мини-водопад, если это имеет смысл для команды и соответствующих заинтересованных сторон.
Мэтт В.