Dalam Lingkungan Agile, yang bertanggung jawab untuk arsitektur perangkat lunak


19

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?

masukkan deskripsi gambar di sini


10
Ini ... tidak masuk akal ...
Telastyn

3
Kehadiran backlog Produk dan Sprint tidak memengaruhi siapa yang bertanggung jawab atas arsitektur perangkat lunak. Pertanyaan yang lebih baik mungkin: Dalam Lingkungan Agile, siapa yang bertanggung jawab untuk arsitektur perangkat lunak?
ChargerIIC

Saya sudah mencoba memperbarui pertanyaan sehingga setidaknya bisa dimengerti. Tidak 100% yakin jika saya melakukannya dengan benar ...
FrustratedWithFormsDesigner

Jawaban:


24

"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. "


5
Pure Agile cenderung menolak peran tradisional dari atas ke bawah seperti "manajer proyek" dan "arsitek sistem," alih-alih lebih suka memperbaiki peran itu dan mendistribusikan tanggung jawab tradisional mereka ke seluruh tim.
Jonathan Eunice

6
@ JonathanEunice: Bagaimana ini bisa dilakukan secara praktis? Tidak semua pengembang juga arsitek yang baik.
Giorgio

2
@ JonathanEunice: Jadi pertanyaan yang diajukan DWD memang masuk akal. Saya tidak mengerti semua downvotes.
Giorgio

3
@DaveHillier: Mungkin proyek-proyek ini besar tetapi arsitekturnya cukup sederhana: pengembang hanya perlu mengisi bagian-bagian dalam skema berulang yang agak sederhana (misalnya menulis ratusan formulir serupa dalam aplikasi berbasis web dengan model domain yang ada) . Di sisi lain, saya tahu bahwa segera setelah aplikasi menjadi cukup kompleks, Anda memerlukan seseorang untuk mengurus arsitektur (sering kali dimuka) jika tidak, Anda akan berakhir dengan kekacauan besar.
Giorgio

6
"Desain Besar di Muka" adalah argumen gesit tipikal untuk menarik kesimpulan bahwa seharusnya tidak ada desain di muka sama sekali: pendekatan diambil ke ekstrem, ekstrem terbukti salah, dan ekstrem yang berlawanan diusulkan sebagai solusi. Saya setuju bahwa desain besar di muka jarang merupakan pendekatan yang baik, tetapi beberapa keputusan arsitektur mendasar harus diambil di muka untuk menghindari refactoring besar atau penulisan ulang lengkap nanti. Ini bukan kegiatan yang bisa diimprovisasi "ketika seseorang merasa kodenya menjadi terlalu berantakan dan perlu dire-refacting". Pengalaman membantu menemukan keseimbangan yang baik.
Giorgio

19

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.


1
Apakah kunci 'h' Anda cerdik? ;)
Dave Hillier

3
Tidak, Dave. Saya menggunakan kata ganti Spivak (netral-jender).
JB Rainsberger

Karena pertanyaan seperti pose @DHillHillier, saya cenderung menggunakan "s / he" ... (Terima kasih atas jawaban yang bagus ini, memasukkan kenyataan kembali ke "tim adalah / tidak / memiliki / memiliki ..." klise)
Marjan Venema

1
@ jdl134679 Kontrol versi untuk penyelamatan: softwareengineering.stackexchange.com/posts/260541/revisions
JB Rainsberger

1
@ Walfrat Setelah berpikir lebih jauh, saya memutuskan untuk mengklarifikasi poin ini sedikit lebih jauh. Seseorang yang peduli akan mencoba mempelajari apa yang perlu mereka pelajari, tetapi kemungkinan membutuhkan dukungan, seperti seorang mentor.
JB Rainsberger

10

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 .. .


9
Saya suka Agile, tetapi ini adalah satu kelemahan besar - arsitekturnya sering diabaikan atau dirangkai menjadi satu.
user949300

1
@ user949300 "Agile" seperti dalam manifesto mengatakan sangat sedikit tentang arsitektur. Apa metode yang tepat Anda menarik kesimpulan ini? XP akan mendorong Anda untuk melakukan refactor tanpa ampun. Apakah Anda mendukung BUFD?
Dave Hillier

"XP akan mendorong Anda untuk melakukan refactor tanpa ampun": Sampai Anda menghabiskan lebih banyak waktu refactoring daripada menulis kode baru. Saya pikir solusi terbaik adalah menemukan keseimbangan antara keputusan arsitektur mendasar yang Anda ambil di muka setelah analisis yang cermat, dan keputusan desain yang lebih kecil yang Anda terapkan sepanjang jalan melalui refactoring.
Giorgio

@ user949300 itu karena tim tidak mengatur diri sendiri, jika mereka mereka akan sering berkomunikasi dengan anggota tim lainnya setiap kali keputusan arsitektur perlu dibuat dan mendokumentasikan / berdebat / mendiskusikan ide-ide tersebut dengan benar.
Rudolf Olah

3

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.


1

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.


2
bagaimana ini menjawab pertanyaan yang diajukan, "siapa yang bertanggung jawab untuk membuat keputusan arsitektur dan desain tingkat tinggi"?
nyamuk

1
Terima kasih agas, saya telah mencoba mengeditnya untuk membuatnya lebih jelas seperti apa niat saya untuk menanggapi pertanyaan. Saya membuat beberapa lompatan di kepala saya, tetapi lupa untuk menuliskannya :)
Jay S

1

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.


0

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.


0

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:

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.