Коли це добре, щоб відправити товар із відомою помилкою?

Коли це добре, щоб відправити товар із відомою помилкою?

Я припускаю, що ви говорите про "відому" помилку (питання не має сенсу інакше). Ну, відповідь залежить від цих факторів:

1) Хто є користувачем і як він / вони приймуть помилку, якщо її знайдуть?

2) Який потенційний вплив (пошкодження) клопа?

3) Чи можливо затримати відвантаження програмного забезпечення, щоб виправити помилку?

4) Найголовніше: чого ви очікуєте від свого програмного забезпечення? Час на ринок? Якість? Ви хочете дізнатися, чи ваші клієнти використовують програмне забезпечення досить довго, щоб знайти помилку?

Це має бути завжди гаразд, тому що немає такого поняття, як програмне забезпечення без проблем.

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

Тому подивіться на це з точки зору витрат / вигод.

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

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

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

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

Клопи бувають різної тяжкості. У будь-яких програмних компаніях, в яких я працював, ми класифікували помилки в порядку пріоритетності від P0 до P4.

P0 Чи програмне забезпечення не працює / виходить з ладу і може спричинити шкоду для клієнтів. P1 Він не працює як розроблений, і стабільно виходить з ладу в основній функціональності P2 Він періодично виходить з ладу, або частина бічної функціональності може не працювати. P3 Деякі елементи програмного забезпечення не працюють як розроблені / очікувані проблеми P4 Cosmetic.

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

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

Я ніколи не випускав програмне забезпечення з проблемою P0, P1 або P2, про яку я знав.

Це називається " Відомий випуск ". Google, Microsoft, Apple та ін., Всі товари, що постачаються з помилками, як відомими, так і невідомими Намагайтеся мінімізувати їх, але не чекайте досконалості. Доставка швидко, відправляйте часто.

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

коли це "особливість"! ;)

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

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

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

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

Часто краще вчасно доставити товар із переліком відомих проблем, ніж взагалі не відправляти.

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

Ось чому кораблі Ubuntu випускаються кожні півроку, навіть якщо є ще відкриті питання.

Я б сказав, що хорошим правилом є "це помилка шоустоппер?"

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

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

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

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

Як кажуть люди, це дуже широке питання. Насправді мене цікавить така перспектива: так звані «помилки», на які ви заявляєте, - це лише ті несправності, які були виявлені вашими тестерами. Тут може бути нескінченно більше лазівки. Щойно нагадав цікаву історію, яку я почув від одного шановного професора на одному випускному семінарі: Коли люди в одній із скандинавських країн використовували машину для голосування типу "почерк - невпізнаваний", певні люди зламали всю систему, написавши шкідливий код SQL (який система приймала як звичайний вхід).

Існує щось, що називається FMEA (режим відмов та аналіз ефектів), дуже корисно вирішити, коли відома помилка важлива чи не заснована на:

1. Виникнення
2. Суворість
3. Виявлення

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

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

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