Сроки являются гибкими?

Для ясности, крайний срок:

Ограничение по времени или предельный срок - это узкое поле времени или конкретный момент времени, к которому должна быть достигнута цель или задача.

^{Из википедии}

Всю свою карьеру в области разработки программного обеспечения я занимался «Agile», что повсюду, казалось, означало, что, по крайней мере, были соблюдены следующие методы:

• Еженедельные или двухнедельные спринты
• Ретроспективы Спринт планирование
• Владелец продукта
• Scrum
• Пользовательские истории

Однако каждый проект, в котором я когда-либо участвовал, настаивал на том, чтобы установить крайний срок. Учитывая, что Agile пытается сосредоточиться на адаптивном планировании, гибкости и изменениях; сроки гибкие?

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

Сроки являются реальностью. В большинстве случаев вы должны иметь что-то к определенной дате. Это неизбежно. Без сроков даже гибкие проекты могут уступить Закону Паркинсона :

Работа расширяется, чтобы заполнить время, доступное для ее завершения.

Другими словами, если ваш проект может продолжаться вечно, так и будет.

В отношении сроков Agile пытается сделать несколько вещей:

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

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

Так да. «Agile» и «сроки» могут быть идеально совместимы.

Сроки - это факт жизни. Есть вещи, которые имеют очень твердую дату.

Нам нужно программное обеспечение Comdex

или же

Игры должны быть на прилавках магазинов к Черной пятнице

и тому подобное. Нельзя откладывать Comdex или Черную пятницу - остальной мир так не работает.

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

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

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

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

Хорошо, мы упустили все, что мы хотим, чтобы налоговое программное обеспечение было развернуто 15 апреля, но у нас есть 75%, и то, что у нас есть, работает и работает с тех пор, как мы начали в ноябре прошлого года. Мы знали, что не сможем развернуть полный набор функций с середины декабря, и переориентировали наши усилия на 80% клиентской базы.

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

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

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

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

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

Сроки не всегда неправильны. Как мы все узнали от Оби-Вана:

«Только ситхи имеют дело с абсолютами»

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

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

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

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

ТЛ; др

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

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

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

Команда разработчиков (D): «Пожалуйста, вы можете расставить приоритеты для тех функций, которые вы хотите предоставить, в первую очередь для наиболее важных?»

Заказчик (C): «Все является приоритетом 1 - я хочу, чтобы все они были выполнены к концу следующего месяца».

Д . : «Это может быть возможно, но это может быть невозможно, если требования изменятся или мы обнаружим проблемы, которые не ожидали в процессе разработки».

C: "Ну что, если я дам тебе больше денег?"

Д: « Вздох ... даже с большим количеством ресурсов им понадобится один месяц, чтобы начать работу; так что, если вы не уверены, как расставить приоритеты для функций, просто скажите нам, какие из них вы хотите сделать первыми».

C: "Хорошо, я хочу большую кнопку, но сделаю ее действительно большой, а потом ... и т. Д."

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

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

Иногда клиенту не нравится, что он не получит то, что хочет, к определенной дате, НО он поймет, почему и что он получит, будет хорошего качества. И через 6 месяцев после того, как функции будут доставлены, клиент не будет беспокоиться или помнить, что вы доставили его к определенной дате, он будет помнить качество продукта, который он все еще использует.

Сроки традиционно основаны на жизненном цикле бизнеса. Налоговое программное обеспечение должно быть до 15 апреля. Отчетность за следующий финансовый год, возможно, должна быть подготовлена ​​к июлю.

В Agile Manifesto гласит:

Люди и взаимодействия по процессам и инструментам

Рабочее программное обеспечение над всеобъемлющей документацией

Сотрудничество с клиентом в рамках переговоров по контракту

Реагирование на изменения После плана

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

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

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

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

Некоторые люди, кажется, путают ловкий «дикий запад». Agile не значит, что все идет. Agile означает, что мы перестаем лгать себе о том, как хорошо может оценить разумный человек. В основном мы можем оценить разработку программного обеспечения примерно через 2 - 4 недели в будущем. Помимо этого, все это разные степени гаданий и догадок. Что еще хуже, стоимость предоставления сметы для вещей все дальше и дальше в будущее приближается к стоимости просто делать работу. По какой-то причине руководители проектов исторически не хотели признавать эти абсолютные истины для клиентов. Agile просто корректирует это мышление, утверждая, что существует предел того, насколько хорошо мы можем прогнозировать будущее в разработке программного обеспечения, и тонко переключается на «доказательную оценку» для долгосрочного прогнозирования.являются способны оценить, и мы можем обеспечить достаточно обоснованные оценки долгосрочной поставки в будущем на основе того, что мы поставляли до сих пор.

TL; DR

Считается ли, что крайние сроки [a] gile? ... [D] eadlines идут рука об руку с [a] развитием gile.

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

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

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

Подумайте, временные рамки, а не сроки

Однако каждый проект, в котором я когда-либо участвовал, настаивал на том, чтобы установить крайний срок. Учитывая, что Agile пытается сосредоточиться на адаптивном планировании, гибкости и изменениях; сроки гибкие?

Это распространенное недопонимание гибких принципов. Гибкие структуры, такие как Scrum и Kanban, ориентированы не на сроки, а скорее на временные рамки и устойчивый темп поставки.

Например, в Scrum Sprint не является «крайним сроком». Это временной интервал, который заполнен объемом работы, который, по оценкам команды, уместится в пределах временного интервала, но не переполняет его, а затем либо «выполнено», либо «не выполнено» по истечении срока. После того, как время ушло, время исчезло навсегда; любая работа, которая не была выполнена, должна быть перепланирована и переоценена в рамках нового, в равной степени эфемерного периода времени, основанного на текущих (а не исторических) потребностях проекта.

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

Планирование выпуска на основе временных рамок

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

Например, проект может быть посвящен выпуску v1.0 проекта в конце 20 итераций; объем выпускаемой информации может меняться в течение срока действия проекта (поскольку объем, функции и приоритеты могут изменяться в начале каждого спринта), но целевые даты для каждого выпуска фиксируются в плане проекта. Команда стремится предоставить потенциальный прирост приращения для каждого Спринта, а определение «Готово» включает проверки качества, такие как непрерывная интеграция, чтобы гарантировать, что проект находится в состоянии высвобождения в конце каждого спринта.

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

Смотрите также

• Как выполнить гибкое планирование выпуска

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

Что приносит гибкость, так это то, что происходит между ними. Вместо того, чтобы иметь документ со спецификацией строгих требований к программному обеспечению, который определяет, что вы должны предоставить функцию A, состоящую из подфункций B, C, D и E, на определенную дату, вы обязуетесь предоставить функцию A на определенную дату, учитывая, что на На раннем этапе ни вы, ни ваш клиент не знаете, как будет выглядеть эта функция, или у нее есть подфункции B, C, D и E, или, может быть, B и C, или дюжина других подфункций.

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

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

Вы также должны понимать точку зрения клиента:

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

• Без обязательств разработчик или субподрядчик заманчиво либо перфекционист, либо делает проект низким приоритетом. Хотя регулярность спринтов помогает, это не полностью предотвращает этот риск.

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

eXtreme Programming заявляет о планировании выпуска:

Основная философия планирования выпуска заключается в том, что проект может быть определен количественно по четырем переменным: объем, ресурсы, время и качество.

Что кажется справедливым. Также говорится, что

Никто не может контролировать все 4 переменные. Когда вы меняете один, вы непреднамеренно заставляете другого реагировать. Обратите внимание, что снижение качества до уровня ниже превосходного имеет непредвиденное влияние на другие 3 переменные

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

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

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

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

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

Сроки не являются гибкими, они:

1) Водопад и 2) Неправильно.

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

Agile пытается внедрить реальность в ситуацию, говоря: «Вы знаете крайний срок, или особенности будут смещаться и / или изменяться, мы знаем это, поэтому давайте встанем на правильную ногу и даже не будем притворяться».

Ключ заключается в том, что крайний срок становится просто датой выпуска первой версии программного обеспечения. Это все еще может быть написано на камне - скажем, программное обеспечение предназначено для академических целей и ДОЛЖНО быть применимо к началу семестра - но то, что вы получите, - нет. У вас есть минимально жизнеспособный продукт, который, как все уверены, может быть доставлен к тому времени, и у вас есть масса «хотел бы иметь». Вместо того, чтобы каждый поднял руки, когда выяснилось, что весь список не будет доставлен к «крайнему сроку», вы должны убедиться, что вы получили MVP за дверь и столько «желающих иметь», сколько можно, а затем оценить стоимость / выгоды от остатка в этой точке.

Любой, кто играл в компьютерные игры в течение любого времени, точно знает, как это работает! Если первый выпуск соответствует бета-стандартам, многие геймеры будут довольны, настолько низки ожидания того, что означают «твердые, реальные сроки» в реальной жизни.

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

Agile пытается использовать эту мягкость, позволяя целям развиваться и изменяться в ходе проекта так, как это никогда не удавалось создать мосту.

Ответьте "вероятно нет"

Project_management_triangle утверждает , что стоимость, время и область применения (а также качество) зависят друг от друга. («выбери два и получи 3-е»)

Спринт Scrum выбирает фиксированное время (т.е. 7 дней = продолжительность спринта) и стоимость (т.е. бюджет для 7 членов команды) и оценивает масштаб (количество историй, которые должны быть сделаны в спринте)

Если руководство или отдел продаж пытается определить все три (стоимость, время и объем), то это не является гибким в смысле разборок, потому что команда не может обещать достичь цели (не нарушая качество = определение выполнено)

Профессиональный менеджмент пытается определить стоимость и время и при необходимости сократить объем, если есть какая-то фиксированная дата, которую необходимо выполнить.

Разве на это нельзя ответить просто и прямо?

Никакие сроки не проворные.

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

Крайний срок - «вы должны доставить x по y», который не выполняется в обоих случаях, поскольку вы обещаете фиксированный результат в заранее установленное время (где agile говорит, что мы не уверены в том, что мы пытаемся доставить, и Изучение от Agile учит нас, что даже если мы знаем, что очень трудно быть уверенным в сроках - или это решенная проблема, и мы не должны делать это в любом случае).

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

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

Степень ловкости, требуемая в работе, обратно пропорциональна тому, насколько высоко их положение в организационной структуре.

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

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

Но, как и просвещенный личный интерес, он на самом деле не существует.