Apa itu Anarki Pengembang?

Saya telah membaca tentang Developer (atau Programmer) Anarchy, yang tampaknya disebut sebagai metodologi pengembangan pasca-Agile. Saya menemukan beberapa sumber di atasnya ( 1 , 2 ) tetapi tampaknya tidak banyak di luar sana.

Saya bertanya-tanya apakah ada yang punya sumber daya yang baik di mana saya bisa mencari tahu lebih banyak tentang itu _ bagaimana menerapkannya, pro dan kontra, perbandingan dengan metodologi lain dll

agile development-process development-methodologies

— Martyn
sumber

Saya belum pernah mendengarnya sebelumnya tapi sepertinya agak bertentangan dengan saya. Mereka mengatakan "... formalitas dan aturan membatasi kreativitas dan produktivitas" tetapi pada saat yang sama mereka mengadakan pertemuan secara reguler (sebagai bagian dari metodologi?). Saya tidak percaya bahwa deskripsi metodologi semacam itu dimulai dengan menetapkan aturan.

— Giorgio

Membaca tentang hal itu untuk pertama kalinya, menurut saya hal itu dilakukan oleh orang atau orang yang hanya memiliki pengalaman dengan Agile setengah-setengah. Karena "Developer Anarchy" ini adalah contoh buku teks "agile done right". Misalnya. tangkas diimplementasikan dengan benar.

— Euforia

Tautan pertama yang Anda kutip tampaknya sudah berisi semua yang Anda cari.

— Michael Borgwardt

Sungguh kata kunci yang indah!

— CesarGon

@CesarGon: Buzzwords lebih mudah ditemukan daripada metodologi yang benar-benar baru. ;-)

— Giorgio

Saya dapat mengarahkan Anda ke pemikiran Alistair Cockburn tentang aspek proyek Agile 'benar' ini:

Salah satu anggota dalam keluarga metodologi Crystal adalah Crystal Clear. Crystal Clear dapat dijelaskan kepada pendengar Level 3 dengan kata-kata berikut:

“Tempatkan 4-6 orang di ruangan dengan workstation dan papan tulis dan akses ke pengguna. Mintalah mereka mengirimkan perangkat lunak yang sudah berjalan dan diuji kepada pengguna setiap satu atau dua bulan, dan jika tidak biarkan mereka sendiri.

Sebenarnya, saya menggambarkan Crystal Clear dalam kata-kata itu kepada sponsor proyek yang cerdas. Dia mengikuti instruksi itu dan melaporkan lima bulan kemudian, "Kami melakukan apa yang Anda katakan, dan itu berhasil!"

Saya mewawancarai ketua tim beberapa bulan kemudian dan laporannya sesingkat instruksi saya:

“Mengikuti saranmu, kami berempat mengambil alih ruang konferensi ini, yang memiliki koneksi jaringan. Kami menyimpannya selama empat bulan, menggambar di papan tulis di sana, mengantarkan perangkat lunak saat kami pergi. Itu bekerja dengan baik. "

itulah yang lincah tentang, dan tampaknya ini adalah pendekatan yang diambil oleh metodologi Anarchy - intinya adalah bahwa, jika Anda telah mengalami cowok , maka Anda dapat memberitahu mereka untuk "turun dan membuatnya bekerja" dan mereka akan melakukan hal itu . (Ini tidak bekerja dengan orang yang kurang berpengalaman, Anda tidak akan membiarkan tim junior melakukannya tanpa setidaknya beberapa pengawasan).

Semua petunjuk tentang lincah yang dibangun selama bertahun-tahun, seperti standup harian dan papan scrum, sesi perawatan produk backlog, pertemuan pra-pertemuan tentang tumpukan produk perencanaan rapat sesi perencanaan perawatan papan scrum .. semua hal proyek kelas berat yang harus dilihat sebagai overhead untuk pengiriman produk yang sukses.

Terlalu banyak hari ini, hal-hal ini dipandang sebagai wajib dan metodologi 'gesit' turun ke dalam sistem yang memiliki lebih banyak proses daripada metode lama!

— gbjbaanb
sumber

"Terlalu banyak hari ini, hal-hal ini dipandang sebagai wajib dan metodologi 'gesit' turun ke dalam sistem yang memiliki lebih banyak proses daripada metode lama!": Anda mencapai titik penting (+1). Saya telah bekerja dengan SCRUM dalam tim pengembang yang berpengalaman dan perasaan kami, setelah dua tahun adalah bahwa ... kami lebih gesit sebelumnya, ketika kami tidak memiliki pertemuan harian (kami biasa bertemu dua kali seminggu) dan banyak kegiatan lainnya terjadi "ketika tim memutuskan mereka dibutuhkan" alih-alih "ketika metodologi menentukan mereka".

— Giorgio

+1. Pada akhirnya, saya pikir metodologi ini adalah indikasi dari siklus yang berkelanjutan: metodologi berat gagal berulang kali, (beberapa) orang menyadari bahwa programmer cukup pintar untuk menangani hal-hal, mengurangi proses, dan umumnya hal-hal bekerja - tetapi proses ringan dicoba dengan tim yang miskin atau tidak berpengalaman, itu gagal atau tidak memenuhi perkiraan, proses ditambahkan untuk meningkatkan "kepastian" dan "kepastian," dan siklus berlanjut.

— asthasr

Gahhh ... siklus itu terdengar akurat dan menyedihkan.

— Graham

"Tim adalah pengembang berbakat yang bekerja di perusahaan yang dipenuhi pengembang berbakat. Hampir semua metodologi yang Anda pikirkan akan bekerja dengan orang-orang ini."

— AakashM

@syrion: Anda mungkin benar. Saya membaca di suatu tempat bahwa praktik lincah bekerja untuk programmer yang berpengalaman. Kemudian programmer berpengalaman seperti itu yang telah melatih tim yang tidak berpengalaman harus menuliskan aturan untuk mereka (karena pelatihan berkelanjutan biaya banyak dan lebih baik untuk memiliki beberapa aturan yang ditulis dalam buku). Dengan cara ini metodologi baru seperti SCRUM dan sejenisnya dikembangkan: sehingga orang sekarang dapat menjual buku atau sertifikasi. Tapi semangat lincah yang sebenarnya adalah menerapkan akal sehat Anda sendiri, bukan aturan yang ditulis oleh orang lain. Aturan adalah pedoman tetapi dianggap oleh banyak orang seperti agama.

— Giorgio