Як вплинути на пріоритети помилок перед розробниками та обробляти їх відповідно?

У нас є процес помилок, над яким зараз працює.

У нас є 3 рівні помилок:

Помилка P1: помилки, які не дозволяють користувачам працювати. Вони повинні бути вирішені на місці.
Помилка P2: помилки, які впливають, але користувачі можуть працювати
Помилка P3: Помилки, які не впливають на них і де користувачі можуть працювати.

P1 є обов'язковим і повинен бути розроблений на місці. Але щодо P2 та P3, ми судимо в кожному конкретному випадку.

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

Питання такі:

Чи слід додати інший рівень пріоритету, наприклад, P4?

Чи повинен я також призначити їм цілі поводження з невідкладними квитками, як на цьому тижні, коли не призначити завдання кодування, вам слід обробити принаймні 1 P2?

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

Оновлення:

Мені було запропоновано це питання з точки зору подібності. Однак він зовсім не схожий.

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

agile debugging issue-tracking

— Енді К
джерело

Можливий дублікат Як я можу переконати керівництво боротися з технічною заборгованістю?

— гнат

зазвичай рівень пріоритету не такий корисний, як упорядкування пріоритетів ... "помилка X" важливіша, ніж "помилка Y". якщо ви додасте p4, врешті-решт, ви захочете p5 та p3.5

— sudo rm -rf slash

Якщо у вас є так багато помилок P1 , що всі ваші розробники завжди зайняті фіксування їх замість того , щоб працювати на P2 / P3, ви робите що - то дуже неправильно. Не додайте більше функцій на деякий час. Зосередьтеся на висвердленні та вирішенні архітектурних (або кадрових) проблем, які майже напевно спричиняють багато цих помилок. Наприклад, якщо ви кодуєте в C ++, переконайтеся, що ви використовуєте RAII скрізь, де ви можете, щоб не забути вручну .release().

— Позов по

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

— sleske

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

— mattnz

Відповіді:

Як правило, у вас є дві осі для помилок: гравітація та частота.

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

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

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

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

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

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

Удачі!

— Ніл
джерело

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

— corsiKa

@corsiKa, так, ROI - це складова метрика: "повернення" та "інвестиція". А для помилок повернення можна моделювати як складовий елемент "гравітації" та "частоти".

— Пол Дрейпер

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

— Wildcard

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

— corsiKa

@Wildcard і corsiKa компанія не велика, і ми не можемо дозволити собі сказати "ой ми втратимо гроші, тоді давайте зробимо щось інакше, давайте тримати його на цьому". Однак у грандіозній схемі речей я не вірю, що підхід, про який ви згадали, є довготривалим. Люди - Клієнти далеко не дурні. Компаній, які проповідували таке євангеліє, Sun, щоб його назвати, вже немає. Я працюю в управлінні рахунками досить довго, щоб гроші не заробляли таким чином. Для когось, якщо вам трапляється працювати в такій компанії, де компанії не вистачає лояльності 1 / n

— Енді К

Це дійсно зводиться до того, що ви вважаєте важливішим. Помилка P2 чи нова функція?

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

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

Це справді найголовніше. Прості правила, такі як "виправити принаймні 1 P2 на тиждень", не дуже допомагають досягти цієї мети.

— Еван
джерело

Проблема з призначенням пріоритетів полягає в тому, що незалежно від того, яка деталізація ковша ви виберете, ви завжди отримуєте більше одного на відро. Потрібно навести порядок, а не просто сказати "все це ТОП ПРІОРИТЕТ!"

— Еван

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

— kasperd

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

— kasperd

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

— Еван

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

— Балдрік

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

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

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

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

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

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

— AnoE
джерело