Имеет ли позднее значение в Agile методологиях?

Это получилось из некоторых ответов и комментариев на другой вопрос ( этот ).

Я работал в основном с проектами «водопад», и хотя я работал над специальными проектами, которые приняли гибкое поведение и прочитали немало об agile, я бы сказал, что никогда не работал над «правильным» гибким проектом. ,

Мой вопрос: имеет ли понятие «поздний» какое-либо значение в agile, если да, то что?

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

Так что, если вы не знаете точно, что вы собираетесь доставить, в основном, пока вы не доставите это, и пользователь не примет это, и если у вас нет расписания после следующего спринта, как вы могли бы опоздать в любом случае, если на самом деле имеет значение?

(Очевидно, я понимаю, что спринт может перерасти, но я говорю о том, что выходит за рамки этого.)

Просто чтобы быть ясным, я (лично) доволен предположением, что вовремя проекты водопада (даже относительно большие) возможны, основываясь на том факте, что я их видел и принимал в них участие - они не простые или даже общие но они возможны.

Речь идет не о том, чтобы сбить Agile, а о том, что я это понимаю. Я всегда видел преимущество agile в том, что он не имеет ничего общего со сроками или бюджетом (или, скорее, только косвенно), это связано с областью применения - agile позволяет приблизиться к тому, что действительно важно, а не к тому, что команда проекта считает важным до того, как они Я видел что-нибудь.

Я не согласен с тем, что Agile-проект не имеет предварительного плана.

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

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

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

«опоздание» в гибкой методологии означает то же самое, что и в методологии «водопада»: оценки были неверными, объем был слишком велик для отведенного времени, появились неожиданные трудности, клиент не был достаточно отзывчив, программисты стали ленивыми, машины разбились, ваша собака съела мой байт-код и т. д.

вы извлекаете уроки из этого и настраиваетесь на следующую итерацию

разница в том, что это может происходить каждые 2-4 недели, поэтому уроки усваиваются и процесс быстро корректируется

Да, но потребуется всего 1 месяц, чтобы понять, что вы не достигнете своего 9-месячного «мифического окончательного срока выполнения проекта» вместо 9.

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

Каждый раз, когда вы делаете какое-то обязательство, вы рискуете опоздать. Это относится и к гибкой.

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

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

И это то, что Agile это все. Умный способ справиться с этим неудобным представлением о том, что опоздание - это факт, и мы просто должны справиться с ним как можно лучше.

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

Для многоэтапного планирования, то есть планирования выпуска, вы используете скорость, рассчитанную на основе выполненных итераций, и экстраполируете данные, чтобы предсказать дату будущего выпуска. Я рекомендую статью Джеймса Шорса или мою собственную (более короткую) для более подробной информации об этом. Обратите внимание, что это никогда не является твердым обязательством, а скорее «мы на 80% уверены, что к этой дате мы выполним следующие функции». Это может (что-то вроде) привести к тому, что вы опоздаете, но обязательство - это только вероятность, а не факт.

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

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

В Agile SCRUM есть два типа «поздних»>

1. Перенос - в конце спринта истории не «Готово», разработчики «обязуются» сделать PBI готовым, поэтому, когда он не готов, его можно считать переносом.

2. Дорожная карта - если у вашей организации есть дорожная карта и если у нее есть даты, если основные результаты для этих дат пропущены, это можно считать «поздним».