Apa peran pengembang utama dalam tim yang gesit?


42

Dalam tim pengembangan yang tidak gesit, pengembang utama umumnya :

  • Menetapkan standar (pengkodean dan sebaliknya)
  • Meneliti teknologi baru untuk tim
  • Menetapkan arahan teknis untuk tim
  • Memiliki keputusan akhir tentang masalah
  • Mendesain arsitektur suatu sistem

Namun tim yang gesit bekerja secara berbeda:

  • Tim lincah akan mengandalkan desain yang muncul, bukan di depan
  • Tim lincah mendesain bersama, alih-alih desain didikte oleh satu orang
  • Tim lincah memutuskan arah teknis mereka sendiri, yang terbaik untuk memberikan proyek

Di mana ini meninggalkan pengembang utama dalam tim tangkas? Apakah mungkin untuk memiliki pengembang utama dalam tim yang gesit? Apakah tim yang gesit menuntut tanggung jawab yang berbeda dari seorang pemimpin?


Menjawab Matts komentar terakhir saya akan menambahkan bahwa pengembang utama harus menjadi orang yang mengambil keputusan arsitektur kunci yang mempengaruhi banyak komponen sistem. Dia juga berada di pihak yang membawa tanggung jawab ini dan harus berubah pikiran jika ada yang salah.
user2236631

Jawaban:


46

Tidak ada yang gesit mengubah bagaimana pengembang utama harus berfungsi. Mereka harus melibatkan anggota tim lainnya dengan keputusan arsitektur sistem, dan arahan teknis apa pun model pengembangan yang diikuti.

Menyerahkan keputusan dengan dekrit adalah cara yang mengerikan bagi tim pengembangan mana pun untuk dijalankan. Agile hanya membuat pembelian dari seluruh tim menjadi proses yang lebih eksplisit, dan pengembang utama seharusnya tetap melakukan itu.

Hanya karena tidak ada peran pengembang utama dalam metodologi scrum tidak berarti pendapat programmer yang lebih berpengalaman bukanlah yang paling dihormati. Agile tidak membiarkan semua orang menjadi liar pada hal mereka sendiri dan kemudian mencoba untuk menyatukan semuanya, masih ada visi dan arahan terpadu yang perlu ditetapkan.


Bisakah Anda menambahkan beberapa klarifikasi pada apa yang Anda maksud dengan, "Membagikan keputusan dengan dekrit adalah cara yang mengerikan bagi tim pengembangan mana pun untuk dijalankan"? Saya setuju dengan sisa posting Anda, tetapi saya hanya setuju dengan pernyataan yang disebutkan dalam cara tertentu tetapi tidak yang lain. Sebagai contoh, bagaimana diputuskan untuk menggunakan SOA pada tingkat basis data? Bukankah itu merupakan dekrit atau tidakkah seseorang harus memiliki keputusan akhir? Saya bertanya karena saya seorang pemimpin tim dan menghadapi situasi ini. Saya membuat panggilan untuk tidak menggunakan SOA berdasarkan kebutuhan bisnis. Tidak ada cukup waktu untuk memungkinkan semua pengembang untuk mendiskusikan / memperdebatkan setiap poin.
Brian

@Brian membuat keputusan arsitektur akan menjadi cerita dalam sprint, mungkin yang diperuntukkan bagi anggota tertentu tetapi sebaliknya sama dengan cerita lainnya. Itu harus mengalami peer review seperti cerita lainnya. Argumen waktu adalah omong kosong, jika Anda kebetulan kehilangan X atau memutuskan untuk mencoba Z bahwa semua orang di tim tidak terbiasa dengan Anda AKAN menghabiskan lebih banyak waktu untuk berkembang sebagai hasilnya, bahkan satu hari penuh berdebat tentang desain akan menjadi tidak signifikan secara komparatif . Rapat / ulasan sederhana untuk mengatakan "Saya memilih A karena X, Y, Z." mungkin akan memakan waktu satu jam dan membuatnya menjadi upaya kolaborasi.
Ryathal

30

Dalam tim yang gesit, setiap orang seharusnya mengesampingkan ego mereka.

Jika salah satu anggota tim tangkas memiliki lebih banyak pengalaman daripada yang lain, apa yang kemungkinan akan terjadi adalah bahwa anggota yang berpengalaman akan terlibat dalam sebagian besar tinjauan kode dan orang-orang akan sering tunduk pada pengalaman orang tersebut ketika membuat keputusan tim.

Jadi, pengembang "pemimpin" akan terus "memimpin," tetapi sebagai konsekuensi alami dari pengalaman mereka dan bukan sebagai fungsi yang diamanatkan dari jabatan mereka.

Itu di dunia yang ideal di mana orang bisa mengesampingkan ego mereka. Semoga berhasil!


Tidak akan setuju Saya telah melihat terlalu sering keputusan terburu-buru yang dibuat oleh pengembang sendiri dengan konsekuensi buruk hanya karena timahnya tidak ada dan pengembang tidak terbiasa dengan situasi seperti itu. Menggiring kucing, saya katakan.
andrew.fox

20

Selain jawaban Ryathal :

Anda berbicara tentang desain yang muncul dan arahan tim seolah-olah mereka mengalir dari tim secara serempak dan harmonis. Kelompok orang, kelompok pemrogram terutama mengalami konflik . Sebagai tim yang memimpin, pekerjaan Anda dalam tim yang gesit lebih sebagai wasit atau katalis daripada di air terjun. Ketika tim memiliki konflik tentang desain apa yang akan digunakan misalnya, Anda akan memastikan bahwa orang memiliki pendapat yang sama dan tetap memperdebatkan kelebihan. Dan Anda akhirnya menjadi wasit yang solusi yang diusulkan tim akan pergi ketika jalan tidak jelas.

Ini adalah salah satu tanggung jawab utama pemimpin, tetapi banyak hal lain diperlukan untuk membuat sekelompok orang menjadi satu tim. Anda masih perlu memberikan contoh sejauh pengkodean yang baik berjalan, dan seringkali memaksakan hal itu (baik secara langsung atau dengan menciptakan budaya untuk melakukannya). Anda perlu memfasilitasi komunikasi antara semua anggota tim Anda, karena sekali sehari standup tidak akan memotongnya.

Hal penting lain yang Anda abaikan adalah rapat. Tidak praktis membawa seluruh tim ke setiap pertemuan di mana tim perlu berinteraksi dengan orang-orang bisnis, tim teknis lainnya, dll. Sebagai pemimpin tim, Anda adalah perwakilan tim. Anda pergi ke pertemuan sehingga mereka dapat tinggal di meja mereka dan menyelesaikan pekerjaan. Anda adalah titik kontak sehingga mereka tidak terganggu oleh orang-orang yang mampir secara langsung. Dan Anda bekerja untuk mengambil informasi dari dunia luar (apa yang sedang dikerjakan tim lain, seperti apa kelincahan tim sprint berikutnya, bagaimana status req terbuka itu, dll.), Merebusnya untuk mereka dan mengomunikasikannya.

Singkatnya, Anda adalah pelumas untuk memastikan bahwa mereka dapat berjalan dengan lancar.


1
Ini sangat penting dalam pertemuan yang "Timeboxed", artinya rapat, atau diskusi khusus, tidak akan berlangsung lebih lama dari X menit. Pada akhirnya, seseorang membuat keputusan dan membuat prosesnya terus berjalan. Ini bisa menjadi Pengembang Utama untuk arsitektur sistem dan diskusi terkait.
Chris

1
Baik. Pengembang timbal juga harus diarahkan untuk meningkatkan pengalaman dan pemahaman tim mereka, dengan rencana jangka panjang adalah tidak hanya menjadi 'pemimpin' tetapi juga anggota tim rekan-rekan.
David 'the botak jahe'

Apa yang telah Anda gambarkan adalah ScrumMaster.
DBedrenko

6

Deskripsi tidak tangkas Anda tidak membatalkan deskripsi tangkas Anda.

Tim lincah akan mengandalkan desain yang muncul, bukan di depan.

Tidak ada definisi Anda tentang pengembang utama yang mengatakan desain harus ada di depan. Dia mungkin menetapkan arah, dan dia mungkin masih mengeluarkan desain awal. Desain itu pasti muncul.

Tim lincah mendesain bersama, alih-alih desain didikte oleh satu orang

Tidak ada definisi Anda tentang pengembang utama yang mengatakan bahwa ia menentukan desain. Meskipun dia mungkin memiliki keputusan akhir, hanya pemimpin yang miskin yang akan sepenuhnya mengabaikan pikiran rekan satu timnya yang mayoritas. Di sisi lain, hanya tim yang buruk yang akan sepenuhnya mengabaikan pemikiran pengembang utama.

Tim lincah memutuskan arah teknis mereka sendiri, yang terbaik untuk memberikan proyek

Sekali lagi, ini tidak berarti bahwa arahan pada awalnya tidak menetapkan arah ini. Pemimpin adalah bagian dari tim lincah ini. Bahkan dalam lingkungan yang tidak gesit, hanya pemimpin yang buruk yang akan terus bergerak ke arah tim ketika hal itu secara sadar menjadi tidak mungkin, atau ketika informasi baru telah disajikan untuk membatalkan arah ini.


6

Pertanyaan itu menimbulkan beberapa pertanyaan lain. Menurut Anda, apa yang membuat Anda memenuhi syarat untuk memberi tahu tim rekan insinyur perangkat lunak apa yang harus dilakukan? Apakah ini pengalaman Anda? Apakah itu gelar kecil yang lucu yang diberikan atasan Anda kepada Anda? Apakah itu egomu? Masa jabatan Anda di perusahaan? Apakah itu "panik" Anda? Gaya mu?" "Keterampilan kepemimpinan Anda?"

Tim lincah tidak membagikan lencana atau topi satu sama lain yang mengatakan, "Selamat, kau jenius super kami - kaulah satu-satunya yang diizinkan melakukan pekerjaan genius ganda super rahasia." Sebaliknya, fokusnya adalah BEKERJA DI TANGAN. Jika Anda memang lebih berpengalaman, maka pengalaman itu harus MENUNJUKKAN seberapa baik desain Anda mendorong pekerjaan ke arah penyelesaian. Tugas yang Anda pilih sendiri (kartu) harus mencerminkan bidang yang paling Anda kuasai. Di sisi lain, jika beberapa anak yang baru lulus dari perguruan tinggi memiliki ide yang lebih baik, dan itu sesuai dengan konteksnya lebih baik daripada sesuatu yang muncul oleh veteran 40 tahun yang muncul Dengan, mengapa kita harus pergi dengan desain yang lebih buruk? Tempat kerja kami bukan kantor terapi - itu tempat kami datang untuk membangun hal-hal hebat.

Itu menimbulkan pertanyaan lain: siapa yang bisa memutuskan apa artinya "lebih baik"? Jawabannya: tim pemangku kepentingan. Itu berarti pengembang, persyaratan orang, penguji, pebisnis, dll. Yang merupakan pembangun dan pengguna dari hal yang dimaksud. Jika Anda punya ide bagus, Anda bisa menunjukkan mengapa itu lebih baik. Jika Anda tidak bisa melakukan itu, maka tidak ada alasan bagi tim untuk percaya bahwa ide Anda lebih baik. Agile mendorong meritokrasi.

Jadi, apa yang terjadi pada "pemimpin tim pengembangan?" lincah? Tidak ada - mereka lebih baik hidup sampai nama itu - mereka lebih baik SEBENARNYA dapat menghasilkan perangkat lunak yang lebih baik daripada orang lain di tim. Kalau tidak, tidak ada alasan untuk menyebut mereka "pemimpin" - itu hanya lencana kecil atau topi lucu, dan itu tidak ada artinya. Banyak orang menemukan ini mengancam. Mereka merasa seperti telah "bekerja untuk" lencana atau topi lucu. Pengembang yang baik tidak bekerja untuk topi lucu. Mereka bekerja untuk membangun perangkat lunak yang hebat, dan mereka berencana untuk melakukannya sampai mereka serak - tujuan mereka adalah menjadi lebih baik dalam membangun perangkat lunak, setiap hari. Jika itu bukan Anda, mungkin Anda mungkin ingin melihat manajemen proyek. Anda mungkin akan lebih bahagia.


+1 untuk "THE WORK AT HAND". Saya setuju untuk fokus pada solusi terbaik untuk apa yang harus Anda berikan sekarang. Ini bukan tentang siapa yang menemukan ide itu.
Kwebble

Jika semua yang dilakukan oleh seorang pemimpin tim develompent pada tim SCRUM menurut Anda adalah "menghasilkan perangkat lunak yang lebih baik daripada orang lain di tim", maka mereka semua adalah pengembang tanpa tanggung jawab jarak jauh. Apakah itu poin yang disarankan oleh jawaban Anda? Kalau tidak, ini benar-benar tidak menjawab pertanyaan tentang bagaimana seorang pemimpin dev cocok dengan tim SCRUM.
DBedrenko

Ya itu. Mereka adalah insinyur yang baik, sehingga mereka memiliki peran sebagai insinyur (secara teknis, "anggota tim"). Apa lagi yang akan mereka?
Calphool

3

Dalam pengalaman saya tentang Agile, tim pengembangan secara keseluruhan diberikan tanggung jawab yang lebih sedikit daripada yang disiratkan oleh contoh Anda, membiarkan pengembang dan arsitek memimpin untuk mengoordinasikan pilihan desain tingkat atas, tetapi menyerahkan desain tingkat yang lebih rendah kepada tim tangkas secara keseluruhan.

Jadi, pengembang utama tetap bertanggung jawab atas arsitektur sistem dan pilihan teknologi. Ini sangat penting: walaupun tangkas mendorong desain yang muncul dan refactoring ini harus terjadi pada tingkat objek kode. Sistem secara keseluruhan perlu memiliki tingkat pra-desain dan kekakuan yang lebih besar selain risiko proyek menjadi kekacauan yang tidak terkoordinasi.

Dalam proyek kami, pengembang utama mengamanatkan pilihan teknologi, dan merancang bagaimana komponen sistem akan berinteraksi satu sama lain. Pertemuan perencanaan tangkas berfokus pada bagaimana merancang komponen-komponen itu dalam mandat tingkat yang lebih tinggi. Sebagai tambahan yang menyenangkan, ini menjaga batasan ruang lingkup pada pertemuan perencanaan yang membosankan.

Dia juga berfungsi sebagai titik pilihan terakhir. Ketika masing-masing programmer menghadapi masalah yang tidak dapat mereka perbaiki, mereka akan pergi memimpin dan tanggung jawab terakhir untuk memperbaiki masalah adalah miliknya.


Ini mirip dengan pengalaman saya, tetapi saya memang berpikir bahwa ada lebih banyak "lencana" dan "topi" daripada yang diperlukan. Hampir tidak ada perbedaan antara bagaimana pengembang yang baik berpikir tentang desain dan apa yang dipikirkan arsitek tentang desain.
Calphool
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.