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


13

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

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

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

Переваги я бачу в цьому:

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

Недоліки:

  • Сильний запах золотого молотка: програмне забезпечення для відстеження випусків зазвичай використовується для відстеження дійсних предметів
  • Організаційні накладні витрати можуть бути непропорційними: замість невеликої неформальної бесіди треба доносити свої ідеї в письмовій формі

1
Особисто я вважаю такі дискусії болісно повільними та неефективними. Принаймні, з Джирою та Редміном.
c69

1
@ c69: Так, це було моєю проблемою. Швидкий "ей, чи не повинні ці поля бути приватними?" стає формальним процесом, який може стримувати будь-яке подібне обговорення.
Озан

1
Дуже багато трекерів випуску інтегруються з компонентами для обговорення. . .
Wyatt Barnett

Відповіді:


8

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

У нашій реалізації Jira у нас є категорія "Ризик", тому ми використовуємо Джиру для відстеження предметів, які не підлягають дії, але мають можливість певним чином поставити під загрозу програмне забезпечення. Обговорення предмета відстежується, і як тільки ризик зникне (або зменшиться), питання закрито. Наведений вами приклад легко може перейти до категорії ризиків.

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


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

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

3

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

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

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

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

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

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

  3. Більшість рішень повинні бути прийнятними. Це може бути важко уникнути протиріч; але той факт, що рішення не є прийнятними і лише суб'єктивними засобами є можливості для майбутніх (помилкових) тлумачень.

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

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

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

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

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


1

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

Більш простим, вільним шляхом буде Асана.

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

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