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

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

Як ми маємо справу з цим?

Скільки деталей я повинен обговорити під час планування, щоб підходити до всього 2 годин на тиждень спринту?

Ви маєте рацію - 5 годин планування спринту на 1 тиждень спринт здається давно. Часові скриньки керівництва Scrum планують спринти до 8 годин протягом 1 місяця спринтів і кажуть, що "для коротших спринтів подія зазвичай коротша". Якщо врахувати коефіцієнт, хорошим показником може бути 2 години Спринт-планування на спринтер на 1 тиждень, але немає фіксованої часової скриньки.

Отже, як можна вирішити довге планування спринту?

Як майстер Scrum, я б зробив наступні кроки:

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

По-друге, я би переконався, що команда витрачає достатньо часу на вдосконалення відставання. Посібник з Scrum вказує, що заходи з уточнення зазвичай займають не більше 10% від потенціалу команди розвитку. Наприклад, Команда з розробки 4-х осіб, яка працює стандартним 40-годинним тижнем, повинна запланувати приблизно 16 годин уточнення відставання. Це може бути зроблено індивідуально, в малих групах або в команді. Я виявив, що запланований семінар з уточнення відставання для команди, а потім прорив, щоб зробити будь-яке дослідження або розслідування чи планування, як правило, працює найкраще.

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

З них може випадати більше кроків, але це було б хорошою відправною точкою.

Я чую тебе. Це занадто довго, щоб витратити! Сподіваємось, ваша команда обговорює це у ваших ретроспективах. Ми спробували кілька експериментів із змішаними результатами:

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

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

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

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

Мені подобається відповідь, яку ви отримали від @ Thomas-Owens, але я також додам ще один предмет. Чи розглядали ви програмування пар в рамках вашої реальної реалізації Agile?

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

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

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

Я бачу кілька червоних прапорів у тому, що ви пишете:

5 годинне спринтерське планування

Це занадто довго для спринцювання на тиждень.

Мета планування спринту - AFAIR to

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

Для того, щоб зробити це ефективно, кожна сторона повинна розуміти Product Backlog items.

Для того, щоб зрозуміти, Product Backlog itemsвідставання має бути в хорошій формі.

На етапі конкретного планування Product Backlog itemsперетворюються на Sprint Backlog items.

Однією з можливих причин є те, що ці пункти недостатньо уточнені / уточнені.

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

Обговорити дуже детально в плануванні спринту

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

З іншого боку: Спринт-планування очікує професійної поведінки від кожного учасника. Сюди входить уникнення обговорень на велосипеді .

Можливо, все зрозуміло, але хтось починає обговорення на велосипеді .

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

Оскільки більшість членів команди не є старшими

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

Помилки впровадження та оновлення під час спринту

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

Як я вже говорив вище: Поки Product Backlogперебуває у хорошій формі, важко буде пропустити суть.

Я не можу уявити таку ситуацію, як:

"Як користувач я хочу бачити кілька клієнтів!"

"О, ти не мав на увазі кожного з наших 2 мільйонів клієнтів?"

OTOH: Що означає перероблення цього контексту ? Якщо розробник обрав алгоритм з низькою ефективністю, то зрозуміла наступна мета: вибрати більш ефективний. Але це не “перепроектування”, це оптимізація.

До основних питань:

Як з цим боротися?

Банально згадати, але я це все одно роблю: не забувайте, що ви маєте справу з людьми .

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

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

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

Скільки деталей я повинен обговорити під час планування розміщення 2 годин на тиждень спринту?

Саломонівська відповідь: Як можна менше і стільки, скільки потрібно, але не більше.

тл; д-р

• Виберіть просту мову (якщо це допоможе, використовуйте просту англійську або ELI5), щоб уникнути непорозумінь

• Покращити збір вимог

• Поліпшення відставання

• Підвищити впевненість членів команди у своїх індивідуальних можливостях, а також у можливостях команди

• Уникайте велосипедів

• Поліпшити особисту дисципліну

• Можливо, використовуйте фіксовані часові скриньки для кожного пункту для обговорення

• scrum masterЕфективно зміцнюйте положення середнього та середнього рівня.

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