Нарізання стеку розвитку - по діагоналі?

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

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

Проте нещодавно я дізнався, що команда A хоче відповідати за певні частини стеку, і вони пропонують розділити між двома командами, де рівень абстракції даних (і вміст вмісту в рівень даних) обробляється вони без розвитку команди B. Розділення виглядатиме щось подібне до цього:

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

Я маю занепокоєння щодо цього підходу щодо:

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

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

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

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

Це може бути хорошою ідеєю, якщо:

• Відомо, що Команда A буде працювати над проектами, які потребують нових можливостей у базі даних, тоді як мета команди B по суті полягає у виконанні функцій "лише фронтенд". Наприклад, якщо команда B пише нову програму iPhone для вашої компанії, швидше за все, вони деякий час не будуть додавати нові поля баз даних, оскільки їм потрібно перенести / повторно застосувати всі функції версії для настільних ПК.

• "Повна стека" стала досить складною, що жоден один розробник (чи команда розробників) не може ефективно "володіти" всією справою. Під "власним" я маю на увазі не просто додавати функції та виправляти помилки, але розуміти та дбати про всю систему до того, що вони можуть уникнути додавання їй більше технічного боргу з часом. У цьому випадку «діагональний» розкол є розумним кроком, якщо команда A володіє інтерфейсом інтерфейсу / веб-API, який є надзвичайно простим або неминуче щільно поєднаним з реалізацією DAL / бази даних (можливо, деякі внутрішні засоби діагностики?), А команда B робить всі складні матеріали, що стоять перед обличчям.

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

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

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