Чи сприятливі терміни?

Для наочності крайнім терміном є:

Межа або термін - це вузьке поле часу або конкретний момент часу, за допомогою якого повинна бути досягнута мета чи завдання.

^{З вікіпедії}

Всю свою кар'єру з розробки програмного забезпечення я займався "Agile", який, здавалося б, означає, що принаймні дотримуються наступних практик:

• Щотижневі або двотижневі спринти
• Ретроспектива Спринт-планування
• Власник товару
• Скрам
• Історії користувачів

Однак кожен проект, на якому я коли-небудь був, наполягав на встановленні терміну. Враховуючи, що Agile намагається зосередити увагу на адаптивному плануванні, гнучкості та зміні; чи сприятливі терміни?

Моя власна думка полягає в тому, що їх немає, як я бачу строки, що призводять до нестабільності та недостатньої якості. Натомість я думаю, що це надає більшої цінності зосередитись на спринтах та ранніх поставках. Але, мабуть, у кожному колі, в якому я був, це не так, і терміни розглядаються, щоб іти на руку з розвитком Agile.

Дедлайн - це реальність. Найчастіше вам доводиться щось мати до певної дати. Це неминуче. Без термінів навіть спритні проекти можуть піддатися Закону Паркінсона :

Робота розширюється, щоб заповнити доступний час для її завершення.

Іншими словами, якщо ваш проект може продовжуватися назавжди, це буде.

Стосовно термінів, Agile намагається зробити кілька речей:

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

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

Так що так. "Спритний" і "термін" можуть бути абсолютно сумісні.

Дедлайн - це факт життя. Є речі, які мають дуже тверду дату.

Нам потрібне програмне забезпечення від Comdex

або

Ігри повинні бути на полицях магазинів до Чорної п’ятниці

тощо. Не можна відкладати Comdex або Чорну п’ятницю - решта світу не працює так.

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

Кінцевий термін - важка дата, яка встановлена ​​твердо. Agile - це інструмент, який дозволяє зрозуміти на початку циклу, що програмне забезпечення потребуватиме вдвічі більше часу, ніж спочатку сподівалося. Важливо, щоб керівники проектів мали змогу реалізувати ці проблеми раніше, ніж пізніше, щоб було додано більше ресурсів, змінено обсяг, встановлено термін (у ситуації, коли це твердий, а не твердий термін) або проект скасовано.

Прозорість, яку прагне Agile, полягає в тому, щоб показати проблеми та прогрес на початку циклу. Класичний збій з доставкою водоспаду - це те, що ти провів місяці за закритими дверима і доставив товар за тиждень до встановленого терміну, і сказано, що ти робиш це все неправильно, і ти витратив місяці (а тепер повністю прострочив термін) . Інший класичний збій водоспаду з'ясовується за тиждень до граничного терміну, у якого ще є місяці. Agile прагне донести до відома ці питання на початку процесу.

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

Гаразд, ми пропустили все, що ми хочемо, щоб податкове програмне забезпечення було розміщене 15 квітня, але ми отримали 75%, і те, що ми робимо, працює і працює з моменту початку минулого листопада. Ми знаємо, що не зможемо розгорнути повний набір функцій з середини грудня і переорієнтували свої зусилля на 80% клієнтської бази.

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

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

Навіть якщо ви надсилаєте завершені історії користувачів раз на тиждень або два рази на місяць, ви, ймовірно, будете мати терміни. Коли хтось з'явиться, переконайтесь, що ваші зацікавлені сторони знають, що, на вашу думку, підійде до встановленого терміну, та встановіть очікування.

Якщо ви постійно будуєте найкраще програмне забезпечення, яке ви можете, з вимогами, які ви зараз маєте на кожному етапі, то термін в кінці будь-якого спринту теоретично не повинен бути проблемою. Насправді це зазвичай не так, але тоді також не настають терміни, що з’являються поза повітря. Найважливіші терміни, які мені коли-небудь давали, були передані мені задовго, саме очікування якості та особливості були проблемою.

Довільні терміни, які не мають наслідків, якщо їх пропущено, не дуже гнучкі, але є ситуації, коли з причин, що не відповідають контрольним термінам групи розробників, потрібно встановлювати та дотримуватися. На щастя, якщо терміни розумні, існує безліч способів перевернути рівняння та обробити терміни по-спритному.

Терміни не завжди помиляються. Як ми всі дізналися від Оби-Вана:

"Тільки ситські угоди в абсолюті"

Справедливо сказати, що в більшості випадків терміни нерозумні, непотрібні, і, звичайно, не спритні, але дурним було б сказати, що це завжди так. Корпус Architypal - це програмне забезпечення, необхідне для використання в режимі часу, наприклад програмне забезпечення для відстеження виборів. Якщо програмне забезпечення не готове вчасно до виборів, не було б розумним чи практичним відкладати вибори, і, здається, не дуже орієнтоване на клієнта, щоб просто сказати: «Вибачте, схоже, що ми зайняли занадто багато часу. Я знаю, що це програмне забезпечення, за яке ви нам платите, абсолютно нікчемне, але терміни не є спритними, тож як ви насправді можете протистояти нам за те, щоб не зустрітись з ними? "

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

Якщо дата доставки залишається постійною, деякий інший аспект стає змінною.Як ми всі знаємо, в програмних проектах може виникнути велика невизначеність. Щось потрібно змінити у відповідь на цю невизначеність, якщо ви хочете досягти успіху в своєму проекті, і зазвичай це дата доставки. У будь-якому випадку це здається досить природним. Але це не ваш єдиний варіант. Якщо ви дотримуєтесь строгого терміну, спосіб впоратися з цим - зробити передавані функції змінними. Визначте пріоритет переліку функцій, чітко повідомте, що існує невизначеність у кількості функцій, які можна надати до цієї дати. Попрацюйте з замовником, щоб визначити пріоритетність цих функцій, щоб найбільш важливі з них мали більшу ймовірність доставки. Тоді це справа, як зазвичай, лише тоді, коли термін обертається навколо вас, коли ви готові відправити. У цій моделі

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

тл; д-р

В ідеальному світі у нас не було б строків і просто доставляти речі, коли вони будуть готові. Однак реальність полягає в тому, що люди, які платять за речі, зазвичай хочуть знати, коли вони закінчені. Agile методології це визнають, але також визнають, що не все можна зв'язати.

Це гарантує, що ви можете зберегти якість доставки на рівні, що підходить для товару. Якщо ви встановите термін і обсяг (і бюджет), то все поспішає, і ви в кінці проекту повернетеся до старого світу водоспадів з шаленим крихом. Збільшення бюджету зазвичай не є відповіддю, оскільки додавання більшої кількості розробників і тестерів не вирішує проблему швидше. Це добре відомий вид (і я згоден з ним з досвіду), що чим більше людей ви додаєте (кожен зі своїми слабкостями) , тим більше часу він приймає.

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

Команда розробників (D): "Будь ласка, чи можете ви визначити пріоритетні функції, які ви хочете отримати, перш за все найголовніше?"

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

Д : "Це може бути можливим, але це може бути неможливо, якщо вимоги зміниться або ми виявимо проблеми, яких ми не очікували під час розвитку".

C: "Ну що робити, якщо я дам вам більше грошей?"

Д: " зітхніть ... навіть якщо більше ресурсів, це займе у них один місяць, щоб реально розпочати роботу, тому, якщо ви не знаєте, як розставити пріоритети, просто скажіть нам, які з них ви хочете зробити першими".

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

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

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

Іноді клієнту не подобається, що вони не отримають того, що хочуть, до певної дати, Але вони зрозуміють, чому і що вони отримають, будуть хорошої якості. І через 6 місяців після того, як функції будуть доставлені, замовник не піклується або пам’ятатиме, що ви доставили до певної дати, він пам’ятатиме якість продукту, який він все ще використовує.

Кінцеві терміни традиційно базуються на життєвому циклі бізнесу. Податкове програмне забезпечення має бути до 15 квітня. Звіт про наступний фінансовий рік може знадобитися до липня.

У маніфесті Agile зазначено:

Індивіди та взаємодія над Процесами та інструментами

Робоче програмне забезпечення над всеосяжною документацією

Співпраця з клієнтами щодо узгодження договору

Відповідь на зміну щодо виконання плану

Терміни - це договір. Вони є планом. Вони не відповідають швидкості вашої команди. Вони не змінюються, якщо ви втратите своїх трьох найкращих розробників.

Дедлайн не є спритним, але Agile може дати нам відгук про терміни. Agile дайте нам знати, якщо наша швидкість не дасть нам зробити граничний термін, без того, щоб функція була зменшена. Це також дасть нам знати, чи потрібно брати на роботу, щоб скласти термін. І в деяких випадках нам дано знати, що граничний термін неможливий, коли не потрібно залишати жодних функцій.

Найкраще, що може зробити команда Agile - це нехай швидкість та пріоритетність відставання визначають терміни. Це дасть орієнтовні дати доставки. Якщо вони не відповідають терміну, тоді настає час серйозної розмови з клієнтом і визначити, чи цей термін навіть виконаний.

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

Деякі люди, здається, плутають спритний "дикий захід". Agile не означає, що нічого не йде. Спритний означає, що ми перестаємо брехати собі про те, наскільки розумна людина може оцінити. В основному ми можемо оцінити розробку програмного забезпечення приблизно на 2–4 тижні в майбутньому. Крім того, це все різного ступеня замахів та здогадів. Що ще гірше, витрати на подання кошторису для речей і далі в майбутнє наближаються до вартості просто виконати роботу. З будь-якої причини керівники проектів історично не бажали визнавати клієнтам ці абсолютні істини. Agile просто налаштовує це мислення, стверджуючи, що існує межа того, наскільки добре ми можемо передбачити майбутнє в інженерії програмного забезпечення, і робить тонкий перехід на "оцінку, засновану на доказах" для довгострокового прогнозування.є здатні оцінити, і ми можемо забезпечити достатньо обґрунтовані оцінки довгострокової поставки в майбутньому на основі того, що ми поставляли до сих пір.

TL; DR

Чи вважаються граничні строки [a] gile? ... [D] eadlines переходять в ногу з розвитком [a] gile.

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

Кінцевий термін передбачає велику кількість попереднього планування, яке не відповідає гнучким принципам. Натомість, ітеративні моделі розвитку покладаються на цикли часу, каденції та випуски, які включають в себе планування вчасно, але не "велике, переднє планування", яке, як правило, пов'язане з традиційними термінами управління проектами.

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

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

Однак кожен проект, на якому я коли-небудь був, наполягав на встановленні терміну. Враховуючи, що Agile намагається зосередити увагу на адаптивному плануванні, гнучкості та зміні; чи сприятливі терміни?

Це поширене нерозуміння спритних принципів. Складні рамки, такі як Scrum і Kanban, зосереджені не на термінах, а на скороченні часу та стійкій каденції доставки.

Наприклад, у Scrum, спринт - це не "термін". Це графік часу, який заповнюється кількістю роботи, яку, за оцінками команди, помістить у вікні часу, не переповнюючи її, а потім або "зроблено", або "не зроблено", коли термін часу закінчиться. Колись пішов, тайм-аут назавжди зник; будь-яка робота, яка не виконана, повинна бути перепланована і переоцінена в новому, однаково ефемерному часовому вікні на основі поточних (а не історичних) потреб проекту.

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

Планування випуску на основі часових вікон

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

Наприклад, проект може бути зобов'язаний випустити v1.0 проекту наприкінці 20 ітерацій; обсяг випуску може змінюватися протягом життя проекту (оскільки обсяг, функції та пріоритети можуть змінюватися на початку кожного спринту), але цільові дати кожного випуску визначаються в проектному плані. Команда прагне поставити потенційно можливий приріст кожного спринту, і визначення Виконано включає перевірки якості, такі як безперервна інтеграція для того, щоб проект був у звільненому стані в кінці кожного спринту.

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

Дивитися також

• Як виконати гнучкі плани планування випуску

Подумайте про терміни як зобов’язання. Те, що проект є гнучким, не означає, що ви не зобов’язуєтесь надавати функції на певну дату.

Спритність приносить те, що відбувається між ними. Замість того, щоб мати суворий документ із специфікацією вимог до програмного забезпечення, який визначає, що вам слід поставити функцію A, що складається з підфункцій B, C, D і E на дану дату, ви зобов’язуєтесь доставити функцію A на дану дату, враховуючи, що на на ранній стадії, ні ви, ні ваш клієнт не знаєте, як буде виглядати ця функція, чи мали б у неї підфункції B, C, D і E або, можливо, B і C, або десяток інших підфункцій.

Уявіть собі компанію, яка раніше постачала товари лише невеликим компаніям і щойно підписала контракт з великою корпорацією. Ця велика корпорація використовує EDIFACT, і здається, що поточне програмне забезпечення бухгалтерського обліку, яке використовується вашою компанією, не обробляє EDIFACT. Ви просили , щоб створити плагін , який робить це, з огляду на , що за контрактом, ваша компанія повинна бути готова до 15 квітня ^тис .

Спритність означає, що посередницькі кроки здійснюватимуться поступово і базуватимуться на регулярному зворотному зв’язку. В основному, ви покажете своїм успіхам бухгалтерам, і вони скажуть вам, що вони думають про це, які можливі питання і т. Д. Це також означає, що, можливо, спочатку у бухгалтерів була чудова ідея, яка, на їхню думку, могла поліпшити. по суті, користувацький досвід. Через три тижні з'ясувалося, що це не тільки не дуже вдосконалює її, але й призведе до місяця додаткового розвитку. Завдяки Agile ви зможете перенаправити свої зусилля з цієї функції на щось інше, переконуючись, що це доставлено вчасно.

Ви також повинні розуміти точку зору замовника:

• Часто підприємствам потрібна конкретна дата доставки. Наприклад, ви не можете надати послугу онлайн-потокового передавання «Олімпійські ігри» після закінчення Олімпійських ігор. Для бізнесу це просто провал, який має величезні негативні наслідки.

• Не маючи на себе зобов'язань, розробник чи субпідрядник спокушає або бути перфекціоністом, або зробити проект низьким пріоритетним. Хоча регулярність спринтів допомагає, це не повністю запобігає цьому ризику.

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

Програмування eXtreme повідомляє про планування випуску:

Основна філософія планування випуску полягає в тому, що проект може бути кількісно визначений чотирма змінними: сфера, ресурси, час та якість.

Що здається справедливим. Він також говорить, що

Ніхто не може контролювати всі 4 змінні. Коли ви змінюєте одне, ви ненавмисно викликаєте зміни у відповідь іншого. Зауважимо, що зниження якості до менш ніж відмінного непередбачувано впливає на інші 3 змінні

І як вже зазначалося в br3w5 , збільшення ресурсів є обмеженим рішенням. Напевно, ви можете додати пару людей, які вже були частиною команди, якщо їх відправили на щось інше. Але ви не можете просто збільшити розмір команди швидко і безстроково, принаймні, не без реорганізації команди, яка займає багато разів.

Отже, маючи невідмінну якість та постійні ресурси: термін є часовим обмеженням, це означає, що вам потрібно адаптувати сферу застосування. А використання спритності дає вам можливість дотриматись терміну з максимально продуктивними можливостями. Однак, як правило, ви можете гарантувати, що деяка частина сфери буде виконана вчасно. Це та частина, за якою ви можете з довірою оцінити час її обмеження нижче граничного строку. Зазвичай те, що насправді близьке до того, що ви робили кілька разів, і мало що невідомо.

Мета методів розробки програмного забезпечення, якщо їх правильно розуміти, полягає в тому, щоб зробити нас більш продуктивними, зосереджуючи свої думки, і надати загальну мову для типових ситуацій. Йдеться про натхнення та сприяння, а не про контроль розуму та провину.

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

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

Терміни не є гнучкими, вони:

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

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

Agile намагається ввести реальність у ситуацію, сказавши: "Ви знаєте, що термін або функції будуть ковзати та / або змінюватися, ми це знаємо, тому давайте зійдемо на праву ногу і навіть не робимо вигляд".

Ключовим є те, що термін стає просто датою випуску першої версії програмного забезпечення. Це все ще може бути написане кам'яним каменем - скажімо, програмне забезпечення призначене для академічного використання і ОБОВ'ЯЗКОВО бути доступним до початку терміну роботи, - але те, що ви поставите, - це не так. У вас є мінімум життєздатного продукту, який всі впевнені, що його зможуть доставити до цього часу, і ви маєте навантаження "хотіли б мати". Замість того, щоб усі кидали руки, коли виявиться, що весь список не буде доставлений до "строку", ви переконайтеся, що ви отримаєте MVP у двері і стільки ж "хотіли б мати", як можливо, а потім оцінити вартість / вигоду залишку в цьому пункті.

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

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

Agile намагається використати цю м'якість, дозволяючи цілям розвиватися та змінюватися в ході проекту таким чином, щоб конструкція моста ніколи не могла.

Відповідь "напевно, ні"

Project_management_triangle стверджує , що вартість, час і область застосування (а також якість) залежать один від одного. ("виберіть два та отримайте третє")

Спринт scrum вибирає фіксований час (тобто 7 днів = тривалість спринту) та вартість (тобто бюджет на 7 членів команди) і оцінює обсяг (кількість історій, які потрібно виконати у спринті)

Якщо керівництво чи відділ продажів намагаються визначити всі три (вартість, час та сфера застосування), це не є спритним у сенсі скруту, оскільки команда не може обіцяти досягти мети (без порушення якості = визначення-зробленого)

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

Чи не можна відповісти на це просто та безпосередньо?

Ніякі терміни не є спритними.

Вся справа в тому, щоб будувати те, що ви можете, ітераційним способом навчання та адаптації, як ви йдете.

Кінцевий термін - "ви повинні доставити х по у", який не відповідає обом показникам, оскільки ви обіцяєте фіксовану доставку за заздалегідь визначеним часовим шкалом (де спритний говорить, що ми не впевнені, що ми намагаємося доставити, і навчання з спритного вчить нас, що навіть якщо ми знаємо, дуже важко мати певність щодо часових масштабів - або це вирішена проблема, і ми не повинні цього робити.

Встановивши, що відповідь на питання "Ні, терміни не є гнучкими" - тоді ми можемо провести цікаву бесіду, яка стосується питання "як ми вирішуємо терміни в спритному контексті", і є багато хорошого думаючи про це в інших відповідях.

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

Ступінь спритності, необхідної в роботі, обернено пропорційна тому, наскільки високою є їхня позиція в організації.

"Спритний" - це добре, для чого воно є. "Спритний" сорт означає "відкритість у поєднанні з достатньою компетентністю". Саме бурчання внизу повинно бути найбільш спритним.

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

Але подібно до освіченого власного інтересу, він насправді не існує.