TLDR; Ketika saya mengatakan bahwa saya bukan penggemar model Tim Fitur, beberapa orang mungkin berpikir itu adalah konsekuensi dari kurangnya delegasi, atau bahkan konservatisme organisasi. Ini bukan salah satu dari ini. Hal ini terutama demi efisiensi yang saya lebih suka regu (yaitu tim otonom khusus oleh topik bisnis / Bounded Contexts) TETAPI dikombinasikan dengan teknik Swarming bila diperlukan. Peringatan: posting ini juga berisi kata-kata kasar mini terhadap Inverse Conway Maneuver ;-)

Artikel ini mengikuti posting saya sebelumnya ( Is DDD right-wing? ) yang berbicara tentang Domain Driven Design dan berbagai masalah organisasi. Artikel yang saya sebutkan secara singkat bahwa saya bukan penggemar Tim Fitur. Saya akan menjelaskan di sini alasannya.

Dunia Tim Fitur yang hilang

Saya sudah mengalami iseng-iseng ketika semua orang bersumpah demi tim fitur. Itu di tahun 2010-an dan sebagian besar organisasi besar benar-benar berpikir itu akan menyelamatkan mereka dari masalah Budaya mereka (), dari hutang teknis mereka tetapi juga dari beban birokrasi mereka. Prinsipnya sederhana: kami membentuk tim yang berpusat pada pelanggan, multidisiplin tetapi stabil, yang akan secara teratur diberi misi berbeda. Misi berbeda tetapi setiap kali ada fungsi tertentu yang akan dikelola tim sendiri dari awal hingga akhir (pemotongan vertikal). Untuk mencapai hal ini, Tim Fitur akan dapat melakukan intervensi sendiri pada semua komponen yang akan menghalangi jalannya (depan, belakang, infra, db dll).

Gagasan tim fitur adalah tidak perlu memanggil tim lain untuk dapat menambahkan fitur atau kemampuan ke suatu produk.

Peringatan: pengertian "fitur" dalam tim Fitur tidak berarti bahwa ia bertanggung jawab atas Domain bisnis tertentu (yang akan menjadi spesialisasinya). Tidak, pengertian "fitur" lebih sesuai dengan unit kerja tim (yang dapat berubah secara berkala). Tim fitur agak mirip dengan A-Team: tim otonom yang memecahkan masalah yang muncul (di awal setiap episode) dan terus mengubah topik pembicaraan sebelum berangkat ke petualangan baru.

Namun masalah datang ketika…

Dalam organisasi seperti itu, kami berpotensi memiliki beberapa tim fitur yang bekerja secara bersamaan pada fitur yang berbeda, tetapi semuanya pada platform/perangkat lunak yang sama. Setelah melihat ini sana-sini dalam pengalaman lama atau dengan klien (ketika saya menjadi konsultan), hal ini dapat menimbulkan :

• Masalah konkurensi antar tim saat membuat kode pada komponen yang sama
• Basis kode heterogen diakhiri dengan banyak pendekatan desain yang berbeda. Oleh karena itu mengarah ke kode yang lebih rumit untuk dibaca/dipahami/dipelihara/dikembangkan (benturan budaya dev?)
• Desain sentris jangka pendek, dengan orang yang kurang memperhatikan daya tahan dan pemeliharaan kode yang dihasilkan. Seperti jika itu hampir intrinsik dengan pernyataan misi mereka.

Memang, berurusan dengan domain yang rumit mungkin sangat menyusahkan atau menyebabkan banyak kode domain anemia dengan Tim Fitur.

Jadi. Bagaimana kita bisa menghadapi semua kesulitan ini?

Model "pasukan" Spotify

Maka tidak mengherankan jika model yang muncul di tahun-tahun berikutnya adalah model "pasukan" Spotify. Yang ini dimulai dari konsep tim multidisiplin dan stabil (seperti tim Fitur), tetapi orang-orang Spotify melangkah lebih jauh ke aspek otonomi.

Mereka telah meminta masing-masing regu ini untuk berinvestasi lebih lama dan tetap ditugaskan ke area bisnis tertentu, aspek fungsional tertentu dari produk. Mereka memahami bahwa perlu berinvestasi seminimal mungkin secara fungsional, agar dapat sepenuhnya efektif, mandiri, dan mampu membuat keputusan yang relevan.

Dan jangan salah paham: “Squad” bukan sekedar istilah “keren” untuk membicarakan sebuah tim. Pasukan adalah tim OTONOM. Kami memberi mereka misi yang akan bertahan lama, dan kami akan meminta mereka untuk mengambil kepemilikan Domain bisnis mereka sendiri.

Domain tempat tim bekerja harus pas di kepala semua orang

Topologi Tim (oleh Matthew Skelton & Manuel Pais ) muncul beberapa tahun kemudian dengan istilah "Tim yang selaras aliran". Tapi sementara saya menemukan proposal mereka untuk mengurangi beban kognitif pada tim yang menarik, dengan menempatkan batas atas yang keras pada ukuran tim ("domain tempat tim bekerja harus pas di kepala semua orang"), saya tetap lebih suka menggunakan nama "Pasukan" untuk mewakili otonomi.

Catatan: mengerjakan otonomi untuk tim adalah salah satu hasrat saya seperti yang baru-baru ini saya diskusikan di sini dengan Bagaimana mencegah pencarian Anda untuk otonomi tim berubah menjadi kekacauan…

Squads & DDD: duo fantastis untuk menangani kompleksitas bisnis

Otonomi benar-benar merupakan landasan bersama antara model "Pasukan" dan Desain Berbasis Domain (DDD). Memang, yang terakhir menyarankan agar kami menyelaraskan perangkat lunak kami dengan kebutuhan Domain, dan membagi produk kami menjadi "alam" otonom yang berbeda tetapi terhubung yang disebut Konteks Terikat (mis. Akuntansi, Penjualan, Pencarian, dll.). Ranah/Konteks terbatas ini seharusnya memberi kami lebih banyak kebebasan dan otonomi untuk memberikan nilai (misalnya, kami tidak ingin memengaruhi dan meminta pendapat tim khusus Pemasaran saat kami mengubah bagian tentang Akuntansi). Untuk detail lebih lanjut tentang apa itu DDD, Anda dapat melihat ini ( Desain Berbasis Domain dijelaskan dalam 3 menit ).

Untuk mencapai tantangan ini, kami biasanya hanya ingin memiliki satu tim yang bertanggung jawab per Bounded Context (dan sangat sering dengan sesuatu seperti modul atau API web per BC) karena kami ingin setiap tim konsisten di dalam (dalam hal desain & umum mendekati).

Yang terpenting, kami menginginkan waktu yang tepat untuk memasarkan dan tim otonom dalam pengambilan keputusan mereka. Karenanya kami menyesuaikan arsitektur kami, mengikuti batas domain kami. Memiliki beberapa tim pemilik dari Bounded Context yang sama akan mempersulit setiap pengambilan keputusan. Desain Berbasis Domain BTW memberi nama pada situasi di mana beberapa tim akan berbagi sepotong kode: Shared Kernel .

Bahkan jika semuanya adalah masalah konteks, saya dapat mengatakan tanpa terlalu tersipu bahwa kernel yang dibagikan seringkali merupakan situasi yang menyakitkan (bau?) Secara organisasi. Setidaknya itu membutuhkan kedewasaan tertentu dan budaya perusahaan yang menghargai kolaborasi dalam perusahaan (yang tidak akan Anda miliki jika Anda menghargai orang dan memberikan bonus secara individu, misalnya) yang sangat jarang. Bukan tidak mungkin tapi jarang.

Singkatnya: kami umumnya ingin menghindari situasi dengan tim berbeda yang menangani bagian bisnis yang sama dari Produk kami.

Penggunaan tim Fitur pada intinya tampaknya tidak memadai terkait IMO tujuan ini.

Di Agica

Tidak mengherankan, kurang lebih inilah yang saya temukan di Agicap ketika saya tiba tahun lalu untuk menjadi Wakil Presiden Teknik peningkatan skala Eropa yang sedang booming ini.

Tetapi tidak seperti situasi Spotify di mana setiap Skuad (memahami "seluruh tim") benar-benar mandiri dalam pengambilan keputusan, Manajer Produk Agicap adalah orang yang sangat mendorong fase implementasi pengembangan.

Itu telah bekerja dengan cukup baik sejauh ini. Terutama fakta tidak memiliki Pemilik Produk (PO) melainkan Manajer Produk, yang mencakup fase penemuan dan pengiriman (sangat efisien).

Meskipun demikian, tim teknologi secara teratur mendapat permintaan dari orang-orang Produk untuk mengubah struktur tim mereka. Hal-hal seperti meminta kami untuk memindahkan dev tertentu dari satu tim ke tim lain agar lebih sesuai dengan kebutuhan/kesibukan fungsional mereka saat ini atau yang akan datang. Mengikuti permintaan seperti itu akan mengarahkan kami untuk membuat keputusan dampak jangka panjang bagi orang-orang tetapi berdasarkan topik jangka pendek dari produk (untuk minggu atau bulan mendatang).

Perspektif apa pun yang Anda ambil tentang ini, bagi saya sepertinya itu bukan ide yang bagus.

Kami bukan "sumber daya" demi keparat!

Keinginan saya untuk membina tim otonom berakar kembali ke pertengahan tahun 2000-an, ketika saya menemukan XP (eXtreme Programming) sedang bekerja. Saya dapat merasakan kekuatan dan efisiensi lokal dari tim XP otonom pada proyek percontohan di bank investasi besar. Pengalaman yang luar biasa di banyak level. Beberapa tahun kemudian, saya juga mengalami frustrasi bekerja di organisasi besar yang tidak memahami dinamika tim pengembang dan Dynamic Reteaming . Sebuah organisasi yang menghabiskan waktunya memecah tim kami berulang kali sesuai dengan proyek yang sedang populer.

Seperti yang saya katakan di artikel saya sebelumnya, dibutuhkan setidaknya 6 bulan untuk membangun tim pengembang yang efisien di mana hubungan antarpribadi efektif dan beberapa keahlian bisnis diperoleh.

Menghabiskan waktu untuk merombak casting tim pengembang sangat memengaruhi efisiensi kami. Juga: kami bukan mesin! Kita adalah manusia dengan pengaruh, ikatan, dan keterikatan yang kita jalin dari waktu ke waktu dengan rekan kerja kita.

(

Tanda kurung kecil: Inverse Conway Maneuver (ICM)

Ini adalah alasan yang sama mengapa sebagian dari kita mengeluh ketika mendengar tentang Inverse Conway Maneuver (ICM) . Dan saya tidak berbicara tentang versi asli ICM yang baik-baik saja (yaitu: "mendobrak silo yang membatasi kemampuan tim untuk berkolaborasi secara efektif" ). Saya sedang berbicara tentang bagaimana generasi konsultan telah mengubah ICM menjadi monster frankenstein (yaitu: " ubah organisasi Anda untuk mencapai arsitektur target Anda" ).

Pada topik khusus itu, nantikan seri artikel hebat yang akan datang dari teman saya Cyrille DUPUYDAUBY (seharusnya diterbitkan segera). Dia adalah orang pertama yang mengingatkan saya tentang hal ini bertahun-tahun yang lalu dan akan mengklarifikasi alasannya.

Beberapa orang seperti John CUTLER atau Mathias VERRAES ( Hukum Conway Tidak Berlaku untuk Desain Kaku ), telah memahami bahwa konsep seperti manuver Conway terbalik mungkin terlalu ambisius mengingat hutang fungsional dan teknis dari arsitektur tertentu:

« Terakhir, mudah untuk mengatakan "berdayakan saja tim Anda!" Bahkan dengan niat terbaik, itu mungkin tidak mudah. Arsitektur dan struktur organisasi Anda saat ini mungkin membatasi pilihan Anda. » ( John CUTLER — TBM 27/52: Tingkat Mandat )

Beberapa dari kita juga mengatakan bahwa manuver ini tidak etis dan sangat naif. Alasan mengapa saya berbicara tentang penipuan untuk ICM.

Pertama tidak etis, karena kami tidak bermain seperti itu dengan orang, manusia nyata di organisasi kami. Anda tidak "memfaktorkan ulang" orang. Anda tidak bermain dengan orang saat Anda bermain dengan kode.

Ini juga sangat naif, karena wajah tersembunyi dari Gunung Es yang akan Anda hadapi sekali lagi adalah Budaya. Hal yang familiar bagi para peminat manajemen perubahan seperti saya. Ingat? Orang yang makan semua strategi saat sarapan (lih. Peter Drucker).

)

Tanda kurung di sisi manusia ini selesai, mari kita kembali ke subjek utama kita: apa yang dapat dibawa oleh Swarming ke tim yang stabil dan otonom (yaitu Pasukan).

Berkerumun: sedikit tambahan yang kami butuhkan untuk organisasi DDD yang efisien

Baik. Pertama: mari kita jelaskan apa itu Swarming. Swarming seperti Gugus Tugas (karenanya sementara), tetapi di dalamnya kami akan menentukan sejak awal siapa yang akan bertanggung jawab atas dukungan produksi perangkat lunak yang dihasilkan (poin yang bahkan lebih penting jika, seperti kami, Anda berada di " Anda membangun itu, Anda menjalankannya!” mode). Ini menyoroti banyak keputusan desain kolektif, dan menghindari situasi terkenal saat mengakhiri gugus tugas: "BTW: siapa yang mengurus dukungan untuk hal yang baru saja kita lakukan bersama?!?" (keheningan panjang ;-) Adapun gugus tugas, anggota Swarming berasal dari beberapa tim yang berbeda dan harus bekerja sama untuk memecahkan masalah jangka pendek (sebelum kembali ke pasukan mereka di penghujung hari)

Di luar keefektifannya dalam mendapatkan orang yang tepat untuk berkolaborasi tergantung pada subjeknya, inisiatif Swarming membawa banyak modal sosial ke organisasi dengan mempromosikan sementara hubungan interpersonal antara regu yang berbeda (sangat berguna untuk masa depan ketika semua orang kembali ke regu mereka).

Mengapa kita perlu Berkerumun?

Jika kita mendorong terlalu jauh dan salah memahami konsep otonomi yang direkomendasikan oleh DDD, kita mungkin tergoda untuk mengacaukan otonomi dengan isolasi. Kita juga mungkin tergoda untuk mengasingkan diri terlalu banyak… Untuk melihat setiap konektivitas dan setiap interaksi antara BC sebagai kejahatan mutlak yang harus dihindari.

Saya telah melihat banyak orang jatuh ke dalam perangkap berhenti memikirkan orang lain dan hanya berfokus pada Konteks Batas mereka sendiri, pada tim mereka sendiri. Sangat mudah untuk melupakan bahwa kita adalah bagian dari ekosistem di mana setiap bagian memiliki peran untuk dimainkan dan di mana interaksi harus dibatasi -tentu- (dalam hal permukaan paparan) tetapi tidak diabaikan. Karya kita harus bermanfaat dan dimanfaatkan. Setiap orang (PM, pengembang) memimpikan situasi di mana kita tidak pernah membutuhkan tim/BC lain untuk maju dan memberikan nilai. Tapi semua orang bermimpi…

Bagaimanapun. Tak satu pun dari ini cocok dengan apa yang dikatakan DDD kepada kita. Sebaliknya, DDD ingin setiap Bounded Context menjadi yang paling otonom tentunya, namun tetap berguna untuk kebutuhan pengguna kami. Untuk mencapai ini, kita perlu menghubungkan BC yang berbeda dengan bijak, tidak sepenuhnya menyembunyikannya satu sama lain. Dan untuk itulah sebagian besar pola strategis DDD adalah: untuk membantu kami mengizinkan interaksi antar BC ini dengan aman.

Nah, Swarming mengintervensi dengan tepat dalam beberapa kasus ini di mana kita perlu bekerja pada sinkronisasi & interaksi antara 2 atau lebih Bounded Contexts.

Berkerumun juga dapat membantu kita bertahan dalam situasi di mana BC kita belum terdefinisi dengan baik. Sebelum Domain atau klarifikasi Peta Konteks.

Saat Pengerumunan selesai, semua orang menemukan tim dan subjeknya. Swarming hanyalah cara yang sangat efisien untuk berkolaborasi dengan orang-orang dari berbagai tim dan keahlian Domain untuk mencapai tujuan dengan cara yang efisien.

Inilah mengapa saya ingin teknik ini dicoba ketika saya tiba setahun yang lalu. Dan harus saya akui bahwa saya tidak pernah bosan melihat efek menguntungkannya (sekarang sudah beberapa bulan sejak kami mengalaminya di sini atau di sana).

Untuk menyimpulkan: FTW yang penuh!

Seperti yang disebutkan di awal artikel ini, saya telah melihat begitu banyak situasi rumit tetapi terutama basis kode yang tidak konsisten setelah disentuh oleh beberapa tim fitur sehingga menurut saya Tim Fitur tidak lagi menarik.

Terburuk, saya telah melihat berkali-kali Tim Fitur tidak terlalu berpengetahuan atau tertarik dengan seluk-beluk atau bahasa yang ada di mana-mana dari setiap bagian fungsional/BC. Setiap kali, dampak pada basis kode sangat dramatis (Domain anemia atau perkiraan).

Alasan mengapa menurut saya tim Fitur tidak dapat bersaing dengan Skuad kombo dengan Swarming kapan pun kita perlu memaksakan topik atau kolaborasi tertentu.

Langkah selanjutnya

Hari ini di Agicap, orang-orang teknologi sangat dekat dengan Manajer Produk mereka. Namun langkah selanjutnya dari perjalanan peningkatan berkelanjutan kami adalah agar Manajer Produk melibatkan orang-orang teknologi yang lebih cepat selama penemuan mereka ("pergeseran ke kiri" yang terkenal untuk teknologi).

Saya juga ingin kita mulai mempertimbangkan jalur ganda Penemuan Berkelanjutan / Pengiriman Berkelanjutan yang sangat disukai Marty Cagan & Jeff Patton. Hal ini seharusnya memungkinkan kami untuk lebih menempatkan energi & kekuatan teknik kami HANYA pada ide-ide yang telah divalidasi oleh klien kami. Untuk lebih meningkatkan rasio biaya/manfaat dari tindakan kami.

« Maksimalkan nilai, minimalkan upaya » (Jeff Patton)

Tapi itu akan menjadi subjek posting masa depan saya kira.

Untuk mengetahui lebih lanjut tentang Agicap:

• Tunjukkan Domain Anda ( Sesi peta konteks pemantauan Arus Kas & perkiraan )
• https://agicap.com/
• https://career.agicap.com/