Як зупинитись / уникати з часом команди Scrum?

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

Мої формальні питання:

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

2. Якщо так, то які методи / інструменти ви пропонуєте?

   • Система контролю ревізії (SVN, GIT, HG тощо), блоки по годинах (8 - 5)
   • Блоки робочих станцій по годинах (8 - 5) або кумулятивних годин (до 8 годин / день)?
   • Інше

3. Або, може, не жорстко блокуйте подібні речі; але впровадити деяку "систему покарань " за невиправдані додаткові години ?

@Baqueta (та інші з подібними питаннями): Ні, їм не платять за додаткові години. Першою моєю порадою було переглянути їхні оцінки, бо, можливо, вони недооцінювали. Це була моя улюблена порада:

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

Крім того, я вважаю, що корінна проблема (для цієї команди) - це поєднання наступного:

1. Розробникам кажуть, чого вони повинні досягти у спринті / не консультуються щодо того, що можна досягти / ігноруються, коли кажуть, що надто багато роботи.
2. Розробники послідовно недооцінюють, скільки часу займуть завдання / скільки одиниць роботи бере участь у кожному завданні.

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

Відверто кажучи, ті "жорсткі блоки", про які ви згадуєте у №2, - це найгірша ідея, яку я чув за тривалий час. Що станеться, якщо помилка з першочерговим пріоритетом буде знайдена о 16.45, а хлопець, який має можливість переосмислити ваші блоки, не захворів? Щодо №3 - ви пропонуєте покарати людей за те, що вони виконують свою роботу .

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

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

Якщо у спринтах занадто багато роботи, зазвичай це з однієї з трьох причин:

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

Якщо це №1, ви робите це неправильно . Немає двох способів про це!

Якщо це №2, звичайною причиною є недосвідченість - або з оцінкою часу, або з системою, що розробляється. Хороший спосіб цього - припинити робити оцінку часу і почати оцінювати "одиниці роботи". Скористайтеся якоюсь абстрактною одиницею, просто переконайтеся, що це не години реального часу (зрештою ви все ще представляєте часовий інтервал, але абстракція важлива!). Потім ви можете почати підрахувати, скільки одиниць роботи насправді виконується за тиждень, а потім налаштувати спринти за допомогою цих даних.

Якщо це номер 3, вам потрібно якось почати факторинг у цих інших завданнях. Якщо це узгоджується, це слід легко пояснити (див. №2 вище). Якщо це часто, але непередбачувано, з цим набагато складніше впоратися. Ви хочете ознайомитись з тим, чому це відбувається (наприклад, серйозні помилки в «живому» коді => чи достатньо ретельне тестування?), Але якщо цього не вдається виправити, то в кінцевому рахунку scrum може бути не правильним підходом для вас. Нещодавно моя команда перейшла на Kanban саме з цієї причини ...

Редагувати: Уточнив мою критику до ідей, поданих у питанні.

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

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

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

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

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

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

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

Просто скажіть команді не працювати понаднормово. Період.

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

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

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

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

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

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

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

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

Щоб уникнути понаднормових робіт, вам доведеться скоротити масштаби проекту.

Наведений нижче графік показує, де в проекті лежить невизначеність:

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

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

Якщо ваша команда може обробити 10 квитків за 5 днів, і їм присвоєно 20 квитків, зменшіть цю кількість, відправте її власнику продукту / керівнику проекту / менеджеру / клієнту та скажіть їм розставити пріоритети.

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

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

Я раджу проти "жорстких блоків". Такий контроль може сприйматися як мікроуправління та може не вирішити основну проблему.

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

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

Причини навантаження можуть бути

• Закінчене відставання занадто велике
• Або програмісти, або власник продукту є "позолоченими" (роблячи функції складнішими, ніж потрібно)

Очікування можуть бути

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