“Semuanya beracun, semuanya obat; keduanya ditentukan oleh takaran. ”
Paracelsus
Merupakan kebiasaan untuk menghitung sejarah
Agile dari Februari 2001, ketika dokumen yang agak aneh lahir -
Agile Manifesto . Pada umumnya, teks dokumen terdiri dari bukti filosofis (misalnya, "kesederhanaan - seni tidak melakukan pekerjaan yang tidak perlu") dan pernyataan kontroversial (misalnya, "persyaratan teknis, desain, dan arsitektur terbaik diperoleh dari tim yang dikelola sendiri"). Tetapi dokumen ini aneh bukan pada isinya (Anda tidak pernah tahu apa yang mungkin terlintas dalam pikiran di sebuah resor ski), tetapi dalam sifat epik dari perubahan selanjutnya dalam industri pengembangan perangkat lunak. Dalam waktu singkat, banyak teknik muncul yang menerapkan metodologi pengembangan "fleksibel", yang dengan khidmat berbaris di seluruh dunia, menangkap pikiran Kontraktor dan dompet Pelanggan. Mahir menyajikan gerakan ini sebagai semacam pil ajaib yang memutuskan segalanya. Itu sampai pada titik bahwa
donor mulia seorang programmer jujur telah menjadi tidak senonoh untuk mengakui keterlibatan dalam pengembangan perangkat lunak sesuai dengan
orientasi tradisional metodologi. Mari kita mencoba memahami penyebab dan konsekuensi dari fenomena, menggunakan
Scrum sebagai manifestasi Agile yang paling umum.
Pertama, mari kita coba untuk memahami apa yang benar-benar baru yang kita dapatkan di bungkus Agile pada umumnya dan Scrum pada khususnya.
Scrum di Mesir kuno
Saya akan mengambil kebebasan menyatakan bahwa metodologi yang fleksibel pada umumnya, dan metodologi Scrum pada khususnya, selalu ada, meskipun mereka tidak dipanggil. Mereka tidak dipanggil sama sekali, tetapi hanya cara paling alami dan efektif untuk melakukan proyek internal mereka (kata kuncinya di sini adalah "internal").
Misalnya, firaun Mesir kuno berencana membangun piramida dan ... itu dimulai. Membahas gagasan itu dengan para imam (pemangku kepentingan) dan menugaskan kepala pelayannya untuk bertanggung jawab atas proyek (pemilik produk). Petugas menemukan tukang batu yang kompeten (ahli scrum). Si tukang batu mempekerjakan asisten (tim scrum), dan mereka pergi ke pasar budak dan mencetak budak (alat kerja: PC, server, perangkat lunak untuk pengembangan, dll.).
Karena firaun memerintahkan laporan bulanan kepadanya tentang kemajuan konstruksi, tukang batu (dengan asisten) mulai melakukan demonstrasi konstruksi bulanan (demo) untuk kepala pelayan. Selama pertunjukan, tidak hanya apa yang sudah dilakukan (retrospektif) dibahas, tetapi juga rencana untuk bulan berikutnya (sprint) disusun. Agar tidak ketinggalan apa-apa, sang cupbearer mendiskusikan kisah-kisah pengguna dengan para pendeta selama sebulan dan menulisnya dalam perkamen khusus (jaminan), dari mana Daftar Keinginan masuk ke dalam rencana untuk bulan berikutnya. Baik dan sebagainya. Saya tidak tahu seperti apa stiker, papan scrum, dan diagram burndown. Setiap pemimpin yang kompeten memilih alat yang paling nyaman untuk mengelola dan memantau proyek. Detailnya tidak penting di sini, yang terpenting adalah tekniknya bekerja.
Yaitu Saya pikir semua manajer selalu menggunakan teknik yang fleksibel untuk menciptakan produk internal mereka (dengan risiko dan risiko sendiri) karena:
- cukup kompeten untuk mendesain hasil akhir;
- cukup kompeten untuk mengendalikan proses;
- memiliki kekuatan yang cukup atas peserta proses bawahan;
- rasio istilah, biaya dan kualitas pekerjaan bukanlah dogma bagi mereka dan dapat direvisi jika perlu (karena “ia adalah tuannya sendiri”);
- dan yang paling penting, hasil akhir dan proses mencapainya ada di tangan yang sama dan mengejar satu kepentingan komersial.
Tetapi untuk Pelanggan eksternal, tidak ada item dalam daftar ini yang berlaku; oleh karena itu, untuk proyek eksternal (kebiasaan), teknik fleksibel tidak pernah digunakan (pengecualian hanya mengkonfirmasi aturan). Lagipula, orang-orangnya sederhana dan tidak toleran, karena tenggat waktu dan perkiraan berlebihan yang mencolok, mereka bisa saja memperpendek kepala mereka.
Scrum saat ini
Satu-satunya kebaruan Scrum modern adalah fakta penggunaannya untuk implementasi proyek eksternal (khusus). Mencoba untuk tidak menonjolkan sisi masalah ini, karena menarik tali dapat menarik keluar motivasi nyata dari pelaku pasar. Bahkan, manifest Agile dan semua argumen Scrum adalah propaganda murni dari kepentingan Kontraktor, demi kesopanan, terselubung di bawah perjuangan untuk semua yang baik melawan semua yang buruk. Itulah jenius solusi, yang memungkinkan kami meyakinkan Pelanggan untuk mengorbankan hasilnya demi proses!
Jadi, apa yang berubah jika pemilik produk adalah karyawan perusahaan lain, dan bukan perusahaannya sendiri? Perbedaan utama adalah bahwa hasil akhir dan proses pencapaiannya sekarang berada di sisi yang berbeda dari "barikade" dan masing-masing pihak hanya mengejar kepentingan komersialnya sendiri. Hasilnya penting bagi pelanggan, dan prosesnya penting bagi Kontraktor. Tidak mungkin sebaliknya - setelah semua, "bukan masalah pribadi, ini hanya bisnis."
Agile bermanfaat bagi para pemain pasar TI, karena memberi mereka peluang:
- menghasilkan uang dari proses dan tidak bertanggung jawab atas hasilnya;
- mengurangi biaya personel manajemen yang kompeten (mereka mahal, tetapi Anda tidak perlu merancang apa pun sekarang dan Anda tidak perlu menulis TK, dan prosesnya sekarang mengendalikan pemilik produk pelanggan).
Dan karena ini menguntungkan, tepat di depan mata kita, tim pemrograman dengan tulang punggung profesional yang sangat memenuhi syarat dan berpikiran sistem dapat berubah menjadi peternakan penyandi tangan tengah yang disewa.
Cobalah untuk menempatkan diri Anda di tempat seseorang yang menyewa tim pembangun untuk memperbaiki apartemennya dan mencoba untuk mendapatkan syarat dan biaya perbaikan dari ketua tim, dan sebagai tanggapan ia mendengar:
- kami adalah orang-orang kreatif, jadi kami akan bekerja "sebagaimana mestinya", tetapi Anda membayar untuk setiap jam kerja tim dan materi;
- kami tidak akan melakukan proyek dan rencana bersama, kami akan mencari tahu di sepanjang jalan (jika kami melakukan sesuatu yang salah, maka kami akan mengulanginya untuk waktu yang Anda bayar dan bahan tambahan);
- kami akan menunjukkan hasil pekerjaan kami setiap dua minggu dan berbicara tentang masalah kami, dan kemudian bersama-sama kami akan merencanakan dua minggu ke depan.
Tidak mungkin ada orang yang akan setuju dengan tawaran seperti itu, dan pelanggan karyawan TI setuju! Itulah yang dilakukan propaganda pemberi kehidupan!
Tidak hanya pelanggan diyakinkan untuk menyetujui tanggal dan biaya yang tidak dapat diprediksi, mereka juga mengalihkan semua tanggung jawab atas kegagalan itu. Sebagai aturan, kualifikasi Pelanggan tidak mengizinkan formalisasi persyaratan untuk hasil akhir dan mengendalikan proses secara profesional. Oleh karena itu, selalu dapat dikacaukan dan dialihkan (jika tidak ada TK umum) untuk menyelesaikan banyak masalah sekunder (yang paling sering muncul karena kurangnya perencanaan jangka panjang).
Konsekuensi Ibadah yang Cerdas
Tidakkah Anda berpikir bahwa kualitas produk perangkat lunak turun sebanding dengan distribusi Agile yang tersebar luas di industri? Dari mana kualitas berasal jika seluruh proses dipertajam dengan memecahkan masalah dengan cara paling sederhana dan tercepat? Dan berpikir ke depan secara resmi dilarang oleh metodologi!
Tidakkah Anda berpikir bahwa produk perangkat lunak semakin berubah menjadi "selimut tambal sulam" ketika Anda terkejut melihat bahwa bagian yang berbeda dari perangkat lunak yang sama tampaknya dibuat oleh orang yang sama sekali berbeda? Dan bahkan pada satu layar program, gaya desain yang berbeda, pendekatan ergonomis yang berbeda, dan algoritme yang berbeda untuk fungsi kontrol yang sama dapat digabungkan. Tetapi tidak ada Panduan Gaya dan TK untuk produk, jadi siapa pun yang lebih akrab akan melakukannya! Dan staf QA, seperti orang lain, dijepit oleh tenggat waktu sprint.
Tentang apa semua ini?
Dari semua hal di atas, sepertinya saya pembenci Agile yang bersemangat. Tapi ini sama sekali tidak! Dan saya tidak mencoba menyinggung siapa pun! Dia hanya mencoba mengilustrasikan kata-kata Paracelsus agung dengan lebih jelas dalam epigraf.
Metodologi yang fleksibel sangat cocok untuk proyek-proyek internal kecil dan bahkan menengah. Ukuran proyek hanya dibatasi oleh kemampuan seorang pemimpin tertentu untuk "tidak kehilangan hutan di balik pohon," kemampuan untuk mengingat semua detail dan hasil yang diinginkan tanpa mensistematisasikannya "di atas kertas".
Metodologi yang fleksibel secara terbatas cocok untuk proyek eksternal. Dalam hal ini, persyaratan yang sama berlaku untuk pemilik produk Pelanggan untuk manajer proyek internal, yaitu, orang ini harus menjadi profesional TI nyata, dan bukan sekretaris yang menarik beban sementara waktu. Ia harus dapat memverifikasi kualifikasi tim yang disewa dan terus-menerus memantau kualitas produk yang dikembangkan. Selain itu, produk yang dikembangkan harus memungkinkan (dalam kasus force majeure) penggantian tim pengembangan. Hanya dalam kasus ini kita dapat berharap bahwa itu tidak akan "menghina dan menyakitkan selama bertahun-tahun tanpa tujuan".
Seperti yang Anda lihat, Agile memiliki tempat di bawah sinar matahari, tetapi sangat terbatas di bidang pengembangan TI kontrak. Apa yang harus dilakukan jika proyek Anda tidak masuk dalam kategori Agile-cocok?
Apakah tidak mencurigakan bagi Anda bahwa metodologi yang fleksibel belum berakar di mana pun selain pengembangan perangkat lunak kontrak? Ya, mereka tidak melakukan kapal selam, pesawat, atau mobil di Scrum. Kebijaksanaan nenek moyang kita mengajarkan kita bahwa bahkan rumah anjing biasa tidak dapat disatukan tanpa tahap desain (sketsa pensil dengan dimensi) dan persiapan Kerangka Acuan (daftar bahan dan alat). Segala sesuatu yang Anda lihat di sekitar (dari bangku ke pesawat ruang angkasa) telah dibuat sesuai dengan
"air terjun" tua yang baik. Kenapa kamu tidak melakukan hal yang sama? Dan ingat - semuanya akan baik-baik saja!
PS
Semua yang dikatakan berdasarkan pada pengalaman pribadi saya (19 tahun) dalam pengembangan web kontrak menggunakan pendekatan tradisional (Waterfall) dan progresif (Scrum). Motif untuk menulis artikel itu adalah kesedihan moral dari kontemplasi "keajaiban teknologi permusuhan" berikutnya, yang disatukan di bawah perjanjian Frankenstein yang agung untuk satu perusahaan Barat yang disegani.
