Який найкращий спосіб розширити масштаб і розділити спритну команду для створення веб-програми?

Нещодавно я приєднався до компанії, де я працюю майстром scrum над гнучким проектом розвитку, створюючи веб-додаток.

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

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

Хтось має досвід роботи з чимось подібним?

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

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

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

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

Ура!

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

Кожна з нових команд повинна мати керівника / технічного керівника, який має ґрунтовні знання про сферу своєї команди та який також знайомий з роботою інших команд.

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

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

Ключовим аспектом Scrum є самоорганізація .

Я пропоную вам обговорити питання з командою, і дозволити їм вирішити.

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

Додам: загалом крос-функціональні команди - це шлях.

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

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

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

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

2. Чи існує стабільний і однозначний інтерфейс програмування між переднім і заднім числом?

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

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

   • Це не означає, що API слід встановлювати в камені. Це лише пом’якшення наслідку для розбиття команди на дві частини.

3. Чому стільки спритних статей рекомендують мати вертикальні зрізи? Ось довідкова інформація:

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

   • Також не забувайте, що частина спритних статей мала неявну упередженість щодо стартап-компаній.

   • І не забувайте про сувору реальність маркетингу - більшість клієнтів платять лише за передні місця.

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

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

4. Практики, які можуть пом'якшити погані наслідки від розбиття команди

   • Стійкі спинки
   • Стабільний API
   • Низький коефіцієнт дефекту
     • Причина: щоб уникнути розладу
     • Як: одиничне тестування
     • Не означає: продуктивність чи оптимізація; це просто потрібно бути функціонально правильним.
   • Постійна інтеграція
   • Прозорість у спілкуванні, прогресі та прийнятті рішень
   • Заохочуйте неофіційні дискусії між двома командами
   • Заохочуйте членів команди (тих, хто не виходить назовні) відвідувати засідання іншої команди.
   • Створюйте випадкові спільні зустрічі та спільні ретроспективи
   • Інша діяльність з побудови команд

Як і інші, я б точно запропонував перейти з вертикальними скибочками. Іноді їх називають "Команди функціональних можливостей". Я рекомендую ознайомитися з плюсами / мінусами на веб-сайті Scaled Agile Framework: http://scaledagileframework.com/scaled-agile-framework/team/features-components/

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

1. Agile Team 1: SM, PO, крос-функціональна команда. Має власні відсталі команди для своїх історій.
2. Agile Team 2: SM, PO, крос-функціональна команда. Має власні відсталі команди для своїх історій.
3. Команда з управління програмами: Менеджер продуктів, Менеджери випусків, Enterprise Architects Має власні відсталі програми вищих епічних рівнів та функції, які будуть організовані, проаналізовані та подані в команди.

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