Чи значно вигідніше виправити помилку в кінці проекту?


21

У публікації в блозі Ендрю Хей була розміщена така аксіома:

Виправити помилку в кінці проекту коштує значно більше, ніж це зробити, щоб виправити цю помилку раніше в проекті.

Однак це не здається певним, особливо після прочитання публікації в блозі на Less Wrong , і дані, які я бачив, щоб створити резервну копію, надзвичайно старі.

Чи є це ще сьогодні аксіомою точною?


@StefanHendriks Коментарі у вашій статті, що посилається на Morendil, дійсно висвітлюють все, що ви можете запитати; ІМХО. Чудова інформація там.
Аарон Маківер

@AaronMcIver, я маю на меті більше людей дізнатися про це. Як і поширення слова та збільшення шансів на отримання реальних даних. Я не шукаю реальної дискусії; чудові проходять у статті (як ви також з’ясували :)).
Стефан Хендрікс

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

Хоча це, безумовно, пов’язане з програмуванням, характер питання може насправді зробити його більш доцільним на критиці.stackexchange.com.
Стриптинг-воїн

Відповіді:


16

Єдині важкі дані, які я коли-небудь бачив, - це Боем і Папаччо, розуміння та контроль витрат на програмне забезпечення .

Це відноситься до 1988 року і було вивчення близько 80 програмних проектів. Вони дійшли висновку, що рішення, прийняте достроково і виправлене пізно, може коштувати в 50-200 разів, ніж воно було б, якби воно було скоріше виправлене. Але дуже ранніми рішеннями, про які вони говорять, є те, на якій ОС працювати, а також якою мовою та базою даних використовувати.

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

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

Редагувати: Док Браун добре зазначає у своєму коментарі.

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

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

Тож це було безумовно вірніше тоді, ніж зараз.

І все-таки, зовсім недавно я бачив, як в блогах використовуються візуалізація цієї проблеми Стіва МакКоннелла ( див. Дату 1996 р.), Ніби цей графік насправді ґрунтується на важких цифрах. Це не так. Це візуалізація, пояснити його суть просто.

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


3
+1. Думаю, слід додати, що дослідження Бома проводилися в той час, коли витрати на створення та розгортання виправлень виправлень були набагато вищими, ніж сьогодні.
Doc Brown

@DocBrown: Добре. Додано. Поряд із ще однією трамбуванням.
пдр

+1 для довідки, +1 для візуалізації (дуже погано, можу дати лише один бал.) Відмінна відповідь, дякую!
Стефан Хендрікс

15

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

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

Крім того, якщо ви виправляєте помилки рано, реалізація все ще є свідомою для розробника. Залежно від тривалості будь-якого проекту, якщо ви виправляєте помилки в кінці, розробнику потрібно буде витратити час на з'ясування того, що вони написали, і (можливо), як працюють підсистеми, від яких залежить їх код. Час, витрачений на перевчення цього = $.


1
Тому в основному ми говоримо про необхідну кількість зусиль, щоб виправити помилку пізніше (або раніше). Я можу придумати інші фактори, які роблять помилки дорожчими, якщо їх виправити пізніше. Але це залежить від вашого визначення помилки. Можливо, це щось, про що слід домовитись спочатку. У моїй книзі це також "невідповідні очікування в цьому випуску". Мовляв, відсутня функціональність. Це може коштувати справжніх грошей, тож його очевидніше тоді. Деякі функції, можливо, не коштують дорожче (наприклад, для веб-сайтів, зміни CSS?) Зараз, ніж раніше. Або, не те, що значно більше. Проте я не маю даних.
Стефан Хендрікс

@StefanHendriks: Ми говоримо як про кількість необхідних зусиль, так і про нові помилки, які виникають із-за виправлених заявок. Вам, мабуть, доведеться заглибитись у проектні програми (ті, які використовують обидва методи), щоб отримати фактичні дані.
Дем'ян Брехт

2
@AaronMcIver: Моє відсторонення від статті полягає не в тому, який метод є кращим, а в тому, що дослідження та важкі дані, які використовуються для резервування заявки та неправильних тлумачень у наступних звітах. Хоча моя відповідь не ґрунтується на публічних даних, вона базується на 10+-річному досвіді роботи з дуже складними системами.
Дем'ян Брехт

1
До речі, я не погоджуюся з тим, що зміни CSS від цього не страждають. Спробуйте вирішити проблему з компонуванням, як тільки всі інші піксельні речі стануть ідеальними, і ви побачите, що, можливо, доведеться зламати багато речей
Андреа

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

12

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

  • Загальна кількість коду в проекті, як правило, зростає до кінця. Чим довше ви чекаєте виправлення помилки, тим більша база коду, яку вам доведеться торкнутися.
  • Якість нового коду, доданого до проекту, знижується до кінця, принаймні, якщо є тиск (як правило, це дано): наступаючий термін змушує людей викидати кращі практики за борт, щоб просто доставити вчасно. Це означає, що чим пізніше ви виправите помилку, тим більше поганий код вам доведеться просіяти.
  • Незважаючи на те, що дублювання коду, як правило, нахмуриться, воно відбувається постійно, і оскільки його легко скопіювати, вставити, але важко повторно об'єднати повторювані розділи коду, кількість одноразово вставленого коду зазвичай збільшується протягом життя проект. Більше копіюваного коду означає більший шанс, що ваша помилка буде дублюватися та її потрібно знайти та виправити кілька разів (і, отже, більший шанс, що деякі її випадки пройдуть непомітно).
  • Виправлення помилки - це зміна кодової бази; ви сподіваєтесь на те, щоб покращити справи, але зміна завжди несе ризик. Зміна, яка спричиняє серйозні проблеми в проекті, який триває протягом кількох місяців, повинен залишити достатньо місця для управління пошкодженнями, але за два дні до доставки вас чекають серйозні проблеми.
  • Чим довше існує сама помилка, тим більше шансів на те, що інші частини програми починають покладатися на її неправильну поведінку. Потім, коли ви виправите це, ви раптом розкриєте купу вторинних помилок у коді, який не очікує, що ваша функція дійсно забезпечить правильні задокументовані результати.

+1. Чудова відповідь. Копіювати та вставляти код, який містить помилки, генерує більше помилок залежно від залежних від нього модулів.
Картик Сріенівасан

2

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

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

Щось, що коштує $ 10, щоб виправити в момент задуму ідеї ...

Коштує близько 100 доларів, якщо вам потрібно буде оновити специфікацію ....

Або коштувати близько 1000 доларів, якщо щось було реалізовано, і вам потрібно внести зміни в цей момент (і оновити специфікацію, отримати схвалення тощо), але це не пройшло офіційного тесту на прийняття / продаж

Або коштувати приблизно 10000 доларів, якщо щось було впроваджено та прийнято клієнтом, і вам потрібно внести зміни в цей момент (і оновити специфікацію, отримати схвалення, повторно протестувати і повторно запустити прийняття та кваліфікацію клієнтів тощо)

А вартість після розгортання / розгортання / введення в експлуатацію знову ще більше.

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

ОБОВ'ЯЗКОВО ваш пробіг буде різним: витрати та наслідки зміни веб-сайту електронної комерції Фреда Нюрке дещо відрізняються від витрат на зміну програмного забезпечення на комп'ютері управління польотом літака.


1
Скажімо, ви щомісяця постачаєте своїм користувачам нову версію програмного забезпечення (або просто патчі, як MS це робить для Windows). Зараз з’являються дві помилки - одна, яка була впроваджена в програмне забезпечення два роки тому, одна - представлена ​​минулого місяця. Вартість виправлення цих двох помилок та розгортання нового випуску може бути практично однаковою. Вартість виправлення проблем, викликаних будь-якою з цих помилок, може бути різною річчю, але це дуже залежить від самої помилки.
Doc Brown

Не зовсім те саме - ось після доставки. Витрати після доставки схожі за величиною (всі вони потребують оновлення, тестування, розгортання.) Я зазначаю вище, що витрати після релізу різко зростають.
quick_now

1
"пост-реліз" - стан, дійсний для вбудованого програмного забезпечення, певною мірою для програмного забезпечення для скорочення термоусадок, а також для програмного забезпечення, розробленого в (неправильно керованій!) моделі водоспаду. Інші типи програмного забезпечення розробляються та випускаються поступово, час "після випуску" практично невеликий порівняно з терміном експлуатації продукту. Особливо це стосується веб-додатків.
Doc Brown

Можливо, це стосується веб-додатків, але це не весь Всесвіт. А що з пральними машинами? Автомобілі? Ракети? Операційні системи ПК? Електростанції? ПЛК, що працюють на цементних заводах? Вперед і в списку йде.
quick_now

2

У мене немає доступу до важких даних або фактів, тому я можу запропонувати вам лише анекдотичні спостереження, зібрані з моїх останніх 20 років ІТ.

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

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

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

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

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

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


1

Ранні помилки поширюватимуться на інші частини системи, тому після виправлення помилки ви можете змусити переписати деякі частини системи, які покладаються на саму помилку.

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

Це так просто, і немає нічого доказувати.

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


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

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

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

1

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

Ми додали функцію, яка надала можливості управління робочим потоком для нашого продукту. Типові матеріали BDUF, специфікації, підписані та затверджені клієнтом. Реалізовано до спец. Скарги з першого дня на розгортання.

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

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


1

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

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


1

Запитайте у Intel, скільки коштує помилка Pentium, ракета Ariane 5 - ще один хороший приклад. Ці помилки були виправлені наприкінці проекту. Я працював над системою, де "спроба" випуску програмного забезпечення має бюджет 6 цифр. У цих крайніх випадках легко зрозуміти вартість. В інших (більшість?) Випадків вартість приховується від шуму, але він все ще є.

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

Якщо помилка втече в дику природу, вартість має крок мудрий стрибок ...... Чи "Кінець проекту" до або після випуску програмного забезпечення?


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

Помилки, про які ви згадуєте, не були знайдені рано, а тому не виправлені рано.

@ Thorbjørn Ви дійсно правильні - хоча не знайшли рано дефекти, які ми вставили рано (У випадку з ракетою Ariane, помилка була вставлена ​​ще до того, як проект навіть був запущений, оскільки вони повторно використовували існуючий код.). Вартість пропорційна часу між вставкою та розгорнутою корекцією, нічого спільного з тим, коли вона знайдена чи виправлена ​​(Більшість розробників вважає її виправленою, коли патч знаходиться в базі коду. Дефект не виправлений, поки кінцеві користувачі не встановлять його ). Все це лише ІМХО - у мене немає доказів, які б це підтверджували.
mattnz

1

Одного разу я прочитав статтю, яка мала два цікавих моменти (на жаль, у мене вже давно не було посилань, тому мені доведеться просто постулювати тут). Перший пункт, який вони зробили, полягав у тому, що близько 50% всіх помилок були внесені в специфікацію вимог і приблизно 90% всіх помилок, виявлені під час тестування UAT або System.

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

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


1

Немає статистичних даних, а особистий досвід:

Код управління ракетним двигуном, над яким я працював, мав такий рядок powerCutoff = someCondition && debugOptions.cutoffIsAllowed;. Параметр за замовчуванням не було дозволено. "Остаточна" збірка повинна була видалити всі параметри налагодження, тому рядок змінено на powerCutoff = someCondition;.

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

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

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


0

На жаль, як і багато речей, це залежить.

Якщо діалогове повідомлення неправильно написано, виправити його може бути "тривіально" (оновити рядок, відновити / пакет, переукласти). Або якщо макет потребує оновлення, модифікація файлу .css може бути достатньою.

Якщо помилка полягає в тому, що висновок критичного методу, який має специфікацію на 100+ сторінок, і доказ є неправильним, то саме дослідження може зайняти години чи дні. Це те, до чого відноситься стара «аксіома», і чого, серед іншого, намагаються уникнути TDD і спритний (невдалий та чіткий провал, зробити безпечний поступовий прогрес, яда).

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.