Скраб для команд спеціалістів

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

Припустимо, у вас є команда з 5 розробників (не реальна, лише для прикладу):

1. Один математик з сильними навичками C;
2. Один розробник БД;
3. Один веб-розробник;
4. Один розробник UX / GUI;
5. Один архітектор програмного забезпечення;

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

1. Марні весняні плани: дійсно, коли математик каже, що конкретне завдання вартує 2 бали, ніхто не може проголосувати проти нього;
2. Марний показник швидкості команди: оскільки кожен може виділити будь-яку кількість балів власним завданням, швидкість обчислення не має сенсу;
3. Замініть щоденні зустрічі з вигуками на щотижневі (триваліші) зустрічі з вигуками: оскільки кожен член команди працює над власними завданнями, щоденні зустрічі з виступленнями повинні бути дуже важливими для збереження "командного духу". Однак, щоденні зустрічі з обговореннями повинні тривати близько 15 хвилин. Цього явно недостатньо, щоб зрозуміти, що роблять і будуть робити інші. Більше того, математик більшість часу відповість на ті самі речі: "Я все ще займаюся % & Lo (+? $$ + &)" ... Щотижневі зустрічі дадуть більше часу. Щоб тримати однаковий час зустрічей між "початковими" зустрічами scrum і "щотижневими" scrum зустрічами, кожна тижнева зустріч scrum повинна тривати (5 днів на тиждень, 4 спритні спринцювання, зі спринтськими зустрічами тривалістю 4 години та щоденними зустрічами тривалістю 15 хвилин): (4 * 60 + 20 * 15) / 4 =>

Або scrum все ще корисний? Може бути, слід використовувати іншу спритну техніку?

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

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

• Візуалізуйте потік вартості, тобто дошку Kanban. Дошка Scrum - це специфічне застосування дошки Kanban; Можна адаптувати його, щоб дозволити спеціалізацію.
• Обмежте роботу в процесі роботи (WIP), щоб кількість роботи, призначеної для команди, була достатньою для того, щоб робота постійно протікала - тобто не було «блокування» ні початку потоку (проектування), ні кінця (розгортання) .

Ви можете перевірити кілька посилань про Kanban:

• Один день у канбанській землі
• Грунтовка Kanban (безкоштовна електронна книга)

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

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

Щоденна зустріч все ще дає переваги. Між членами команди існують залежності, навіть якщо вони кожен спеціаліст. Хлопець інтерфейсу може чекати на сервері, щоб виправити помилку сповіщення. Хлопець сервера, можливо, чекає на хлопця з математики, щоб з'ясувати, чому підрахунок неправильний. Йдеться не лише про те, як їх робота впливає на вас. Якщо член команди постійно затримується через "Причину X", але вони не встигли пом'якшити майбутні події "Причини X", це може бути оскаржено.

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

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

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

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

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

Я хотів би також торкнутися деяких конкретних тем, які ви піднімаєте:

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

Розміри Важливо пам’ятати, що ми визначаємо розмір бізнес-проблеми або потреби, а не рішення чи частина рішення. Наприклад, інтеграція соціальних медіа / Twitter у наш веб-сайт електронної комерції - це проблема, яка потребує UX, UI-дизайну, програмування, бази даних та знань API Twitter. Команда повинна розміщувати це як одиницю, оскільки вони, як команда, збираються забезпечувати цю функціональність. Цей розмір не буде 100% точним, але ми виявляємо, що в сукупності прогнози, засновані на відносному розмірі, є більш точними. Це означає, що деякі будуть високими, деякі - низькими, і разом взято розрахунковий прогноз є більш точним, ніж передбачувана тривалість.

Марне планування весни Спринт-планування - це час співпрацювати як команда Scrum (Команда розробників + Власник продукту + Майстер Scrum), щоб визначити, що слід створити, і придумати план, як почати. Деякі команди розбивають ці елементи запущених продуктів, вибрані на завдання, в той час як інші придумують свій власний шлях до прогресу, як тести, які необхідно пройти (думаю, XP).

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

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

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

Замініть щоденні зустрічі з scrum на щотижневі (більш тривалі) зустрічі Scrum Щоденний Scrum є для того, щоб забезпечити команду 24-годинним циклом зворотного зв'язку та можливістю планувати наступні 24 години. Нічого більше, нічого менше. "Три запитання" призначені для полегшення цих зусиль.

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

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