Чи спринти Scrum мають на увазі працювати в найшвидшому темпі?

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

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

Зараз я ще не займався Agile (працював з фінансовими та урядовими установами, які більшість все ще віддають перевагу водоспаду), але я розумію, що:

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

Чи правильні мої заяви? І чи варто сприймати презентацію менеджера як червоний прапор?

Не потрібно далеко шукати, щоб побачити, що ця практика суперечить принципам Agile. Один із принципів, що стоїть за маніфестом Agile:

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

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

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

Щоб безпосередньо відповісти на ваші запитання:

• да, Sprint це ім'я для ітерації в Scrum побачити цей відповідь на різницю
• так, команди повинні працювати стійкими темпами. Тільки впевненість в овертаймі, що це буде знижувати продуктивність команди в довгостроковій перспективі.
• так, це червоний прапор!

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

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

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

У цьому світі команда, по суті, каже: "Ми можемо виконати X роботу, протестувати та відправити цю ітерацію". Тож я би сподівався, що команда час від часу працюватиме понаднормово, щоб виконати ці зобов'язання.

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

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

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

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

І це добре. Впевнений, йому погано, маючи визнати наприкінці спринту, що спринт провалився, але це не поразка, це можливість для вдосконалення. Тому що в кінці спринту / початку нового ви маєте зробити ретроспективу спринту, і перше, що хтось запитає: «Чому ми провалили цей спринт, і що нам потрібно зробити, щоб не повторити його? ? '. Одним із варіантів було б позбавити меншої відданості (= зайняти менше очок історії).

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

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

З манефетів Agile Manifesto

Постійно працювати понаднормово для мене не здається стійким.

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

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

Це не Scrum. Пропоноване навантаження робочого часу для таймбоксу ґрунтується на швидкості роботи команди , а не на списку побажань менеджера. Вони просто намагаються вас обдурити, щоб повірити, що нескінченна понаднормова робота - це "Agile", чого це не так. Команда стане більш ефективною під час роботи безперешкодно та зосереджено, але Scrum - це не чарівна паличка для нескінченного підвищення ефективності.

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

Я здогадуюсь, ти знаєш відповідь ... ;-)