Що робити, якщо член команди пропустив планування спринту?

Скажімо, член команди у щорічній відпустці. Він не буде відвідувати планування спринту, але повернеться до середини ітерації / спринту. Скажімо, він має 50% ємності, тобто, як він буде доступний для подальшої половини ітерації, якщо:

1. провести сеанс планування з ним після його повернення.

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

3. не плануйте його для будь-якого завдання і не призначайте його на завдання, що не спринтують, наприклад, шипи тощо

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

5. змусити його сидіти з іншим розробником і робити програмування пари на деякий час.

6. будь-що інше..

мені цікаво знати, що ти робиш ..

Примітка. Ми робимо (1), і це не так.

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

провести сеанс планування з ним після його повернення.

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

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

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

не плануйте його для будь-якого завдання і не призначайте його на завдання, що не спринтують, наприклад, шипи тощо

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

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

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

змусити його сидіти з іншим розробником і робити програмування пари на деякий час.

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

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

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

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

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

Саме важкі часи говорять про те, наскільки професійна команда. У команді середнього розміру в нашій компанії завжди знайдеться людина, яка може пропустити зустріч з планування спринту. Ми не криміналізуємо його / її. Ми вважаємо, що він досить зрілий, щоб прийняти її / його рішення :)

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

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

Люди завжди прагнуть відпустки :-) ніякої шкоди не завдано.

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