it-swarm-id.com

Apakah pendekatan gesit terlalu banyak alasan yang nyaman untuk koboi

Saya percaya bahwa pendekatan gesit adalah yang terbaik untuk proyek-proyek di mana persyaratannya tidak jelas dan banyak interaksi diperlukan untuk membantu membentuk ide-ide pengguna akhir.

Namun ... Dalam pekerjaan profesional saya, saya terus berakhir di perusahaan tempat pendekatan "gesit" digunakan sebagai alasan untuk mengapa tidak ada upaya dimasukkan ke dalam desain muka; ketika persyaratan dipahami dengan baik.

Mau tidak mau saya berpikir bahwa jika pendekatan gesit tidak ada, saya akan duduk di sini dengan spesifikasi tingkat tinggi yang bagus dan tidak harus mengunjungi kembali layar dan fungsionalitas yang sama setiap hari kedua ketika sesuatu yang lain muncul atau lebih dan jadi tidak memikirkan itu.

Apakah manfaat dari metodologi lincah benar-benar cukup untuk melebihi alasan untuk menjadi lumpuh karena petunjuk teknis koboi?

Pembaruan: Ironisnya saya sekarang adalah Scrum Master bersertifikat. Salah satu makalah yang dipresentasikan pada kursus Scrum mengamati bahwa proses pengembangan terbaik adalah di mana ada seorang ahli atau guru tunggal membuat keputusan desain, namun itu memiliki kelemahan yang jelas. Scrum mengalihkan tanggung jawab untuk memproduksi perangkat lunak berkualitas ke "Tim" yang berarti tim di bawah standar dapat lolos dengan mengeluarkan spageti yang saya rasa tidak ada bedanya dengan proses pengembangan Agile dan non-Agile lainnya.

73
sipwiz

I'm Glad it has a name

Saya percaya jika Anda menggunakan pengembangan Agile sebagai alasan untuk pemrograman gaya koboi, maka Anda tidak benar-benar mengikuti pengembangan Agile. Koboi akan selalu menjadi koboi, tidak peduli proses apa pun yang Anda berikan kepada mereka.

87
Dean Harding

Agile tidak lebih disalahkan untuk praktik pembangunan yang buruk daripada BDUF. Masalahnya terletak pada disiplin, atau ketiadaannya, dalam menerapkan praktik. Tujuan praktik BDUF adalah untuk mengidentifikasi arah proyek dan menentukan risiko sebelumnya. Tujuan dari praktik lincah adalah untuk menjaga kondisi perkembangan cukup fleksibel untuk dengan cepat mengubah arah. Sebuah proyek gesit dapat menyiapkan cerita pengguna yang sangat rinci sehingga tim menyadari arah masa depan dan masih hanya memilih 2 atau 3 per iterasi untuk sepenuhnya diimplementasikan. Masalahnya tetap sama, apa pun metodologi yang digunakan: manajemen membiarkan koboi berkeliaran.

[BDUF: Desain Besar Di Depan]

20
Huperniketes

Agile, seperti apa saja, dapat digunakan untuk membahas perilaku buruk atau mencoba memecahkan masalah yang menurut tim mereka tidak bertanggung jawab.

Namun, keajaiban dalam beberapa Agile metodologi seperti Scrum adalah bahwa mereka akan memberikan banyak visibilitas pada masalah dalam organisasi. Termasuk masalah dalam tim!

Anda akan diberikan kesempatan untuk menyelesaikannya saat masalah itu muncul.

Jika masalahnya ada pada koboi, ini akan sangat terlihat setelah iterasi pertama. Jika masalahnya ada di tempat lain, Anda juga akan segera melihatnya.

13
user2567

Anehnya, dari proyek "lincah" yang pernah saya ikuti, sepertinya lebih seperti alasan manajemen untuk melewatkan fase pengumpulan-persyaratan daripada keinginan koboi untuk hanya memulai pengkodean. Proyek saya sangat mengecewakan karena kami tidak memiliki pengguna akhir untuk berinteraksi. Alih-alih, kami memiliki direktur yang berbicara kepada penjualan untuk mengetahui apa yang mereka pikir diinginkan pelanggan, kemudian memanggil rapat dan menjelaskannya kepada manajer, yang kemudian mulai menugaskan tugas kepada pengembang. Pada proyek "baik" kita mungkin memiliki presentasi PP untuk merujuk, tapi biasanya kita akhirnya menghabiskan rapat scrum harian kami menanyakan bagaimana fitur seharusnya bekerja, dan manajer menuliskan pertanyaan-pertanyaan dan bertanya pada sutradara, ini buang-buang waktu - tapi "gesit"!

12
TMN

Saya tidak akan mengatakan bahwa saya adalah penggemar Waterfall, karena saya juga berurusan dengan creep scope yang selalu membuat frustrasi, tetapi saya selalu melihat Agile sebagai konsesi untuk masalah, bukan cara yang efektif untuk memeranginya. Desain yang bagus, dengan pengujian iteratif awal dan banyak prototipe kertas tampaknya jauh lebih efektif.

7
Morgan Herlocker

Saya melihat pertahanan Agile Development mengatakan bahwa itu tidak bertanggung jawab atas kegagalan yang disebabkan oleh koboi. Sukses dengan Agile membutuhkan ketekunan dan kecerdasan.

Ini sepertinya posisi yang masuk akal, selama Anda menerapkan konsesi yang sama untuk metodologi lain. Jika Anda tidak bisa menyalahkan Agile untuk kegagalan proyek yang disebabkan oleh koboi, Anda tidak bisa menyalahkan metodologi non-Agile untuk kegagalan proyek yang disebabkan oleh koboi.

Kita kemudian dapat berdebat apakah ada korelasi (bukan sebab-akibat!) Antara Agile dan koboi. Dengan hanya bukti anekdotal, saya yakin ada. Apakah ini dianggap sebagai cara yang baik untuk bertahan dengan praktik koboi tanpa terdeteksi oleh manajemen?

Tentu saja, jika kita menerima bahwa koboi mungkin tidak tersebar secara merata di seluruh metodologi, dan kita menerima bahwa koboi merusak keberhasilan penggunaan suatu proses, kita telah membuatnya sangat sulit untuk menguji apakah suatu proses berhasil. Klaim bahwa satu proses lebih baik (dalam konteks) menjadi dekat dengan tidak dapat dibenarkan. Ini adalah salah satu masalah yang membuat saya malu karena profesi saya - kurangnya dasar ilmiah dari banyak klaim.

(Ngomong-ngomong, aku benci menyebut alternatif untuk Agile "air terjun", karena proses air terjun tampaknya menjadi jerami yang diserang semua orang, tetapi sangat sedikit orang yang pernah benar-benar digunakan tanpa iterasi.)

6
Oddthinking

Agile baik-baik saja asalkan bekerja untuk tim Anda.

Terlalu banyak yang menjualnya sebagai cara untuk mengubah tim yang buruk menjadi tim yang baik, dan itu tidak berfungsi seperti itu. Anda tidak dapat mengambil orang jahat dan menerapkan proses untuk tiba-tiba membuat mereka berguna.

Saya menyukai banyak ide di balik gesit, tetapi kegagalan yang saya lihat berulang kali adalah bahwa para manajer mendorong serangkaian "proses gesit" yang ketat, yang terbang di hadapan seluruh konsep gesit, bahwa tim harus mandiri mengorganisir.

Sejauh "koboi", saya menemukan bahwa untuk semua tim lincah yang saya ikuti, proses berfungsi untuk memperlambat mereka lebih dari membiarkannya menjadi liar. Saya tidak pernah mengalami situasi di mana tangkas bertugas aktifkan a "cowboy coder".

Untuk tim yang bagus, tampaknya bekerja dengan baik (sekali lagi, sebagian besar proses tampaknya bekerja dengan baik ketika Anda memiliki tim yang bagus, lucu bagaimana cara kerjanya bukan?).

Untuk tim lain, dalam pengalaman saya, itu tidak pernah membantu orang jahat melakukan lebih baik, tetapi itu kadang-kadang berfungsi untuk meruntuhkan orang-orang produktif.

Secara keseluruhan, saya pikir yang penting adalah membangun tim yang baik, memberi tahu mereka apa yang Anda butuhkan, dan kemudian menyingkir. Saya tidak berpikir menerapkan string kata kunci apa pun cenderung untuk memecahkan masalah memiliki tim yang buruk.

(Jika Anda belum menemukan dari atas, saya bukan penggemar "Capitol-A Agile" setidaknya. Di sisi lain, saya tidak berpikir itu mendorong koboi juga.)

5
TM.

Agile ketika dilakukan dengan benar harus memiliki efek mengekang dalam lead teknis "koboi" dan "pahlawan" programmer. Jika Anda tidak mengamati efek ini, itu mungkin pertanda bahwa ada sesuatu yang penting yang hilang dari implementasi tangkas Anda.

Saya ingin menambahkan bahwa "Agile" benar-benar sebuah antarmuka (saya menggunakan metafora berorientasi objek di sini) dan Anda tidak dapat membuat instantiate. Jika implementasi konkret Anda adalah XP , maka Anda harus mengikuti banyak praktik teknis dengan banyak disiplin, yang menyisakan sedikit ruang untuk pemrograman koboi. Kemungkinan lain adalah bahwa kerja tim dari tim yang terorganisir dengan baik --- Scrum akan menyimpannya.

3
azheglov

Coder koboi juga cenderung menulis kode yang tidak terlalu bisa diuji, dan mereka cenderung tidak suka menulis tes. Saya pikir memiliki semua orang yang melakukan TDD dapat membantu memerintah dalam sikap koboi dan membuat pengembang berpikir tentang arsitektur sedikit lebih. Tidak ada metodologi yang sempurna, tentu saja.

3
Matt H

Saya saat ini bekerja di sebuah toko di mana ini terjadi, kecuali itu lebih berkaitan dengan budaya organisasi daripada dengan koboi individu.

Organisasi selalu beroperasi dengan pendekatan "Agile informal" yang relatif longgar. Saya tidak akan mengatakan itu benar-benar Agile, ini lebih "Agile dalam nama", tetapi hanya metodologi yang tidak ada dalam praktiknya. Tim yang berbeda beroperasi secara berbeda, tetapi karena budaya organisasi secara keseluruhan tidak memiliki metodologi di tempat selain dari proses "Agile in name only" yang sangat longgar - ini secara keseluruhan bersifat koboi dan kacau-balau - terutama dalam integrasi (dan ada banyak yang ).

Moral dari cerita ini adalah - Ya, ini memang terjadi. Jika saya mencari pekerjaan saat ini, saya akan sangat berhati-hati dengan ini. Jika sebuah toko mengklaim sebagai Agile - Saya akan mengajukan beberapa pertanyaan yang cukup sulit dalam wawancara untuk memastikan bahwa lebih dari sekadar keliru Agile benar-benar diikuti.

3
Bobby Tables

Saya menemukan bahwa pengguna hanya dapat memberi kami umpan balik begitu mereka memiliki aplikasi yang dapat mereka gunakan, layar tempat mereka dapat memasukkan data. Hanya kemudian, mereka benar-benar memahami apa yang kami coba katakan dalam dokumen persyaratan (bahwa klien menandatangani tetapi semua orang memiliki versi sendiri artinya). Jika ini bukan pengembangan tangkas, itu akan menjadi proyek air terjun melebihi anggaran tetapi aplikasi akan berubah setelah Anda mengirimkannya. Versi pertama Anda tidak lebih dari prototipe bagi pengguna untuk mendiskusikan apa yang seharusnya menjadi persyaratan. Jadi saya lebih suka menyebutnya gesit daripada melebihi anggaran.

2
Veronica Buitron

Saya pikir itu benar, di beberapa lingkungan Agile digunakan sebagai alasan untuk tidak disiplin. Masalah sebenarnya adalah kita tidak tahu mengapa kita memiliki metodologi. Secara pribadi, saya merasa metodologi adalah masalah arsitektur dalam arti bahwa arsitektur sistem seharusnya menangani non-fungsional, atribut kualitas, metodologi harus mengatasi beberapa atribut yang sama (rawatan, pengembangan produktivitas, transfer pengetahuan, et al.)

Melihat metodologi sebagai kontrol untuk atribut proses menyiratkan beberapa hal: 1) tanpa metrik kita tidak dapat membandingkan efektivitas satu metodologi dengan yang lain, 2) keputusan aktif perlu dibuat tentang atribut apa yang penting (waktu pengiriman vs kode transfer kualitas vs pengetahuan).

Tanpa memiliki metrik dan tujuan yang nyata, kami hanya memilih metodologi sebagai "bulu ajaib" kami yang jika kami pegang erat-erat, kami akan dapat memberikan perangkat lunak.

Sekarang nay-sayers dari Agile, XP, Scrum, dll berbicara tentang kerapuhan dari kategori metodologi tertentu. Argumennya adalah: mengapa menggunakan metodologi yang dapat disabotase oleh satu orang yang kurang disiplin untuk mengikuti semua aturan? Pertanyaannya adalah yang valid; Namun, itu adalah gejalanya, bukan penyebabnya. Jika set metrik proses yang akurat dan bermakna (itulah bagian yang sulit) didefinisikan, diuji, dan umpan balik tepat waktu diberikan, saya pikir kita akan menemukan metodologi tertentu tidak ada hubungannya dengan kesuksesan. (Berbicara secara anekdot, saya telah melihat proyek yang sukses menggunakan berbagai metodologi dan dua kali lebih banyak gagal menggunakan metodologi yang sama)

Jadi apa metriknya? Mereka berbeda dari proyek ke proyek, tim ke tim, dan waktu ke waktu. Berguna untuk ketika jadwal pengiriman penting, yang saya pribadi gunakan adalah keterampilan estimasi dan kualitas. Sebagian besar pengembang dapat secara akurat memperkirakan tugas yang panjang satu minggu atau kurang. Jadi satu pendekatan adalah untuk membagi proyek menjadi tugas satu minggu pengembang dan melacak siapa yang membuat estimasi. Seiring berjalannya proyek, mereka dapat mengubah estimasi mereka. Setelah tugas selesai, jika dimatikan lebih dari 10% (1/2 hari) kami memperlakukan ini sama seperti bug - kami mengidentifikasi mengapa perkiraan tidak aktif (yaitu tabel basis data tidak dipertimbangkan), identifikasi tindakan korektif (yaitu melibatkan DBA dalam estimasi), dan kemudian melanjutkan. Dengan menggunakan informasi ini kami dapat membuat metrik seperti # bug estimasi per minggu, # bug per pengembang, # bug per KLOC, # bug per pengembang-KLOC, dll. Mem-posting angka-angka ini di tim wiki memberikan tekanan sosial yang serius dan dari perspektif manajerial, setelah beberapa minggu, Anda dapat menghasilkan model prediksi minggu pengembangan berikutnya.

Terus? Saat itulah metodologi masuk - jika Anda memiliki model prediktif yang gagal memenuhi kualitas proses, Anda dapat memilih untuk menambah atau menghapus beberapa aspek metodologi dan melihat bagaimana itu mempengaruhi model Anda. Memang, tidak ada yang mau bermain dengan proses pengembangan karena takut gagal, tetapi kami sudah gagal pada tingkat yang tinggi dan dapat diprediksi secara konsisten. Dengan membuat perubahan individu dan mengukur hasilnya, Anda mungkin menemukan bahwa Agile adalah metodologi yang sempurna untuk tim Anda, tetapi Anda bisa dengan mudah menemukan RUP, air terjun, atau sekadar kumpulan praktik terbaik untuk menjadi ideal.

Jadi saran saya adalah jangan khawatir tentang apa yang kita sebut proses, lakukan pemeriksaan yang relevan dengan tujuan proses pengembangan kita, dan bereksperimen dengan berbagai teknik untuk meningkatkan proses itu.

2
TEC

Cowboy coders bagus karena mereka suka menyelesaikan sesuatu dengan cepat. Mereka sering tidak peduli tentang masalah gambaran besar atau kualitas kode, itulah sebabnya "koboi pembuat kode" sering merupakan julukan. Metode mereka mengurangi risiko biaya peluang dari pengiriman proyek yang terlambat.

Coders non-koboi suka melakukan pekerjaan mereka dengan cara yang aman, disiplin, dan teratur. Mereka suka membangunnya dengan benar dan membangunnya sekali. Mereka dikenal untuk selamanya mengumpulkan informasi, mempertimbangkan bagaimana, memproduksi dokumen besar yang tidak dibaca oleh siapa pun, dan mengirimkan sistem terlambat atau sangat terlambat. Metode mereka mencoba mengurangi risiko perangkat lunak berkualitas buruk.

Kecemerlangan metodologi Agile adalah bahwa mereka memanfaatkan kekuatan kedua jenis coders dengan memaksa iterasi kerja yang dibatasi waktu singkat yang meminta coder untuk menghasilkan karya kecil berkualitas tinggi dengan cepat. Dan setiap iterasi mengurangi risiko biaya peluang dari keterlambatan pengiriman dan risiko kualitas perangkat lunak yang buruk.

1
Jay Godse

Ini lucu bagaimana tidak ada yang menganggap diri mereka sebagai coder koboi. Saya bertaruh banyak dari poster itu atau telah menjadi satu;)

1
user5206

Saya akan duduk di sini dengan spesifikasi tingkat tinggi yang bagus dan tidak harus mengunjungi kembali layar dan fungsionalitas yang sama setiap hari sebagai sesuatu yang baru muncul atau lebih dan karena itu tidak memikirkan hal itu.

Itu tampaknya cocok dengan pengalaman rekan saya tentang proyek "lincah" yang dia jalani (saya sendiri belum pernah melakukannya): dia diminta untuk menulis sepotong kode untuk beberapa spesifikasi, kemudian sama seperti dia selesai mengujinya dan siap untuk pindah pada persyaratan baru muncul yang mengharuskan dia untuk mengubahnya dan mengujinya kembali. Dia merasa frustasi.

Saya tidak memukul tangkas, saya curiga tim tidak melakukan tangkas dengan benar - tetapi seperti yang Anda katakan, istilah "gesit" kadang-kadang dapat digunakan oleh koboi untuk meyakinkan manajemen yang runcing bahwa desain setengah matang lebih positif daripada negatif .

1
Tony Andrews

Alasan sementara lincah adalah sangat sedikit menekankan pada desain/spesifikasi di muka bukan hanya karena persyaratan dapat berubah. Alasan yang lebih dalam adalah bahwa bahkan ketika persyaratan stabil, spesifikasi cenderung:

  • salah - gagal menangkap persyaratan.

  • tidak konsisten - penuh dengan kontradiksi karena mengandung cukup banyak informasi sehingga mustahil bagi penulis/pembaca untuk menangkapnya.

  • terlepas - mereka tidak memasukkan umpan balik yang berharga dari sistem yang berjalan (meskipun mengalami degenerasi).

0
Itay