Я просто оставлю это здесь
https://res.infoq.com/news/2010/01/kanban-scrum-minibook/en/resources/KanbanAndScrum-Russian.pdf
PS. Кажется я догадываюсь, почему аджайл такое непонимание вызывает. Вы видите новые декларируемые артефакты, ценность которых для вас не очевидна и говорите - что за черт, придется больше работать! Но ведь тут нет ничего нового. Вы можете взять feature request из RUP и использовать его в любом более адаптивном подходе. Но более директивный подход не означает, что работы больше будет. Более директивный подход говорит о том, что у нас есть набор уже известных вам артефактов, ценность каждого из которых обоснована в рамках единой системы. В итоге мы даем вам чеклист, используя который вы будете идти к результату. Конечно, вы можете взять refactoring из XP и засунуть его хоть в канбан, хоть в водопад. Велосипед тоже может быть оборудован палкой-копалкой с помощью которой вы будете периодически сбивать грязь с колес. Или например фонариком, который позволит вам ехать ночью. Но что бы максимально быстро проехать 1000км вам нужен вот такой конкретный девайс. Вопрос переверните с головы на ноги. Не "почему я должен делать лишнюю работу, что бы сделать свою работу" а "какую работу я должен делать, что бы сделать свою работу максимально эффективно".
Набивший оскомину пример с рефакторингом ради рефакторинга. Вот цепочка:
коллективная ответственность за результат -> коллективное владение кодом
коллективное владение кодом -> коллективное принятие решений
коллективное принятие решение -> коллективный анализ эффективности
коллективный анализ эффективности -> обоснованность рефакторинга
Это решение только одной проблемы с точки зрения XP. Если вы уберете коллективное владение кодом, то цепочка станет короче и ответить на вопрос обоснованности рефакторинга вы эффективно не сможете, потому что рефакторинг - это улучшение кода, а ваши цепочки не проходят через код. Но это будет скрам. А если у вас нет коллективной ответственности, то это канбан, где все тратят время на ворклоги, а тимлид зашивается, распределяя задачи и анализируя субъективные отчеты. Это будет канбан, даже если у вас есть беэклоги и стендапы.
Внедрение коллективного владения кодом - это исключительно управленческое решение. Но если вы этого не сделали, то чего вы жалуетесь, что у вас рефакторинг ради рефакторинга? Ну так и есть. Ваш коллега считает что пора, а вы нет. Он за свей счет делает рефакторинг, встречает непонимание, снижается мотивация. В итоге более фанатичный TDD зашивается на своем участке внутри команды и уходит, вместо того, что бы поправить дела на остальных участках системы. Каждый артефакт важен и дает синергетический эффект только при использовании вместе с другими.