Деякі члени команди не беруть активну участь у плануванні спринту

15

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

Я певним чином розумію цю позицію. Чому слухати дискусію про функцію, яка навряд чи допоможе вам розвиватися у спринті чи коли-небудь?

Як ви думаєте, що нам робити?

agile scrum

— Євген
джерело

9

Наскільки велика ця команда?

— JeffO

8

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

— Джиммі Хоффа

7

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

— користувач1019696

5

@ user1019696, щоб бути справедливим, я міг отримати телефонний дзвінок від дружини про те, що моя дитина в будь-який час поламав ногу. Існує велика різниця між "вимкненими телефонами" та "не будьте **** з телефоном посеред зустрічі, тому що це просто неповажно".

— Джиммі Хоффа

4

@jwenting Ви говорите про епоху, коли були секретарі компанії, у компанії, в якій я працював роками, не було такої людини - їм би нічого робити. І ні, це не може чекати. Особливо не для роботи, вибачте, але сімейні> роботи. Це сказав, що я, можливо, дзвоню в середині 1 з 30 або 40 зустрічей (можливо ??), з яких я, мабуть, відповідаю 1 на 30 або 40 ... Не важко не бути ривком зі своїм телефоном. Якщо люди потребують їх інвалідів або відстороняють від своїх осіб, щоб не бути ривком, можливо, ця людина просто ривок.

— Джиммі Хоффа

32

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

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

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

— pdr
джерело

4

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

— JeffO

3

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

— jwenting

3

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

— GrandmasterB

1

@jwenting Це суть спритного. Щоб змінити подібний погляд на речі.

— Ейфорія

1

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

— jwenting

15

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

— jwenting
джерело

12

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

— Том Сквайрс
джерело

3

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

— jwenting

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

— JeffO

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

— jwenting

1

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

— Дейв Хіллєр

5

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

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

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

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

— gbjbaanb
джерело

Гарні ідеї. Сподіваємось, люди не сприйматимуть це як марну часу.

— Євген

1

Яка тривалість спринту?

Більш тривалі спринтерські спричини

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

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

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

— Піт
джерело