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

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

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

1. Це прийнятна / поширена варіація Scrum, про яку я не знаю?

2. Як ви пропонуєте мені діяти з цього приводу?

Кілька речей мені виділяються.

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

Ідея цілей важлива для Scrum. Не тільки організації та команди мають широкі цілі, але в Scrum кожен спринт має ціль спринту, яка визначається в Sprint Planning як співпраця між Власником продукту та Командою з розробки. Мета Sprint досягається шляхом впровадження елементів із Блоку продукту, але це не просто "закінчити цю частину роботи", і вона часто не представляє собою повного Блоку спринту. Тобто ви повинні мати змогу досягти цілі спринту, не виконуючи кожного окремого продукту "Блокування продукту", вибраного для спринту або кожного окремого елемента в "Блоку спринту". Я думаю, що робота, необхідна для досягнення мети спринту, повинна становити близько 60-70% від вашої спроможності команди, проте ви враховуєте її. Хоча різні організації будуть різними, але це "

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

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

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

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

Що ви можете з цим зробити, залежить від вашої ролі.

Якщо ви розробник, то найкраще ви можете це зробити

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

Якщо ви майстер Scrum, то справді можете довести свою цінність, навчаючи керівництво про Scrum. Деякі мої моменти, які виділяються мені:

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

Ваш прем'єр-міністр не має участі у вашій сутичці.

Ваш прем'єр-міністр не має жодної справи з проханням про неоплачувану понаднормову роботу.

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

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

Деякі речі, які ви можете розглянути:

Занадто багато у спринті

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

Розподілення ресурсів

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

Оцініть варіацію

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

Швидкість

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

Добра воля

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

Шипи

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

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

Якщо ви будете спритними, вам потрібна гнучкість, щоб скинути Історії зі спринту, який ви не зможете завершити вчасно. Один із можливих способів зробити це - попросити власника продукту оцінити історії, використовуючи пріоритетність MoSCoW. Це передбачає, що не більше 60% Історій (за загальною кількістю оповідань) повинні бути заповнені, 20% - як слід, якщо ви повинні завершити проект, і мінімальний життєздатний продукт буде випущений, 20% як Могли б Haves, які можуть бути завершені, якщо у вас є час, і що-небудь поза сферою поточного випуску як Won't Haves. Також важливо зауважити, що в поєднанні «Мус Хавс» повинен мати достатню кількість м’яса до кісток, щоб створити мінімальний життєздатний продукт, не потребуючи включення будь-яких предметів з інших категорій.

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

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

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

Але його підхід не є вдалим.

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

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

Ваш Прем'єр-міністр ( що навіть РЧ робить у команді Scrum ?? ) не повинен дозволяти Майстру Scrum, щоб змусити вас закінчити всі історії. Натомість, якщо у нього є скарги, він повинен утримати їх на ретроспективі. А ще краще, має бути частиною вирішення проблем, які заважали закінчити розповіді вчасно.

Це прийнятна / поширена варіація Scrum, про яку я не знаю?

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

Як ви пропонуєте мені діяти з цього приводу?

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

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

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

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

FAQ про зобов'язання

Це нормальна поведінка?

Я не впевнений.

Це дивно?

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

Це гарна ідея?

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

Що нам робити?

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

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

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

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

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

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