Bagaimana arsitek dapat bekerja dengan tim Scrum yang mengatur sendiri?


20

Sebuah organisasi dengan sejumlah tim Scrum yang gesit juga memiliki sekelompok kecil orang yang ditunjuk sebagai "arsitek perusahaan". Grup EA bertindak sebagai kontrol dan penjaga gerbang untuk kualitas dan kepatuhan terhadap keputusan. Hal ini menyebabkan tumpang tindih antara keputusan tim dan keputusan EA.

Misalnya, tim mungkin ingin menggunakan pustaka X atau ingin menggunakan REST alih-alih SOAP, tetapi EA tidak menyetujuinya.

Sekarang, ini dapat menyebabkan frustrasi ketika keputusan tim ditolak. Diambil cukup jauh, ini berpotensi menyebabkan situasi di mana orang-orang EA "merebut" semua kekuatan dan tim akhirnya merasa terdemotivasi dan tidak terlalu gesit sama sekali.

Panduan Scrum mengatakan ini tentang hal itu:

Pengorganisasian sendiri: Tidak seorang pun (bahkan Master Scrum) memberi tahu Tim Pengembangan cara mengubah Product Backlog menjadi Peningkatan fungsi yang berpotensi untuk dirilis.

Apakah itu masuk akal? Haruskah tim EA dibubarkan? Haruskah tim menolak atau sekadar mematuhi?

Jawaban:


20

Tim Pengembangan terdiri dari 3-9 orang dengan keterampilan lintas fungsi yang melakukan pekerjaan yang sebenarnya

Scrum Master harus mengundang "Arsitek Perusahaan" untuk menjadi bagian dari tim proyek. Maka komunikasi antara arsitek dan programmer akan sangat baik.


2
Poin bagus; Namun saya tidak melihat bagaimana ini bisa bekerja jika ada beberapa tim yang bekerja dengan arsitek.
sleske

1
"Hei, EA, sekarang kamu duduk di sini dan masih berkomunikasi dengan orang yang sama. Lebih sering." Bagaimana tepatnya hal ini membantu menyelesaikan konflik antara EA dan pengembang lainnya?
Izkata

@sleske, mengapa tidak membagi grup "arsitek perusahaan" antara tim? atau mempekerjakan lebih banyak arsitek? masalahnya, apakah perusahaan menginginkan SCRUM dan tim yang gesit, atau scrumish. Izkata, pertemuan harian banyak berubah dalam komunikasi tim, serius, ketika EA akan merasa bahwa dia adalah bagian dari DT dan bukan sekelompok arsitektur ekstraterestrial, ada peluang yang lebih baik untuk kompromi.

1
@ariwez: "mengapa tidak membagi grup" arsitek perusahaan "di antara tim?" Karena kami memiliki lebih banyak tim daripada arsitek; juga para arsitek sebagian besar mengerjakan masalah yang mempengaruhi banyak tim.
sleske

@sleske: "Individu dan interaksi atas proses dan alat"

17

Pilihan teknologi yang digunakan adalah bagian dari persyaratan perangkat lunak, yang berarti bagian dari permintaan fitur yang tidak Anda gunakan teknologi tertentu, untuk alasan apa pun.

Arsitek berbicara untuk sistem dan basis kode karena sistem dan basis kode tidak dapat berbicara sendiri. Memiliki seorang arsitek pada umumnya dalam kepentingan jangka panjang terbaik sebuah perusahaan, terutama yang bergantung pada perangkat lunak yang dibangun di rumah.

Arsitek tidak memberi tahu pengembang cara mengubah tumpukan menjadi peningkatan (sprint), mereka mengatakan teknologi mana yang bisa dan tidak bisa digunakan. Anda sedang menyatukan dua masalah berbeda.

Solusinya adalah tidak mengubah apa pun. Jika tim Anda menjadi frustrasi karena arsitek terlalu ketat atau terlalu sombong, itu masalah personil yang tidak ada hubungannya dengan SCRUM dan harus diambil dengan para pemangku kepentingan bisnis sebagai masalah kepuasan karyawan dan, jika mungkin, garis bawah ("Kami membutuhkan waktu x%lebih lama untuk mengembangkan fitur ykarena arsitek ztidak akan membiarkan kami menggunakan Turbo Pascal.")


Ini bukan tentang kepuasan pribadi, ini tentang produktivitas, kualitas dan kepedulian terhadap nilai produk. Saya berasumsi para devs di tim dapat membuat perbedaan itu.
Martin Wickman

2
Seseorang, pada titik tertentu, membuat keputusan bahwa mereka tidak bisa. Itu sebabnya arsitek ada.
Jonathan Rich

4
Saat ini saya sedang mengerjakan pencampuran aplikasi sisi server triple-stack Rails, Java, dan .NET yang benar-benar tidak perlu menjadi sangat rumit. Jadi ya, penjaga gerbang bisa menjadi hal yang baik tetapi keputusan teknologi harus berasal dari para dev yang tiba pada konsensus dan manajemen menyetujui atau mengomunikasikan masalah, bukan non-dev yang membuat keputusan teknologi yang sewenang-wenang atau mengambil keputusan dari tim dev di tengah sprint.
Erik Reppen

4
@ erik Dan ketika tiga tim terpisah tiba di tiga, keputusan konsensus terpisah mereka, Anda mungkin mendapatkan campuran Rails, Java dan .Net.
MarkJ

@ MarkJ jika Anda memiliki tiga tim terpisah yang bekerja secara terpisah untuk aplikasi web sisi server yang sama, Anda layak mendapatkan apa yang Anda dapatkan.
Erik Reppen

6

Hal semacam ini diperlukan untuk menjaga keseimbangan antara kebutuhan tim besar untuk menyelesaikan proyek, dan kebutuhan untuk menjaga tim tangkas kecil.

Secara umum, 'tim lead scrum' terdiri dari satu anggota yang dipilih dari masing-masing tim yang lebih kecil. Itu memberikan beberapa sifat mengatur diri sendiri, serta memberikan beberapa cara representasi sehingga keputusan yang dibuat oleh kelompok tingkat tinggi diterima oleh kelompok gesit.

Untuk skenario khusus Anda, sesuatu harus dilakukan untuk menghentikan penurunan motivasi tim tangkas, tetapi mungkin bukan pemberontakan atau penerimaan sederhana. Tim perlu menyadari bahwa Anda di sana untuk membuat perangkat lunak yang baik, bukan untuk mencapai cita-cita. Memiliki sekelompok tim yang berbeda masing-masing menggunakan teknologi yang berbeda untuk melakukan hal serupa dalam proyek yang sama akan mengarah pada perangkat lunak yang lebih buruk. Memiliki banyak tim yang berbeda menggunakan standar pengkodean yang berbeda dalam proyek yang sama akan mengarah pada perangkat lunak yang lebih buruk.

Jadi, Anda perlu beberapa cara untuk mencapai konsensus tentang bagaimana proyek ini akan bekerja. Scrum tim memimpin digunakan di tempat lain secara efektif. Anda mungkin perlu melakukan sesuatu yang berbeda, atau melihat mengapa kelompok Anda tidak melakukannya secara efektif.


2
Tentu, tetapi memutarnya: memaksa semua tim untuk menggunakan teknologi jelek yang sama bahkan lebih buruk (semua berjalan di jalur jelek yang sama). Padahal memiliki "keragaman" pasti menghasilkan setidaknya beberapa solusi yang akan berkembang.
Martin Wickman

2
@MartinWickman terkadang ada keputusan bisnis di balik memilih teknologi yang jelek. Jika 80% dari pengembang di pasar tertentu memiliki pengalaman dengan teknologi jelek, maka itu bisa masuk akal secara bisnis untuk menggunakan teknologi tersebut karena memungkinkan Anda untuk membawa kontraktor ketika dibutuhkan. Di pasar kecil, Anda mungkin tidak dapat menemukan pemrogram Python yang berharga.
Jonathan Rich

@JonathanRich Ketika saya mengatakan jelek maksud saya jelek. Itu termasuk tidak dapat menemukan siapa pun yang mengetahuinya.
Martin Wickman

1
@ MartinWickman - Tentu, saya membuat asumsi kecil bahwa pengembang tingkat atas yang Anda tunjuk (baik yang ditugaskan, atau diatur sendiri) bukan orang bodoh total.
Telastyn

1
@JonathanRich cacat logika bisnis, IMO. Kuantitas yang lebih besar tidak berarti proporsi kualitas yang lebih tinggi dan dibutuhkan jauh lebih sedikit pengembang Python untuk menyelesaikan pekerjaan jika mereka setidaknya kompeten.
Erik Reppen

5

Pertanyaannya adalah: Apa alasan mengapa tim Arsitek ini ada? Satu-satunya alasan yang dapat saya pikirkan adalah untuk menegakkan interoperabilitas antara berbagai tim. Atau tim bekerja pada berbagai bagian produk tunggal dan tim arsitek ini ada untuk menjaga setiap bagian bekerja bersama.

Saya benar-benar tidak berpikir skema ini dapat bekerja dengan baik di lingkungan yang gesit, untuk alasan yang tepat Anda katakan. Berbagai tim harus mandiri dan karenanya harus menjadi input dan output mereka. Jadi membatasi output mereka seharusnya hanya sebagai bagian dari persyaratan input. Tetapi kendala itu harus masuk akal. Sesuatu seperti "Harus tidak menggunakan perpustakaan X" bukanlah persyaratan yang baik, tetapi mengatakan "Harus membatasi jumlah perpustakaan pihak ke-3 yang digunakan ke minimum" atau "Menambahkan perpustakaan baru, yang tidak digunakan di tim lain harus dibatasi." harus baik-baik saja.

Lalu saya akan membubarkan tim arsitek di semua tim dan menggunakan keahlian mereka dalam masalah arsitektur. Dengan menjadi bagian dari tim, mereka akan dapat melihat masalah dengan lebih baik dan mungkin memiliki ide yang lebih baik atau pendapat yang lebih terdidik tentang mengubah bagian inti arsitektur. Ini juga harus didorong untuk arsitek di seluruh tim untuk berkomunikasi untuk memastikan arsitektur tetap konsisten di seluruh tim.


5

Kelompok di Scaled Agile Framework berbicara dengan sangat baik. Sebagian besar dari kita berurusan di Tingkat Tim, tetapi ketika meningkatkan kita perlu menyadari bahwa ada peran yang harus dimainkan di tingkat Program dan Portofolio. Keputusan arsitektur perlu dibuat di seluruh organisasi, dan itu harus memberi makan apa yang terjadi di tingkat bawah organisasi. Tidak ada yang salah dengan keputusan arsitektur!

Terkait dengan ini, buku terbaru Dean Leffingwell tentang Persyaratan Perangkat Lunak Agile adalah bacaan yang bagus tentang topik ini, saya telah membacanya sendiri.


4

Kami juga memiliki banyak, tim lincah (beberapa melakukan Kanban, beberapa Scrum), dan arsitek. Arsitek bertanggung jawab untuk infrastruktur yang mencakup semua produk kami (perpustakaan pembantu, otentikasi, membangun infrastruktur) dll. Mereka membuat keputusan teknis, tetapi juga menerapkan hal-hal, sebagian besar komponen infrastruktur.

Ini bekerja dengan baik, dan biasanya tidak ada konflik. Saya percaya satu poin penting adalah:

Arsitek tidak memiliki otoritas formal atas tim, dan tidak bisa begitu saja menolak mereka. Biasanya, arsitek membuat keputusan yang berlaku untuk semua produk, dan tim membuat keputusan untuk produk mereka. Jika ada konflik, maka arsitek & tim hanya perlu mencapai kesepakatan, atau naik ke manajemen (meskipun itu jarang terjadi).

Saya pikir sangat penting untuk membuat arsitek dan pengembang menjadi rekan. Keduanya bekerja menuju tujuan bersama, hanya di bidang yang berbeda. Jika tidak ada yang bisa "menolak" yang lain, kerja sama akan lebih baik.


2
Setuju dengan @MartinWickman bahwa "batas" adalah kuncinya, dalam beberapa hal: pertama, pendapat arsitek harus diperhatikan dalam batas perangkat lunak , di mana komponen dari berbagai tim terhubung; kedua, bahwa arsitek tahu batas otoritas mereka sendiri , sehingga mereka akan menahan diri untuk tidak mengambil keputusan tim selama keputusan itu tidak memengaruhi interoperabilitas.
rwong

3

Saya tidak melihat konflik di sini. Dari apa yang saya mengerti, semua EA (sebagai judul sombong saya pikir itu) dimaksudkan untuk dilakukan adalah QA. Semua orang harus sadar akan hal itu.

Anda harus mempertimbangkan, bahwa dalam metodologi pengembangan apa pun (yang layak dianggap sebagai salah satu) persyaratan pengumpulan adalah langkah penting, apakah itu berulang atau dimuka.

Beberapa persyaratan ini diatur oleh kebijakan perusahaan. Dan ini menetapkan aturan dasar:

  • Tim harus mematuhi mereka sebagaimana persyaratan lainnya. Menantang kebijakan kemudian hanya di luar ruang lingkup proyek dan harus ditangani secara terpisah.
  • Tugas EA adalah untuk menegakkan persyaratan ini dan tidak memaksakan keinginan pribadi mereka. Mereka tidak suka X maka itu pendapat pribadi mereka. Tidak lebih, tidak kurang. Perlakukan itu seperti pendapat lain. Namun, jika EA dapat menunjukkan bahwa menggunakan X melanggar persyaratan yang ada, maka mereka berhak untuk melarang penggunaan X dan jika mereka tahu alternatif yang bisa diterapkan dan tim tidak, maka itu adalah hak mereka untuk menegakkannya.

Namun demikian, suatu persyaratan terpenuhi atau tidak. Jika tekad itu sulit untuk dibuat, maka persyaratannya kurang dan Anda perlu mengulanginya untuk menjadi benar-benar dapat diuji (dalam arti yang lebih luas). Anda harus mengatasinya seperti pengulangan persyaratan.


Mereka jelas melakukan lebih dari QA. Mereka membuat keputusan tentang penggunaan alat.
Erik Reppen

@ErikReppen: Saya agak tidak jelas. Maksud saya QA adalah apa yang seharusnya mereka lakukan.
back2dos

@ back2dos: Saya pikir Anda perlu mengubah QA untuk Standardisasi. Saya tahu apa yang Anda katakan, tetapi QA adalah tim yang sepenuhnya berbeda dan membingungkan maksud Anda.
gbjbaanb

2

Arsitek Anda tidak boleh mengesampingkan keputusan yang dibuat oleh tim tangkas Anda. Arsitek Anda harus memasukkan ini dalam persyaratan / cerita yang diteruskan ke tim. Mereka harus terus memperbarui tim ketika lanskap proyek berubah & persyaratan interoperabilitas baru diperkenalkan.

Arsitek memberikan perintah dan memeriksa keputusan teknis adalah cacat budaya. Mereka melihat diri mereka sebagai "bos" daripada sekadar mempertahankan tujuan / visi bersama & menjaga tim yang terpisah pada halaman yang sama. Metodologi tangkas didasarkan pada komunikasi & kontak. Ketika arsitek Anda tidak terlibat sampai setelah keputusan dibuat, mereka gagal tangkas.


"Ketika arsitekmu tidak terlibat sampai setelah keputusan dibuat, mereka gagal tangkas." - Jika kita membalikkan pernyataan ini: "Ketika tim tidak melibatkan Arsitek ketika membuat keputusan, maka tim gagal dalam tangkas." Jika ada keputusan yang dibuat oleh tim yang merupakan perubahan teknologi, pola yang ada, dll ... maka tim perlu menyertakan seorang Arsitek untuk memastikan keseluruhan produk tetap kohesif.
Metro Smurf

2

Martin, saya pikir Anda mungkin memiliki kesalahpahaman tentang bagaimana fungsi tim yang mengatur diri sendiri di lingkungannya.

Anda mengutip Panduan Scrum: "Tidak seorang pun (bahkan Master Scrum) memberi tahu Tim Pengembangan cara mengubah Product Backlog menjadi Peningkatan fungsi yang berpotensi untuk dirilis."

Ini bukan lisensi untuk tim Scrum untuk melakukan apa pun yang diinginkannya (asalkan diberikan) tanpa memperhatikan teknologi dan kebutuhan bisnis perusahaan secara keseluruhan, dan kebutuhan tim lain.

Tentu saja para pemangku kepentingan dapat menyalahgunakan pengaruhnya. Itu adalah salah satu tantangan kolaborasi, dan tentu saja tidak terbatas pada EA. Tetapi kolaborasi tidak berakhir di batas tim.


0

Waterfall atau Scrum (ini sepertinya mencampur dua, yang ya, tidak akan berhasil), yang kedengarannya seperti lapisan manajemen yang tidak ada gunanya bagi saya sejak awal. Gatekeeper pada keputusan teknologi harus menjadi pemimpin dev, manajer pengembangan keseluruhan yang tugasnya harus menjaga preferensi dev dari mengubah aplikasi Anda menjadi hydra pilihan teknologi, dan siapa pun anggaran harus membayar tagihan potensial.

Tidak ada yang terus mengejutkan saya seperti non-devs yang benar-benar memiliki keberanian untuk membuat keputusan teknologi tanpa berkonsultasi dengan orang-orang yang harus menanggung konsekuensi dari keputusan itu.


Ini lebih mirip kata-kata kasar daripada jawaban.
Bryan Oakley

Seseorang harus melakukannya.
Erik Reppen
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.