Коли мій менеджер сказав команді, що " зараз успішні історії користувачів будуть розглянуті для оцінки! "
Ми сиділи там, поки шоковані, і це був один із декількох моментів скидання щелепи, які він дав нам :-)
Ми вважали це дурною ідеєю, оскільки це зруйнує всю концепцію та мету методології спритного розвитку.
Дайте мені знати, що ви думаєте? і як ми можемо його переконати?
Відповіді:
Сенді, на жаль, заява твого менеджера - це класичне непорозуміння скандалу зокрема та спритного взагалі.
Запропонований підхід вбиває співпрацю і протидіє принципу колективного володіння кодом . Історії користувачів у спритних (якщо це справжній спритний) рідко завершуються, перш ніж їх торкаються кілька людей. Крім того, час від часу у вас з’являться історії користувачів, які потребують роїння , щоб закінчити ітерацію. Як ви все отримаєте, коли окремі стимули вирівняні на 180 градусів у зворотному напрямку?
Інстинкти ваших команд правильні. Які джерела я б запропонував у короткостроковій перспективі прочитати, коли ви штурмуєте відповідь своєму менеджеру? Подивіться блоги відомих спритних експертів, таких як Майк Кон , Мартін Фаулер , Елізабет Хендріксон , Юрген Апело , Естер Дербі та кілька інших, і шукайте статті про спритну організацію команди.
Моє основне заперечення проти цього методу оцінки полягає в тому, що він може стати перешкодою для співпраці між розробниками. Я думаю, що важливою частиною продуктивності команди розвитку є готовність членів команди допомагати один одному. Як я розумію запропоновану схему, це може призвести до того, що розробники дотримуватимуться власних завдань і ігноруватимуть інших членів команди, які застрягли і могли легко відклеїтись за невеликої допомоги.
Ми завжди шукаємо внесок програмиста в команду та бізнес.
Це нарівні до вимірювальних рядків коду чи кількості помилок - але трохи складніше.
На перший погляд з вимірюванням нічого поганого, але коли ви задумаєтесь, ви почнете заперечувати:
є найбільш очевидним, який спадає на думку - я впевнений, що є й інші.
Ваш менеджер, очевидно, вважає, що це гарна ідея, тому вам потрібно бути обережним, що, коли ви висуваєте заперечення, ви також можете представити рішення. Це рішення, можливо, має бути модифікацією його схеми, а не новою схемою.
Так, наприклад, ви можете хотіти зазначити, що хтось, хто просто працює над "легкими" історіями, завершить більше, ніж хтось, хто працює над більш "складним", і це може призвести до концентрації на менш важливих аспектах розвитку. Таким чином, одним із варіантів може бути врахування кількості точок історії, а не просто кількості історій.
Я погоджуюся з ChrisF, що це повертається до тієї ж проблеми з будь-яким вимірюванням. Те, що ви хвалите, те, що отримуєте. Завжди знайдуться люди, які грають у систему, якою б не була ця система.
Єдиний реальний ефективний метод, який я знайшов для нагородження програміста, - це три кроки.
Вся справа в тому, що програмісти не є гвинтиками в машині, яку можна «налаштувати», переглянувши статистику. Справжніх людей потрібно оглядати і вдосконалювати в цілому, і команда повинна мати можливість покладатися один на одного в кооперативі, а не в конкурентному порядку.
Бідним виконавцям в колективі надаються всі можливості для вдосконалення та збагачення, перш ніж їх вважати відпущеними. Зрештою, хороші програмісти будуть процвітати в цьому середовищі, і погані програмісти, які відмовляться від покращення, будуть відпущені.
Більшість часу Історії користувачів завершуються колективними зусиллями. Це робить практично неможливим базувати індивідуальну оцінку на цій метриці.
Самою метрикою можна легко керувати, оскільки процес планування - це також зусилля команди, і навіть раніше, ніж пізніше, вся система буде сфальсифікована. Це точно те, чого ви не хочете, щоб процес, орієнтований на людей.
Я думаю, що хороші показники повинні бути визнані якоюсь системою бонусів на основі успіху команди, але Історії користувачів не є хорошим показником успішності.