Рання підзадача на початку кожного спринту

Я приєднався до нової команди, яка використовує Agile / Scrum, і процес їх розробки такий:

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

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

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

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

Але я вважаю це контрпродуктивним, головним чином, з наступних причин:

• якщо мета полягає в тому, щоб дати орієнтовну оцінку, то, що робить роботу, бали історії (крок №2). Інакше навіщо взагалі турбуватися з сюжетними моментами? - просто робіть підзадачі на початку.
• якщо метою є надання точних оцінок, то це наочний приклад того, що описано в « Перемикачах завдань людини», які вважаються шкідливими . Думаю, це особливо стосується нових розробників, які приєднуються до існуючих команд у великих проектах, де розуміння того, що потрібно зробити, може зайняти до 50% часу. Ви зобов'язані детально розповісти про історію №1, потім історію №2, №3 і т. Д. І т. Д., Що дає багато інформації.

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

Це не відрізняється від того, як ми запускаємо частину нашого процесу scrum. Ми

1. Оцініть історії біля вершини відставання в "точках історії"
2. Виберіть / поясніть історії на основі сюжетних точок, які, на нашу думку, "складуть" спринт
3. Розбийте розповіді на детальніші технічні завдання
4. Оцініть технічні завдання та порівняйте з початковою оцінкою балів (ми знаємо приблизно, скільки часу дорівнює точці розробки)

Але те, що ви хочете знати, - це чому ми оцінюємо двічі!

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

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

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

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

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

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

• Ви робите поломки індивідуально - так як ваші молодші / недосвідчені члени команди навчаються у старших членів команди? Звичайно, вони, ймовірно, можуть все навчитися самі - але вони навчаться швидше, якщо пройдуть менеджмент. Чи потребують молодших членів команди тривалий час, щоб розбити речі? Чи роблять вони помилки чи пропускають речі, які в довгостроковій перспективі коштують команді? Тут може допомогти складання команди як команда.
• Ви робите оцінки окремо - те саме стосується першого пункту, але крім того, чи є ці оцінки менш точними, ніж вони могли бути?
• Здається, що завдання ставляться на початку спринту, але якщо це так, то наскільки дорого ви його знаходите, коли вам доведеться змінити завдання? Якщо хтось відстає або захворіє, як легко комусь забрати свої завдання? Чи потрібно їм пройти розбивки завдань і намагатися їх зрозуміти, не перебиваючи початкового правонаступника? Якщо ви розбиваєтесь та оцінюєте як команду, то кожен повинен мати можливість працювати над усім!
• Ваші історії занадто великі? Якщо розбиття займає 50% часу, історії звучать так, ніби вони дуже задіяні - можливо, їх можна зменшити? Ми зберігаємо свої історії протягом 1 тижня роботи людини.
• Ваші завдання занадто малі? Якщо ви витрачаєте тривалий час на складання списків завдань, можливо, ви заглиблюєтесь у занадто багато деталей? Ми, як правило, виконуємо завдання від 1 до 8 чоловічих годин роботи, так що протягом дня кожен досягає певного прогресу, щоб звітувати в наступному щоденному складі.

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

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

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

Це теж моя думка. Я пропоную спробувати для себе і виміряти результат - подивіться, що я там зробив :)

Я б припустив, що ваш спринт Kickoff означає зустріч з планування спринту. Я думаю, що ваш майстер Scrum неправильно трактував, як має пройти ця зустріч. Ви не тільки вирішуєте, які історії розробляти, ви також перевіряєте їх у своїй команді. Її визначення готове переконатися, що вони нічого не пропустять (як правило, використовуючи ІНВЕСТ ), а також поділите ці історії на завдання. Цитувати Майка Конна (одного із засновників Альянсу Scrum);

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

Тож розбиття історій та їх оцінка - це частина сеансу планування спринту; не після закінчення сесії планування, а не окремо.

Для отримання більш глибокого розуміння наш робочий процес під час зустрічі з планування спринту такий:

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

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

3. Промийте та повторіть, поки не досягнемо загальної оціночної кількості балів

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

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

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

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

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

Після наради ви все ще можете призначити час завданням (хоча я не бачу сенсу цього, спринти не базуються на часі, вони базуються на "скільки речей ви розраховуєте зробити", що вимірюється в балах історії , а не час. Це поширена проблема з scrum, бали не означають часу, але вам доведеться виконати, скажімо, 20 балів за тиждень, тому 2 бали = 1 день роботи. Це має бути швидкою здогадкою, скільки завдань поставити у спринті, щоб ви не перевантажувались і не працювали, не скільки насправді будете виконати. Найкращими спринтами є ті, у яких залишилось пару завдань, що показує, що ви оцінили відмінно. затримка їх завершення в кінці - і це не є результативним).

Отже, коротше - роздрукуйте копію Agile Manifesto out та антигігічну версію . Б'юсь об заклад, ви робите більше анти, ніж спритний. Scrum, як правило, такий. Єдиний спосіб виправити це - співпрацювати зі своєю командою та отримувати внесок для змін. Не дозволяйте керівництву розповісти, як працює ваша команда, це теж не спритно, і це буде написано в Книзі.

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

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

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