Чи є законними частинами процесу торги та спроби збиття оцінок Scrum?

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

PO часто намагається збити такі оцінки, як-от: "Що, ви хочете 13 очок історії [4 дня] для цієї історії, це не може бути! Я не можу пояснити це керівництву, хтось повинен мати можливість кодувати це з 3 СП [за 4 години]! ". Як результат, розробники отримують вивернуту зброю, щоб взяти на себе оцінку 5 або 8 історій [1,5–2 дні] (оцінки Scrum все ще приймаються як зобов’язання, а не лише прогнози).

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

Можна сказати: "Не варто брати на себе неможливе зобов'язання, просто тому, що хтось підштовхує вас до цього!" Але, на мою думку, завдання розробника - це розробка та кодування програмного забезпечення, а не торгування чи протистояння тиску! Можливо, є крани всіх торгів, як правило, ті, що мають справу безпосередньо із зовнішніми клієнтами, але це не більшість офісних розробників!

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

Що говорять про ці теми вказівки Scrum чи вони щось на це говорять?

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

EDIT 2 Наразі не існує спеціалізованого майстра розробки, і PO бере таку роль, коли йдеться про збори з оцінки. Тому, ймовірно, рольовий конфлікт робить цей недоречний торг ще гіршим, оскільки він виступає як авторитет, а не нейтральний або розробник scrum master. Можливо, це можна виправити, сприйнявши його як упередженого учасника замість «господаря», доки немає жодного.

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

Якщо ви хочете визначити місто http://www.scrumguides.org/scrum-guide.html як орган, я б виділив:

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

і

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

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

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

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

Якби я був розробником, і мене перекручували, називаючи 13-точкову історію 8-бальною історією, я б із задоволенням зобов'язувався. На свої можливості оцінювання вони впливають. Я просто розмалюю всі свої труднощі, щоб відповідати. Врешті-решт швидкість команди зменшиться в частині сюжетних точок на тиждень, щоб відповідати готовності керівництва "викреслити" сюжетні точки. Цифри, що передаються керівництву, повинні відповідати: "Ми успішно зменшили кількість сюжетних точок роботи, необхідних для досягнення етапу на 50%. Однак ми побачили відповідне зниження швидкості на 50%, тому чистий ефект - це ми збираємось виконати саме те, що ми мали намір виконати саме за той час, який він збирався зайняти ". Поняття швидкості існує для боротьби з бажаним мисленням вищого керівництва.

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

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

Для одного, PO не повинен давати інформацію про завдання керівництву. Оцінки завдань суворо на благо колективу. Єдине, що повинен знати хтось поза командою - це над якими історіями вони працюють, які їхні точкові значення та яка середня швидкість команди. Т

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

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

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

Що говорять про ці теми вказівки Scrum чи вони щось на це говорять?

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

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

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

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

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

Команда несе відповідальність за якість продукції, яка ніколи не повинна відкриватися для ведення переговорів.

Так і ні.

Так, команда спринту повинна домовитися з власником продукту щодо чого потрапляє у спринт.

Ні, власник продукту отримує ні те, скільки часу триватимуть речі. Ви експерти, а не вони.

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

"Ні."

Що вони збираються робити? Написати код самі?

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

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

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

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

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

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

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

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

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

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

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