Agile MVP (найцінніший гравець / програміст)

Нещодавно я брав участь у гнучкому проекті (використовуючи scrum), де керівництво придумало, що команда призначить розробника "MVP", а також QA "MVP" в кінці кожного спринту, проголосувавши за команда. Потім MVP отримує невелику грошову винагороду та безкоштовний обід, а також трофей, який можна виставити на своєму столі. Наразі у нас було два спринти, коли ця система нагородження була створена.

Я добре бачу з цього:

• Виправлено більше помилок (це те, що хоче бачити вище керівництво. Зміна числа в напрямку, в якому вони хочуть)
• MVP від ​​кожної 'команди' визнається і отримує підвищення самооцінки (або це підвищення его?)

Я зауважив декілька, що вважав би поганими сторонами такого вчинку (принаймні, з точки зору розробника):

• Є кілька розробників, які настільки переймаються кількістю, що якість виправлень помилок знизилася. Виправлення в одній області викликають регресію в іншій.
• Є декілька розробників, які вибирають помилки з вишнею «легше / швидше», щоб збільшити кількість помилок. Можливо, тут може бути погано погано.
• Вищі пріоритети (які багато часу співвідносяться з "важче / довше виправити") дефекти фактично стають нижчими.
• Блокування дефектів не вирішується своєчасно, оскільки зазвичай це займає більше часу і вимагає більшої координації з QA.
• Командний аспект у команді Dev втрачено. Командний аспект Dev та QA, які працюють разом як один, також не покращився, але насправді не змінився занадто сильно раніше.
• Працювати за виправленнями помилок або працювати на ТОМУ номері не легко розпізнати / відстежити.

Я вважаю, що кожен із "поганих" вище можна вирішити певною мірою, залежно від того, як команда поводиться з ними.

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

Agile підкреслює зусилля команди , а не зусилля окремих людей. Тож ні, такий підхід явно не спритний.

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

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

Я думаю , що це хороший приклад -bad- Gamification застосовується. Проблема полягає в тому, що ваші програмісти потенційно мали внутрішню мотивацію у вирішенні проблем та вигравали, хоч проблеми (пошук та виправлення важких помилок) І, оскільки ви впровадили Scrum, працюючи як КОМАНДА. Іншими словами, вони потенційно хотіли зробити добру справу.

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

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

Що ви можете зробити, щоб виправити це, - попросити керівництво трохи змінити правила:

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

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

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

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

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

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

Вибирати прості виправлення та робити їх у швидкій чи випадковій формі не варто, тому розробники, які просто роблять це, мабуть, не повинні кваліфікуватися як кандидати в MVP. Вибираючи новий MVP, забудьте про команду та людей у ​​ній, і подивіться на програмне забезпечення. Виберіть найважливішу зміну цього програмного забезпечення за останній час. Я маю на увазі одинокий тут; "не так багато крихітних помилок" - це не велика зміна. Чи виправлена ​​особливо кричуща помилка? Додана нова чудова функція? Визначивши, що це за велика зміна, запитайте, хто за це відповідав. Один з цих людей, ймовірно, ваш фактичний MVP. Якщо "не так багато крихітних помилок" - єдина різниця, тоді і тількито вважається помилка підрахунком дійсної міри MVP - і навіть тоді я б дивився на співвідношення помилок, виправлених до регресійних помилок, викликаних. Кожна помилка, яку хтось викликає, віднімає принаймні 1 зі свого числа. Насправді я б сказав більше 1, тому що неправильне виправлення призведе до невідомої помилки, яку потім доведеться знайти, що гірше, ніж відома помилка, яка вже знайдена. Відома помилка потребує виправлення розробника; невідома помилка вимагає QA, щоб знайти, а розробник виправити, і тоді є ризик, що QA пропустить її.

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

І ей, якщо все інше не вдасться, забудьте програму MVP. Порадьтеся зі своїми колегами-розробниками поза межами scrums та вкажіть на негативний вплив, який надають нагороди MVP на програмне забезпечення. Подивіться, чи можете ви змусити їх ігнорувати це чи не зробити це таким чином. Залиште трофей у шухляді, витрачайте грошовий приз на круглі напої для команди після роботи, використовуйте безкоштовний обід, щоб отримати щось, чим зможете поділитися, як, наприклад, купу кексів. Agile - командна система; підкреслюючи індивідуальні результати діяльності, ризикуючи накладати команду один на одного. Об'єднавшись ви стоїте, ви розділили програмне забезпечення, заповнене помилками, після закінчення терміну, перевитрати бюджету.

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

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

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

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

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

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

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

• Нехай будь-хто дасть «командне кудо» будь-яким (і всім, не лише одному) особам, які наочно сприймають цінності вашої команди. Це сприятиме передбачуваності демократизації системи цінностей команди за допомогою прикладів. (Ми насправді робимо це в нашій команді ..)
• Почніть програмування пар (або призначте "приятелів помилок") для всіх виправлень помилок. Це сприятиме якості, відмовляючи від поспішних або напівперевірених програмних рішень та заохочуючи послідовність, оскільки приятелі будуть гартувати хаотичну поведінку. (Ця ідея зазвичай пропонується під час семінарів, здається інтуїтивно зрозумілою.)

І це лише кілька прикладів, щоб продемонструвати підхід та розпочати роботу ...

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

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

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

Нагороджуйте роботу в команді, і команда помітить, що важлива саме КОМАНДА, а не їх особистий успіх.