Dalam Lingkungan Agile, yang bertanggung jawab untuk arsitektur perangkat lunak

Dalam tim tangkas, siapa yang bertanggung jawab untuk membuat arsitektur tingkat tinggi dan keputusan desain yang memengaruhi seluruh sistem, bukan hanya pekerjaan yang sedang dilakukan dalam sprint saat ini?

Mungkin pemilik produk, ahli scrum, tim scrum, atau orang lain?

"Arsitektur perangkat lunak dilakukan oleh seluruh tim. Praktek ini tidak menghilangkan kebutuhan akan arsitek perangkat lunak, itu hanya berarti bahwa arsitek berkontribusi pada diskusi dengan perspektif yang lebih luas dan mungkin lebih berpengalaman, namun semua anggota tim berkontribusi terhadap arsitektur perangkat lunak. "

• Sumber: http://www.executivebrief.com/blogs/software-architecture-agile-environment-sashimi-approach/

Arsitek, tentu saja, tetapi mungkin bukan jenis arsitek tradisional.

Maksud saya bukan arsitek ahli bedah kepala yang melakukan semua pemikiran dan kemudian meninggalkan monyet untuk melakukan semua pengetikan. Maksud saya seorang programmer yang berpengalaman yang memahami biaya / manfaat dari keputusan sulit untuk dibalik dan yang menyarankan tim tentang apa yang harus dilakukan.

Arsitek yang efektif sulit ditemukan, tetapi ini bisa menjadi posisi yang fantastis, sehingga Anda mungkin memiliki setidaknya satu programmer berpengalaman yang dapat melakukannya dengan baik. Orang seperti itu perlu

• Buat keputusan arsitektur yang bagus, tentu saja, tetapi juga
• Ketahui cara memberi saran secara efektif, sehingga orang lain merasa nyaman menerimanya, dan juga
• Secara perlahan mendelegasikan keputusan arsitektur kepada tim

Poin terakhir ini membuat banyak orang naik. Ketika agonis yang bermaksud baik mengatakan hal-hal seperti "Tim memiliki arsitektur", mereka memiliki "benar", tetapi saya menemukan saran yang hampir sepenuhnya tidak berarti dalam penerapannya. Jika Anda mempercayai tim untuk bertanggung jawab atas arsitektur mereka sendiri, maka Anda tidak akan mengajukan pertanyaan di tempat pertama, sekarang kan ?! Karena itu saya berasumsi bahwa Anda mengajukan pertanyaan karena ada beberapa kekhawatiran

• Tidak ada yang akan bertanggung jawab dan kami akan memiliki arsitektur yang buruk, atau
• Orang yang salah akan bertanggung jawab dan kami akan memiliki arsitektur yang buruk, atau
• Siapa pun yang bertanggung jawab akan menjadi kambing hitam dan Anda berharap untuk menghindarinya

Jika Anda membutuhkan seseorang untuk bertanggung jawab, berikan kepada siapa pun yang ingin menerimanya. Serius. Orang itu setidaknya peduli. Berikan orang itu sumber daya yang mereka butuhkan untuk melakukan pekerjaan itu dan bantu mereka ketika mereka membutuhkannya. Mungkin tidak masalah seberapa kompeten orang tersebut, karena jika mereka peduli, maka mereka akan mencoba mempelajari apa yang mereka perlu pelajari. Secara alami, orang seperti itu membutuhkan dukungan dalam bentuk buku-buku bagus untuk dibaca dan komunitas rekan-rekan dan mentor yang dapat mereka minta bantuan dan nasihat.

Jika Anda khawatir orang yang salah bertanggung jawab, maka saya harap Anda tahu siapa "orang yang tepat", dan akan berjuang untuk menginstalnya sebagai arsitek. Buku seperti The New Strategic Selling akan membantu Anda mempelajari teknik penjualan untuk mewujudkannya.

Jika Anda hanya perlu kambing hitam, maka diam-diam mendorong orang lain untuk memberikan tanggung jawab kepada karier siapa pun yang paling Anda inginkan untuk menghancurkan atau merusaknya. Setidaknya jujur ​​tentang hal itu.

Kembali ke pekerjaan arsitek yang efektif, mereka dapat menganggap pekerjaan mereka sebagai posisi manajemen, bukan hanya posisi pengambilan keputusan. Jika mereka tidak mendelegasikan setidaknya keputusan paling rutin ke tim, maka mereka akan menjadi hambatan dan memperlambat seluruh organisasi . Menambahkan lebih banyak arsitek di atas tidak menjadikannya lebih cepat. Menumbuhkan keputusan arsitektur yang lebih baik dari bawah ke atas. The Dewan Delegasi Teknik akan membantu arsitek Anda menjadi lebih nyaman dari waktu ke waktu mendelegasikan keputusan yang lebih dan lebih untuk tim sebagai tim-tim mendapatkan kepercayaan dengan menunjukkan kompetensi.

Saya menganggap seorang arsitek hebat sebagai seseorang yang membantu saya memahami bagaimana merancang sistem saya dengan lebih baik, yang akan menasihati saya dengan sabar ketika saya memintanya, dan yang sesekali akan menghentikan saya untuk membuat keputusan yang sangat buruk. Arsitek seperti itu bertindak seperti seorang pemimpin dalam arti yang sesungguhnya: seseorang yang diikuti oleh orang lain secara sukarela .

Saya tahu itu banyak.

Referensi

Miller, Penjualan Strategis Baru . Buku ini mencakup model untuk memahami mengapa Anda gagal menutup penjualan tertentu. Saya menemukan ini sangat berharga dalam memahami mengapa rekan kerja tidak akan melakukan hal yang jelas luar biasa yang saya sarankan.

Weinberg, Menjadi Pemimpin Teknis . Buku ini membantu saya belajar bagaimana melakukan bagian non-arsitek dari pekerjaan arsitek yang efektif.

Appelo, Delegation Boards, dan Delegation Poker . Jangan meremehkan betapa sulitnya mendelegasikan dan seberapa banyak kita menghisapnya. Belajar melakukannya dengan lebih efektif dan lebih nyaman.

Yang terbaik arsitektur , persyaratan, dan desain muncul dari tim yang mengatur dirinya sendiri

- Manifesto Agile

Jadi tim mengatur diri sendiri untuk membuat keputusan arsitektur dengan cara apa pun yang dianggap sesuai. Tidak ada aturan yang keras dan cepat, dapat berkisar dari konsensus hingga "dewan" anggota paling senior, hingga menunjuk satu anggota tertentu sebagai otoritas arsitektur, hingga membiarkan arsitek memilih jika ada anggota dengan jabatan seperti itu .. .

Saya merasa bahwa jawaban untuk "" siapa yang bertanggung jawab untuk membuat arsitektur tingkat tinggi dan keputusan desain? "Tergantung pada ukuran dan jumlah tim.

Untuk satu atau dua tim dengan 3-7 anggota di setiap tim, maka tim yang dapat mengatur diri sendiri dapat melakukannya dengan pemimpin dari anggota senior.

Untuk 3 tim atau lebih, meningkatnya kompleksitas mengarah pada kebutuhan akan tim arsitektur yang dapat melihat apakah berbagai sub-tim melakukan pekerjaan yang akan berinteraksi dengan tim lain. Dalam pengalaman saya titik itu tercapai ketika ada sekitar 8 tim atau sekitar 50 orang.

Ada beberapa sumber daya hebat dari tim Scaled Agile Framework (SAFe) di situs mereka.

Ini pada dasarnya membantu Anda meningkatkan kelincahan di seluruh organisasi Anda, melampaui rilis tunggal dan ke dalam perencanaan portofolio dan program. Dokumentasi mereka menunjukkan saran tentang bagaimana melibatkan Enterprise dan System Architects Anda dalam proses untuk memperkenalkan epos arsitektur ke dalam kereta rilis.

Edit untuk kejelasan untuk menjawab pertanyaan lebih langsung:

Dalam lingkungan lincah skala ada beberapa tingkatan kepemilikan atas arsitektur. Tim implementasi tangkas akan memiliki arsitektur tingkat rendah yang muncul dengan refactoring yang diperlukan untuk melanjutkan implementasi backlog mereka. Keputusan arsitektur tingkat tinggi (sistem operasi yang didukung, browser, platform, perpustakaan) berada di bawah tanggung jawab sistem Anda dan arsitek perusahaan. Mereka akan membuat kasus bisnis ketika perubahan ini perlu terjadi dan akan merekomendasikan agar perubahan arsitektur ini ditambahkan ke rilis kereta untuk tim implementasi.

Jadi, sehubungan dengan keputusan arsitektur tingkat tinggi yang melampaui sprint, Anda biasanya akan membuat ini pada tingkat di atas tim. Para profesional ini secara tradisional sudah memiliki peran 'arsitek' dalam perusahaan.

Saya pikir sebagian besar jawaban lain memikirkan hal ini dari sudut pandang berada di dalam proyek.

Jika itu adalah satu-satunya tingkat arsitektur dalam suatu organisasi, hasilnya akan benar-benar kacau. Saya telah menyaksikan kekacauan ini secara langsung, sayangnya itu terjadi.

Menurut TOGAF, Departemen Arsitektur Perusahaan membuat rencana tingkat tinggi untuk dan dengan bisnis untuk membuat dan mengganti lingkungan TI. Arsitek Perusahaan akan menetapkan prinsip-prinsip arsitektur dan membuatnya ditandatangani di tingkat tertinggi organisasi dan akan membantu menciptakan arsitektur dan persyaratan tingkat tinggi untuk setiap proyek. Setiap proyek dimulai untuk menyediakan blok bangunan arsitektur dalam arsitektur tingkat tinggi itu.

Jadi, di tingkat proyek, Arsitek Solusi akan membuat arsitektur proyek (mungkin secara iteratif) dan akan mendapatkan sign-off dari Arsitek Perusahaan.

Sekarang, untuk fokus pada proyek gesit. Proyek lincah memiliki persyaratan. Mereka tidak dalam bentuk "Dokumen Persyaratan" yang besar, melainkan epik dan cerita. Epik ini masih membutuhkan perencanaan. Anda tidak mengirim tim pengembang dengan beberapa sprint ke tempat yang tidak dikenal. Anda tahu pada tingkat tinggi apa yang perlu dilakukan sistem, sistem apa yang perlu berinteraksi dengan perangkat keras / Sistem Operasi / Bahasa apa yang dimiliki organisasi dan ini memandu dan membatasi pilihan arsitektur yang terbuka untuk Arsitek Solusi. Misalnya, jika Anda berkomitmen untuk .NET dan SQL server, Anda harus membuatnya menjadi sangatkasus yang menarik untuk menerapkan situs e-commerce berbasis pada Magento menggunakan PHP dan MySQL karena biaya yang diperlukan untuk mendukung dua DB, dua bahasa, dua webservers dll. Atau, satu proyek dapat memilih untuk menggunakan perpustakaan yang sama sekali berbeda atau tampilan yang berbeda dan rasakan dan ini bisa berdampak pada semua proyek dalam penerbangan lainnya. Sangat penting untuk memiliki pengawasan Arsitek Perusahaan untuk mencegah terjadinya "Hutang Arsitektur" semacam ini.

Tergantung pada desain organisasi organisasi dan jika produk ada dalam portofolio. Organisasi yang lebih besar dan berorientasi peran dapat menunjuk arsitek senior untuk memimpin jenis kegiatan ini.

Umumnya seorang arsitek senior akan memfasilitasi dan memandu keputusan desain karena tidak hanya mempengaruhi tumpukan produk, mereka dapat mempengaruhi beberapa produk dalam portofolio produk.

Perusahaan yang lebih kecil dan gesit dapat mengandalkan pengembang yang ahli sistem untuk memimpin tim pengembangan untuk menyelaraskan pada desain arsitektur.

Pada akhirnya, keputusan arsitektur perlu disepakati oleh tim pengiriman yang mengerjakan produk. Arsitek yang berpengalaman dan pemimpin teknologi akan lebih fokus pada memfasilitasi diskusi tentang seperti apa desain seharusnya, daripada mendikte desain.

Saya pikir sebagian besar jawaban sudah menggarisbawahi bahwa tim tidak satu orang pun harus mengambil keputusan ini.

Apa yang tidak mereka sentuh adalah prinsip Agile yang lain:

Kesederhanaan - seni memaksimalkan jumlah pekerjaan yang tidak dilakukan - sangat penting.

Berpikir tentang arsitektur tingkat tinggi & keputusan desain sering tidak diambil dengan kesederhanaan dalam pikiran, mungkin menyebabkan membuang banyak usaha dan menambahkan kompleksitas yang tidak perlu yang dapat membuat hal-hal sulit untuk diperluas.

Pikirkan 'berkebun' di atas 'arsitektur' — Ciptakan budaya desain yang hidup dan berkembang

Selama iterasi Anda saat ini, Anda harus membuat keputusan arsitektur & desain untuk kebutuhan Anda saat ini. Alih-alih melihat ke depan ke masa depan yang mungkin tidak pernah menjadi, fokuslah hanya pada apa yang Anda butuhkan sekarang. Mungkin YAGNI arsitektur yang dipikirkan dengan baik sekarang, biarkan tim menanganinya sedikit demi sedikit.

Berbunyi lain:

• https://less.works/less/technical-excellence/architecture-design.html