Чи однакова оцінка часу дорівнює обіцянці в Scrum?

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

Чи працює команда Scrum ефективніше, якщо ми ставимося до оцінок часу як до обіцянки?

Скільки досліджень (підготовки, зусиль для розуміння проблеми) в історії достатньо, щоб скласти правильну оцінку?

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

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

У відповідь на ваше запитання «як власник продукту , як я можу поставити свої проекти поза часом в якості еталону?», Відповідь в тому , що ви можете і повинні мати час в якості посилання (тобто ви будете випускати на певну дату). Те , що ви НЕ повинні їсти точна сфера , яка буде знаходитися в постачанні.

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

1. Робота над найважливішою (прочитана: цінна) недоставлена ​​функція (завдання, вимога, історія користувача)
2. Успішно завершив кожну функцію, яка є більш важливою, ніж та, над якою вони зараз працюють (це стосується визначення "Готово : Кожна завершена історія перевірена, прийнята, помилка та завершена функція").

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

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

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

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

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

Етап, на якому ви берете на себе зобов’язання щодо доставки, - це коли ви приймаєте розповіді з відсталого продукту в спринт. Ви обіцяєте доставити ці історії в спринті.

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

Коли команда зробить достатню оцінку, вони стануть краще в цьому.

Ви також можете поглянути на ...

Чистий кодер (книга) - в цій книзі є розділ під назвою "Мова прихильності", а також розділ про оцінку, що насправді відкриває очі.

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

Ні.

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

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

І саме так ви можете бути впевнені в тому, що може дати команда, не даючи жодних випадкових обіцянок.

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

Ми з нетерпінням чекаємо в Agile. Зобов'язання не додають більше значення організаційному плануванню, ніж прогнозам.

Настійно рекомендую спритну оцінку та планування Майка Конна

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

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

Чи працює команда Scrum ефективніше, якщо ми ставимося до оцінок часу як до обіцянки?

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

Скільки досліджень (підготовки, зусиль для розуміння проблеми) в історії достатньо, щоб скласти правильну оцінку?

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

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

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

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

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

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

Найпоширеніший спосіб визначення проекту - це перелік його функцій. Зазвичай проект завершується, коли всі функції були реалізовані. Але що робити, коли ви працюєте над проектом, ви розумієте, що 5 ознак, визначених на початку створення, не знадобляться, але є 7 особливостей, про які люди думали за перші 6 місяців, які дійсно повинні бути включені? Що це стосується питання, скільки часу це займе?

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

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

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

Так ні, оцінка не є обіцянкою. Це оцінка. "Обіцянка" - це зобов'язання, яке Команда бере на виконання певної кількості особливостей або історій у конкретному спринті.

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