Agile - шипы и общая временная шкала

Команда начинает свой первый Agile-проект с большим капиталом, и кажется, что проект будет хорошо соответствовать методологии (то есть мы можем просто взять гибкую книгу и следовать ей как рецепт) с небольшим замешательством:

Проект включает три вещи, с которыми никто в команде не имеет никакого опыта: интегрироваться с системой Foo Payroll, иметь возможность обрабатывать тип файла XYZ89 (где «XYZ89» = некоторый тип файла, о котором вы никогда не слышали), и преобразовывать некоторые другие файлы, чтобы они могли быть обработаны Frobnobdicator.

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

Итак, мои вопросы:

1. Делаем ли мы все спайки в первой итерации, чтобы получить более точную оценку времени, которое потребуется, чтобы их выполнить и / или запустить и запустить «ходячий скелет»?

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

Каков наилучший способ обработки нескольких всплесков, когда они в основном являются необоротными требованиями проекта?

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

Вот почему многие Agile проекты обычно начинаются с того, что я люблю называть Sprint 0 .

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

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

Если они не будут расставлять приоритеты, что они хотят, вы будете бороться.

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

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

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

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