В ідеальному світі бажано дотримуватися терміну з меншими помилками. Але з вашого досвіду, який є більш переважним / прийнятним:

1. Дотримуйтесь терміну, але має ряд помилок, оскільки розробник кидається в речі
2. Менше помилок, але не зовсім відповідає терміну, оскільки розробник дуже жорстко пише код

Відповідь на це питання сильно залежить від бізнес-цілей, а також клієнта.

Підприємство :

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

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

Стартапи :

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

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

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

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

або ... 3. Виріжте неістотні функції

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

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

Переговоріть

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

Іноді в терміни вимагають програмне забезпечення, що працює на високому виробничому рівні з першого дня. Менеджери / клієнти не завжди знають (що в більшості випадків), що їм насправді потрібно для програмного забезпечення. Тому намагайтеся скоротити неістотні функції та зберегти якість. Зрештою, це залежить від того, наскільки критичним буде виробниче середовище, але спробуйте вирішити додаткові можливості та забезпечити якість. Цитую ще раз із "Переробляти":

Зробити пізніше також означає зробити краще

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

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

Дотримуйтесь граничного строку та представляйте список відомих питань.

Люди ненавидять знайти помилок, але якщо їм сказали наперед, вони, як правило, набагато м'якіші.

Це повністю залежить від ситуації….

Є багато факторів, які слід враховувати:

1. Наскільки легко розгортати патчі?
2. Чи можливо випустити основну, зняту версію, а потім виправити новий функціонал (крайній регістр) за часом?
3. Яка загальна культура галузі клієнтів для такого продукту? Вони очікують одноразових досконалих випусків, або вони звикли до ідеї розвиваючої системи, яка може бути баггі при першому випуску?
4. Скільки ризику для бізнесу створює баггі-початкова версія, на відміну від прострочення терміну?

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

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

ПРИМІТКА: Звичайно, як програміст, я віддаю перевагу ідеї максимально відшліфувати продукт перед тим, як його розблокувати (чорт, я швидше не матиму жодних термінів, ніколи;)). Але реально це неможливо в реальному житті. Часто позбавлений початкового випуску є хорошим рішенням середнього рівня.

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

Я думаю, це залежить від помилки. Ви хочете затримати випуск, щоб виправити помилку, коли додаток вибиває з моменту запуску на будь-якому комп’ютері? Однозначно так. Чи потрібно виправляти помилку, яка трапляється лише в Windows ME, поки немає повного місяця? Це, напевно, може зачекати.

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

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

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

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

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

1. Якість, введена в код = на 2 менше функцій на збірку
2. Визначення пріоритетів найвищих необхідних функцій від зацікавлених сторін щодо того, що їм дійсно потрібно.

Тоді ви можете зосередитись на особливостях найвищого значення та витіснити їх із досвідом.

Що ж стосується тестування, воно ніколи не закінчиться. це закінчено, але так і не закінчено.

Ідіть на запуск з помилками з серйозністю і більш пріоритетними обережно.

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

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

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

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

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

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