Apakah ada survei sampai sejauh mana pengembang suka atau benci scrum? [Tutup]


8

Latar belakang: Selama konferensi, seorang analis menunjukkan dalam tweet bahwa pengembang membenci scrum.

Saya dan orang lain menjawab bahwa ini bukan masalahnya, dan mulai membahas berbagai skenario tentang mengapa pengembang tidak menyukai scrum.

Salah satu skenario di mana pengembang malas tidak dapat bersembunyi di proyek scrum. Mereka terus ditantang oleh tim untuk berkontribusi.

Diskusi ini menghasilkan posting blog dan video http://elsewhat.com/2010/05/20/lazy-developers-hate-agile-and%C2%A0scrum/

Saya mendapatkan tiga komentar yang saya coba jawab dengan cara netral, tetapi komentar mereka menunjukkan bahwa ada beberapa orang yang membenci scrum (dan saya selalu 100% yakin mereka bukan pengembang malas).

Pertanyaan

Pernahkah ada survei di antara pengembang tentang seberapa banyak pengembang suka atau benci scrum?


5
Mengikuti scrum akan membuat perasaan terus tergesa-gesa, bahkan ketika tidak ada yang berniat membuat saya merasa seperti itu. Saya tidak suka perasaan tergesa-gesa, keefektifan saya berkurang ketika saya merasa saya dan saya tidak suka keefektifan saya menurun ... lingkaran setan ...
Marjan Venema

1
mungkin pengembang yang tidak pernah berlatih scrum tetapi sebaliknya memiliki pendapat yang sangat kuat tentang hal itu dihitung?
Matthieu M.

Di daerah saya, sebagian besar pengembang, termasuk saya, sama sekali tidak tahu Scrum. Beberapa orang yang senang mendengarnya sebagai kata kunci yang bekerja berpasangan dengan XP.
mouviciel

1
Scrum hanya berfungsi ketika tim membeli. Jika tim yang mencetak cerita membalutnya, atau jika manajemen mencoba menetapkan batas kecepatan yang sewenang-wenang, itu akan mengerikan. .
SoylentGray

Ada survei di luar sana: surveymonkey.com/r/JLF6D25
Sampada

Jawaban:


33

Scrum sangat menuntut ...

.. terutama ketika diselewengkan oleh manajemen.

Karena itu saya tidak ragu banyak pengembang membenci Scrum.

Salah satu cara menyesatkan Scrum yang saya lihat di sebuah perusahaan besar adalah dengan membagi kecepatan oleh pengembang. Dan tentu saja membuatnya sangat terlihat pada standup harian. Coba tebak apa yang terjadi jangka pendek?

Saya telah menemukan bahwa Scrum biasanya tidak cocok di beberapa organisasi, terutama perusahaan publik & pemerintah.

Setelah 5 tahun berlatih intensif Scrum, mengajar & pembinaan, baik di perusahaan besar dan perusahaan yang sangat kecil, saya sampai pada kesimpulan bahwa Scrum hanyalah teknik lain seperti Jawa adalah bahasa lain selain C # dan yang membuat perbedaan adalah individu yang menggunakannya, bukan tekniknya sendiri.


6
+1 untuk komentar tentang individu. Yang ingin saya tambahkan adalah bahwa basis kode juga membuat tuntutan dan tidak semua basis kode cocok untuk "dikerjakan" dalam lingkungan scrum. Sementara banyak bagian dari rangkaian perangkat lunak kami dapat dipecah menjadi potongan "byte-size", ada juga bagian di mana perubahan benar-benar tidak dapat secara efektif dipecah menjadi potongan yang cukup kecil sehingga cocok untuk pendekatan scrum.
Marjan Venema

5
+1 untuk mencatat bahwa "Metodologi Scrum" yang digunakan oleh beberapa perusahaan / tim tidak memiliki banyak kemiripan dengan Scrum asli seperti yang dibayangkan oleh Schwaber et al. Juga benar bahwa itu tidak cocok untuk beberapa jenis proyek, terutama untuk kode lama.
Péter Török

1
@ Péter Török: bagaimana saya tahu Anda seorang Scrum Practionner. Anda akan terkejut melihat apa yang saya lihat;)

2
Sepakat. Saya telah bekerja di banyak organisasi di tim yang mengikuti metodologi Agile. Orang-orang yang bekerja adalah orang-orang yang memahami dan bereaksi terhadap kebutuhan orang-orang dalam tim dan juga proyek. Lucunya, itu agak implisit dalam Agile Manifesto.
Ian

Pertanyaan sesungguhnya yang saya temukan adalah diri saya bertanya; Apakah proyek scrum sesat lebih buruk daripada proyek air terjun sesat? Atau itu hanya mendapat perhatian lebih karena itu oleh beberapa dipandang sebagai cawan suci pembangunan.
dparnas

5

Meta-komentar: Akan menyenangkan untuk memiliki pertanyaan survei tentang Programmer.

Karena Scrum sangat bervariasi antara tim dan organisasi yang berbeda, pertanyaan ini akan sangat sulit dijawab. Scrum harus tentang memberdayakan tim untuk memberikan perangkat lunak yang hebat dan pengembang harus seperti itu.

Dimana yang salah? Jawabannya ada dalam pernyataan saya di atas. Tim tidak diberdayakan atau perangkat lunak yang hebat tidak dikirimkan.

Ada begitu banyak mode kegagalan, berikut adalah beberapa:

  • Pemilik produk tidak memahami pelanggan atau bisnis.
  • Tim tidak mengerti pelanggan atau bisnis.
  • Masalah organisasi menghalangi tim dalam mencapai tujuan mereka.
  • Scrum berubah menjadi manajemen mikro sehari-hari.

Itu terkadang dikenal sebagai scrum-buts .

IMO Scrum lebih disukai / sukses jika:

  • Tim telah membuat keputusan untuk mengadopsi Scrum karena merasa itu sesuai untuk produk / proyek.
  • Ada umpan balik yang kuat / berkelanjutan dari pelanggan melalui pemilik produk.
  • Kirim setelah setiap sprint.
  • Tim memiliki otonomi, pengorganisasian diri dan kepercayaan / dukungan penuh dari organisasi.
  • Sebagian besar item dalam jaminan datang dari tim.

Komentar lain adalah bahwa dalam programer "malas" Scrum hanya bertanggung jawab kepada tim sehingga mereka dapat memilih untuk bertanggung jawab kepada bos mereka. Bagaimanapun, saya tidak berpikir ini adalah faktor.

Masalah yang saya lihat dengan Scrum adalah masalah ayam dan telur. Jika Anda sudah gesit, Anda mungkin tidak perlu Scrum. Jika Anda secara inheren tidak tangkas, Scrum mungkin tidak akan mengubahnya, bahkan mungkin akan memperburuk keadaan karena akan membawa kelincahan ke permukaan dan membuatnya sangat terlihat sehingga kekuatan anti-gesit dapat menghancurkannya :-)

Bisakah organisasi yang tidak gesit menjadi gesit? Saya tidak tahu Saya pikir Scrum ingin melakukan itu, tetapi saya tidak yakin itu bisa.


5

Menurut pengalaman saya, Pengembang / arsitek sangat membenci scrum. Bisa jadi karena alasan di bawah ini

  1. Banyak organisasi produk yang menganggap pengiriman bisnis adalah tujuan utama dan mengikat setiap cerita sprint dengan kebutuhan bisnis. Oleh karena itu mereka membajak / kompromi motif arsitektur, platform, desain bersih, kualitas kode dalam beberapa kesempatan. Terkadang mereka tidak mempertimbangkan teriakan pengembang. Inilah yang dirasakan oleh pengembang profesional yang tidak malas.

  2. Agile / scrum memberikan dominasi, pemilik produk lenience / manajer produk banyak pada tidak memberikan rincian lengkap mengenai persyaratan dan inturn yang mereka harapkan pengembang bayangkan / menganggap kebutuhan untuk melanjutkan pengembangan. Hal ini menyebabkan perbedaan dalam implementasi, terlalu banyak cacat, rasa sakit yang luar biasa besar bagi pengembang dengan membakar minyak tengah malam mereka dalam banyak hal.

  3. Dalam banyak kesempatan pemilik produk berkompromi dengan persyaratan teknis dengan tujuan bisnis yang sering mengabaikan pengembang, pendapat arsitek tentang produk, bentuk, tujuan jangka panjang dari arsitektur dan mereka memberi kami solusi jangka pendek untuk diproses yang bukan pilihan yang tepat untuk produk apa pun

  4. Akhirnya Anda akan berakhir dengan produk yang memiliki cacat, cacat desain, kadang-kadang membangun kemunduran, peringkat ketidakpuasan dari pengguna, masalah kinerja, basis kode yang mengerikan bagi pengembang untuk disentuh lebih lanjut.

Saya benar-benar tidak menganggap scrum / gesit sebagai metodologi yang lebih baik dalam banyak kesempatan.


Menarik bahwa Anda menunjukkan bahwa scrum dapat mengarahkan pemilik produk ke optimisasi jangka pendek untuk memberikan fungsionalitas baru, sementara solusinya berubah menjadi bola besar lumpur laputan.org/mud . Saya akan percaya bahwa tim bersama-sama akan memiliki kesempatan yang lebih baik untuk meyakinkan PO dari nilai arsitektur teknis, daripada pengembang individu dalam peran pengembang terpisah.
dparnas

3

Saya membencinya. Dan sebagian besar pengembang yang saya kenal juga membencinya.

Cukup sulit untuk melakukan kerja otak dan kreatif seperti pengembangan perangkat lunak di bawah mikroskop.


3
Saya benar-benar tidak tahu apa yang Anda maksudkan dengan ini. Apakah Anda benar-benar menggunakan scrum atau apakah menurut Anda itu akan membuat Anda merasa?
SoylentGray

2
Di bawah mikroskop? Apa maksudmu?
Eoin Carroll

2
Apakah Anda melakukan Scrum atau ScrumTapi?
Arnold Zokas

2
"Di bawah mikroskop" berarti harus membenarkan dan menunjukkan kemajuan dengan pekerjaan Anda setiap hari, atau setidaknya merasa seperti ini. Pengembangan perangkat lunak kreatif tidak berfungsi seperti itu. Anda menunjukkan pekerjaan Anda ketika sudah siap, dan jika Anda membutuhkan bantuan, Anda hanya perlu bertanya.
Acumenus
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.