Решение о дате выпуска до сбора всех требований является гибким?

Я только начал читать книгу «Применение UML и паттернов» Крейга Лармана. Я нахожу это очень интересным, потому что это бросает вызов многим из того, что мне сказали на работе. Я читал, что требования не полностью собраны за один раз в agile, и для сбора требований требуется много итераций. Если это так, устанавливает ли жестко установленный крайний срок, а это то, что я вынужден делать на работе, очень неустойчиво, учитывая, что завтра могут появиться какие-то принципиально новые требования (или запрос на изменение, маскирующийся под требование)?

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

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

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

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

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

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

Agile - это техника, а не результат. По сравнению с стрижкой газона одна итерация похожа на одну стрижку травы, которую вы косили. Если кто-то скажет «косить весь газон за 15 минут», и вы используете agile, возможно, к концу вы получите 30%. Тогда вы будете повторять еще несколько позже и закончите это.

У вас может быть запланированная дата выпуска без проблем. Просто убедитесь, что в этот конкретный день у вас нет потерь. У вас должен быть продукт, который можно было бы отправлять в конце каждого спринта, но обычно это не приносит вреда; это скорее цель, которая фокусирует работу, а не требование. Если у вас запланированная дата выпуска, то у вас должен быть выпущенный продукт на эту дату.

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

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