Чи реально велике збільшення швидкості в середовищі Scrum?

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

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

Ну, збільшити швидкість на 40% - це абсолютно просто - просто додайте на всі 40 оцінок більше на 40% балів і виконайте таку ж роботу.

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

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

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

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

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

Отже, чи шукаєте ви (у своїх ретроспективах) шляхи стати більш продуктивними як команда? Чи є у ваших спринтах щось, що регулярно витрачає непропорційну кількість зусиль? Чи можна його вирішити? Напевно, це не призведе до збільшення на 40%, але 5-10% - це початок, ні? У кожному спринті ви повинні шукати вузькі місця і вирішувати їх. Зрештою, ви можете наблизитися до мети, яку він вам поставив.

TL; DR

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

Коли швидкість плутається з цілями управління

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

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

Оцініть свої політичні можливості

У нас середня швидкість 50 точок історії ... Мене попросили збільшити її на 40% до 70 очок (без збільшення числа членів команди).

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

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

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

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

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

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

Я не розумію, яку роль відіграє ваш менеджер у команді Scrum? Він тренер? Він власник товару?

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

Більш імовірне: він знаходиться поза командою, можливо, власник продукту? Якщо так, він повинен зрозуміти, що робить таке дурне прохання, він просто припинив спритність.

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

Якщо він не хоче змінити нинішню мету, може бути досягнуто підвищення продуктивності на 40%, набравши в команду більше людей? Можливо, вкласти кошти в попереднє навчання для деяких членів команди? Команди також можуть набирати швидкість у часі шляхом постійного вдосконалення, але, безумовно, не шляхом довільного рішення.

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

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

У цьому випадку менеджер повернув неправильний напрямок після отримання чесної та вірної оцінки від команди. Менеджер повинен звернутися до зацікавленої сторони і повідомити їм, що їх вимоги не можуть бути виконані у встановлений час. Потім менеджер / аналітик повинен надати пріоритет, які з функцій ОБОВ'ЯЗКОВО бути включені, а інші, які можуть чекати (навіть, навіть, пару тижнів). Якщо зацікавлена ​​сторона нерозумна, то це може зажадати залучення вищих керівників, що, як правило, може бути складним і вимагати цілого іншого набору дискусій.

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

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

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

Здається, ви стикаєтесь з двома проблемами.

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

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

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

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

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

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

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

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

Де мені вдалося досягти збільшення, це було питанням:

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

• вдосконалення практики; спарювання, де це можливо (так, я виявив, що збільшує швидкість), витрачаючи час на рефактор агресивно (ditto!) та безжалісний щодо масштабу та фокусу

• пошук та / або придбання найкращих інструментів для роботи (наприклад, ReSharper для .NET важить ваги золота, Airbrake та Splunk для розробки Ruby тощо)

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

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

Візьмемо сценарій.

Протягом двох тижнів інтеракція може сказати 10 днів. Утопія була б 8 годин на день, причому сюжетна точка була абстрагована робочим днем. Тож, зверху, ваша оксамитовість була б 8. Але, релігічно, люди, мабуть, отримують 6 добрих годин на день електронною поштою, зустрічами, перервами у ванній кімнаті тощо. Отже, тепер ваш номер 6 на розробника. Отже, ваш базовий рівень - 6. Скажімо, ви хочете, щоб люди працювали понаднормово, зараз там по 10 годин на день. Отже, це було б 10 пунктів швидкості на розробника.

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

Але якщо ваші стабільні 50, дійсно, щоб дістатися до 70, знадобиться додаткові години.

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

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

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

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

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

Мені все одно подобається читати Філ Фактор на цю тему:

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

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

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

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

Рада не ставати «сумною і розлюченою» - найкраще, що можна отримати. Не бійтеся з технічно некомпетентним начальником з технічних питань. Він просто сприйме це як особисту атаку.

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

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

Що стосується мого досвіду та прямо до суті.

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

По-друге (передумова: не надуваючи, просто фокусуючи швидкість команди),

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

Вони зручні, зосереджені та оцінені? Що для них буде далі?

Це не "мене штовхають на межі" ... це більше як питання для всієї команди "Ми на межі?" і "Як ми можемо розсунути межі?" ...

У мене є провідні команди з високою ефективністю (для першої будівництва та / або міграції) ... мотивація команди є запорукою успіху ... а планування того, яким чином має бути база заявки, є важливим. Іноді я або театр отримую роль System Architect і вирішуємо, як і куди має йти «річ».

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

ПРОДАЖ ...

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

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

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

Покажіть історію завдань, прибуток від прибутку (за наявності), використаний вами сюжет, і покажіть, що ПРОДУКТИВНІСТЬ НЕ ЕФЕМНІСТЬ КОМАНДИ - це розрахунок, визначений командою для оцінки складності та, можливо, час, щоб отримати щось зроблено