Чи слід повторно відкривати справи про помилки, або помилки слід відкривати як новий випадок?

В даний час на моєму робочому місці ми використовуємо FogBugz для управління всіма нашими функціями та помилками для різних наших веб-додатків.

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

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

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

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

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

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

Я маю рацію, заявляючи, що помилки слід знову відкрити як новий випадок? І які плюси / мінуси кожного способу управління цим?

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

Для таких випадків, як ваш, я використовую підхід до підзадач на високому рівні (концепція, яку я вибрав у JIRA , не можу сказати, чи підтримує FogBugz це явно ^{виглядає так} ). Таким чином, "маркеризовані" клієнтські списки переходять до завдань високого рівня, тоді як "важливі для мене ітерації" відображаються в підзадачах.

Коли завдання на високому рівні "повторно відкрито", я створюю нову підзавдання для відстеження додаткових зусиль для себе .

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

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

_{Що стосується відстеження часу за завданням або підзавданням - оскільки JIRA дозволяє включати відстеження підзадач у підсумок вищого рівня, менеджеру прийнятно, що я відстежую час у підзадачах. Однак, навіть якщо це не відбудеться, я міг би жити з формальним відстеженням часу в "батьківському" завданні - у цьому випадку я просто використовую коментарі підзадач, щоб вказати, скільки часу було витрачено на певну ітерацію.}

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

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

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

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

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

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

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

Чи виявлені помилки до або після того, як продукт був "відвантажений / випущений" клієнтам?

Якщо це до випуску, помилки слід відстежувати щодо оригінального квитка.

Якщо це після випуску, у кожної помилки має бути власний квиток.

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

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

Ця система, здається, працює добре для нас.

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