Mengiris Tumpukan Pengembangan - secara diagonal?

Kami memiliki proyek baru yang sedang berlangsung, dan saat ini pengembang telah dibagi menjadi dua tim, tim A dan tim B. Proyek ini memiliki 2 bagian yang memerlukan pengembangan di seluruh tumpukan pengembangan. Sampel stack kami yang sangat sederhana ditunjukkan di bawah ini:

Setiap bagian dari proyek ini membutuhkan pengembangan di seluruh tumpukan, jadi saya biasanya mengharapkan pendekatan pengembang tumpukan penuh yang merupakan cara kami telah memecah pekerjaan kami dalam tim B, merancang dan bekerja interaksi antara bagian-bagian yang berbeda.

Saya baru-baru ini belajar, bahwa tim A ingin bertanggung jawab atas bagian-bagian tertentu dari tumpukan, dan mereka mengusulkan pembagian antara kedua tim, di mana Lapisan Abstraksi Data (dan menempatkan konten dalam lapisan Data) ditangani oleh sendiri tanpa pengembangan dari Tim B. Kesenjangan akan terlihat seperti ini:

Bagi saya ini terasa sangat tidak wajar. Setiap tim memiliki tujuan dan rentang waktu yang berbeda untuk mencapai ini, tetapi Tim B akan memiliki ketergantungan pada Tim A untuk mengimplementasikan fitur. Solusi yang diusulkan adalah bahwa antarmuka umum didefinisikan di muka (mungkin ada skala waktu 2 tahun pada proyek sehingga mereka bisa banyak). Tim A kemudian akan mengembangkan bit yang diperlukan untuk antarmuka ini sejak awal meskipun memiliki serangkaian tujuan mereka sendiri, sementara Tim B mematikan semua panggilan untuk jangka pendek langsung sehingga mereka dapat berkembang.

Saya memiliki keprihatinan tentang pendekatan ini mengenai:

• Antarmuka dapat berubah dan Tim A mungkin tidak memiliki bandwidth atau waktu untuk mengakomodasi perubahan kebutuhan.
• Bug dalam kode Tim A dapat mencegah Tim B berkembang, dan sekali lagi mereka mungkin bukan prioritas untuk memperbaikinya karena Tim A memiliki antrian prioritas yang berbeda.
• Kurangnya pengetahuan tersebar di seluruh tim - Tim B mungkin tidak sepenuhnya memahami apa yang terjadi di bawah tenda dan mungkin membuat keputusan desain yang buruk karena hal ini.

Telah disarankan bahwa banyak perusahaan dalam industri ini memiliki sub-tim dan harus mampu mengatasinya. Dari pemahaman saya, umumnya tim terpecah seperti yang saya harapkan (Full Stack) atau dengan memecah tumpukan teknologi seperti di bawah ini:

Jadi saya tertarik mengetahui apa yang dilakukan industri lainnya. Apakah sebagian terbagi vertikal / horizontal? Apakah perpecahan diagonal masuk akal? Jika perpecahan diagonal terjadi, apakah kekhawatiran saya tampaknya valid dan apakah ada hal lain yang harus diperhatikan oleh Tim B? Untuk diketahui, saya mungkin akan dianggap bertanggung jawab atas keberhasilan atau kegagalan Tim B.

Kekhawatiran Anda sangat valid. Terutama dua poin pertama tentang Tim A yang tidak punya waktu untuk menambahkan fitur atau memperbaiki bug yang berdampak pada Tim B. Saya telah melihat ini terjadi pada pekerjaan saya sendiri beberapa kali.

Ini mungkin ide yang baik jika:

• Diketahui bahwa Tim A akan mengerjakan proyek-proyek yang memerlukan fitur-fitur baru dalam basis data, sementara tujuan Tim B pada dasarnya adalah untuk melakukan fitur-fitur "hanya frontend". Misalnya, jika Tim B sedang menulis aplikasi iPhone baru perusahaan Anda, kemungkinan mereka tidak akan menambahkan bidang basis data baru untuk sementara waktu, karena mereka perlu mem-port / mengimplementasikan semua fitur versi desktop.

• "Tumpukan penuh" telah menjadi cukup kompleks sehingga tidak ada satu dev (atau tim dev) yang secara efektif dapat "memiliki" semuanya. Maksud saya "sendiri" maksud saya bukan hanya menambahkan fitur dan memperbaiki bug, tetapi memahami dan peduli dengan keseluruhan sistem sampai-sampai mereka dapat menghindari menambahkan lebih banyak hutang teknis untuk itu seiring waktu. Dalam hal ini, pemisahan "diagonal" adalah langkah yang masuk akal jika Tim A memiliki UI / API Web yang sangat sederhana atau tidak dapat dihindari erat-erat dengan implementasi DAL / database (mungkin beberapa alat diagnostik internal?), Sementara Tim B tidak semua hal-hal frontend yang menghadap pengguna rumit.

• Manajemen memahami risiko Tim A menjadi hambatan, dan akan bersedia untuk mendeaginalkan hal-hal jika atau ketika risiko ini berubah menjadi masalah nyata.

Saya tidak dapat berbicara dengan apa yang lebih atau kurang umum di industri, tetapi setidaknya di tempat saya bekerja, ada kebutuhan yang jelas bagi semua pengembang aplikasi untuk menjadi "tumpukan penuh". Apa yang kami miliki adalah tim "infrastruktur" yang mengembangkan / memelihara basis data in-house kami, kerangka kerja layanan web kami dan kerangka kerja UI kami (apakah saya menyebutkan perusahaan saya sangat besar?), Sehingga semua dari ratusan aplikasi kami dapat memiliki tumpukan penuh devs sementara perusahaan secara keseluruhan masih dapat memberikan kinerja dan UI yang konsisten untuk semua layanan kami.

Baru-baru ini perusahaan kami telah membuat kerangka UI baru, jadi ada periode ketika beberapa aplikasi baru kami diblokir dengan sangat buruk pada bug dan fitur yang hilang dalam kerangka baru. Ini bukan lagi masalahnya, sebagian besar karena sebagian dari kita diberi izin untuk mengajukan permintaan tarikan kepada tim yang memiliki kerangka kerja (tidak cukup "de-diagonisasi", tetapi Anda mendapatkan idenya).