Agile Adalah Rigor Mortis sebagai Agama Negeri Perisian

Sudah menjadi perkara biasa dalam dunia kejuruteraan perisian untuk mendengar pengisytiharan kematian Agile daripada orang yang mempunyai kepentingan dalam metodologi, mendakwa bahawa melainkan kita menunjukkan kepercayaan yang lebih besar, ia akan hilang, dan dalam kes di mana ia gagal, ia hanya belum dilaksanakan dengan betul - mengingatkan dakwaan lain berikutan kekeliruan "tiada orang Scotland sebenar" seperti "komunis sebenar tidak pernah dicuba."

Walaupun kehadirannya dalam malapetaka perisian yang berbeza-beza daripada keguguran keadilan kepada bencana perisian penerbangan, realitinya Agile telah memegang jawatan sebagai agama profesional kejuruteraan perisian.

Keadaan ini telah berubah dengan ketara sejak beberapa bulan kebelakangan ini. Sejak saya bekerja pada penyelidikan 6 bulan yang lalu menunjukkan bahawa projek perisian Agile mempunyai kadar kegagalan 268% lebih tinggi , banyak penyelidikan telah dikeluarkan untuk menyokong kerja ini.

Seperti komunisme atau penyembuhan iman, fantasi keagungan yang baik secara universal, tetapi tidak realistik, penyelesaian boleh menyelesaikan semua masalah kita akan sentiasa menarik bagi sesetengah orang walaupun terdapat bukti - tetapi apa yang kini secara asasnya berubah ialah wujud persetujuan termaklum sama ada untuk mengikuti Agile atau melakukan sesuatu yang berbeza. '

(Tidak syak lagi, berita antarabangsa yang dikaitkan dengan kemas kini perisian yang gagal CrowdStrike sudah tentu membantu memahami perkara yang saya cuba buat.)

Walaupun tahap yang menjijikkan sesetengah dalam komuniti Agile cuba untuk menutup mulut saya daripada bercakap tentang Agile, adalah penting untuk bersikap murah hati dalam kemenangan supaya saya tidak akan cuba untuk mereliti hujah di sini - sebaliknya, saya rasa ia berbaloi untuk membincangkan perkembangan terkini dan jalan ke hadapan, 6 bulan lagi.

Penyelidikan DORA Google Menghidupkan Agile

JL Partners, yang saya perintahkan untuk menjalankan penyelidikan kadar kegagalan Agile, telah mengalami fenomena yang luar biasa beberapa bulan lalu. Tidak seperti kebanyakan orang lain yang menjalankan penyelidikan dengan akauntabiliti terhad, mereka kerap menguji model mereka dengan meramalkan pilihan raya. Apabila datang ke pilihan raya UK, mereka mendapati diri mereka menghasilkan antara ramalan yang paling tepat . Perkara yang lebih luar biasa apabila ia datang kepada pilihan raya AS seperti yang dilaporkan oleh Politico :

… Rakan Kongsi JL mungkin akan menjadi antara yang paling tepat dalam ramalan pra-pilihan raya terakhir mereka. Model terakhir firma itu hanyalah satu daripada dua yang meramalkan kemenangan Trump dan ia juga mengunjurkan beliau memenangi Kolej Pilihan Raya 287-251 — margin kemenangan Trump tertinggi yang diunjurkan daripada mana-mana tinjauan pendapat. Ia juga merupakan salah satu daripada beberapa tinjauan pendapat yang meramalkan Trump akan memenangi undi popular.

Selain itu, penyelidikan daripada RAND Corporation yang pada mulanya dijalankan untuk Jabatan Pertahanan AS mendapati bahawa pembangunan AI dan tangkas tidak bergaul dengan baik . Tambahan pula, Synodus (pembekal teknologi global yang membekalkan (syarikat Fortune 500 seperti BOC Aviation, KPMG dan Unilever) melaporkan bahawa dengan berpindah dari Agile , mereka mendapati mereka menyampaikan projek 2-3x lebih pantas dan melaporkan syarikat penerbangan terkemuka menyelamatkan 63 % daripada kos pembangunan mereka.

Ini walaupun pada hakikatnya kelajuan dan kos secara tradisinya adalah metrik yang dikaitkan dengan Agile dan LEAN, manakala pendekatan Kejuruteraan Impak memfokuskan pada Impak sebagai metrik utama.

Akhirnya, seperti yang ditulis oleh Colm Campbell dalam artikel " P-Hacking with Dinosaurs ," dakwaan yang dikemukakan oleh "Agile Mafia" sebagai tindak balas kepada kajian kadar kegagalan Agile telah disangkal secara menyeluruh, hanya meninggalkan serangan peribadi yang menyedihkan.

Walau bagaimanapun, mungkin salah satu bidang penyelidikan sokongan yang paling mengejutkan datang daripada pasukan DORA Google. DORA sendiri mendapati akarnya dalam pergerakan DevOps, yang dengan sendirinya adalah makhluk Agile. Laporan State of DevOps tahunan mereka untuk 2024 tidak menerima liputan yang meluas pada tahun ini memandangkan masa siaran yang telah digunakan untuk penyelidikan Agile, tetapi menarik untuk melihat mereka juga membelakangkan Agile.

Sekarang, saya harus ambil perhatian bahawa saya telah mengkritik metodologi pasukan DORA (sejak saya mengubah fikiran saya tentang Agile, DevOps, dll.) kerana metrik utama yang mereka gunakan untuk mengukur sesuatu adalah tertumpu pada kelajuan penghantaran ( yang kita tahu adalah apa yang pengguna mahukan ), tetapi hakikatnya mereka melihat ini walaupun menggunakan pendekatan mereka menunjukkan sesuatu yang lebih mendalam berlaku di sini.

Pada halaman 64 State of DevOps Report 2024, mereka mendakwa:

'Manifesto Agile menyokong "perisian yang berfungsi dalam dokumentasi komprehensif". Kami terus mendapati, bagaimanapun, dokumentasi kualiti adalah komponen utama perisian yang berfungsi.'

Tambahan pula, pada halaman 82, mereka kelihatan membelakangkan DevOps itu sendiri:

'Kami komited kepada prinsip asas yang sentiasa menjadi sebahagian daripada pergerakan DevOps: budaya, kerjasama, automasi, pembelajaran dan penggunaan teknologi untuk mencapai matlamat perniagaan. Komuniti dan penyelidikan kami mendapat manfaat daripada perspektif pelbagai peranan, termasuk orang yang mungkin tidak mengaitkan dengan label "DevOps". Anda sepatutnya menjangkakan untuk melihat istilah "DevOps" beralih daripada tumpuan.'

Saya masih mempunyai masalah dengan metodologi penyelidikan mereka; titik akhir yang digunakan untuk mengukur kejayaan tertumpu pada kelajuan, dan lebih-lebih lagi, mereka terus menyokong kepimpinan transformasi walaupun penyelidikan psikologi dalam bidang ini mempersoalkan pendekatan tersebut.

Pada peringkat manusia, nampaknya amat kasar untuk memberi tumpuan yang begitu berat pada usaha mengubah organisasi dan orang ramai tanpa persetujuan termaklum mereka sementara juga gagal untuk mengiktiraf bagaimana selalunya tiada sumber pembelajaran yang lebih baik daripada kesilapan kita sendiri (setakat kita mempunyai maklumat persetujuan untuk membuatnya), kritikan utama saya terhadap kerja seperti Projek Pheonix dan Projek Unicorn .

Walau bagaimanapun, adalah luar biasa untuk melihat peningkatan sokongan untuk Kejuruteraan Impak terhadap metrik Agile dan DevOps tradisional.

Scrum, TDD dan Corak Reka Bentuk

Apabila The Register menemu bual saya beberapa bulan lalu dalam artikel " Studi backer: Catastrophic take on Agile terlalu menekankan ciri baharu " , saya tidak merahsiakan tiga faktor yang saya hadapi dalam pendekatan moden untuk Agile, DevOps dan transformasi digital:

1. Pendekatan Agile yang menafikan keperluan, walaupun berlaku bencana termasuk skandal Pejabat Pos dan nahas Boeing 737 Max 8 .

   
   

2. Pelaksanaan DevOps yang mengutamakan kelajuan penyampaian ciri baharu dan pulih daripada isu berbanding mencegah masalah sejak awal - walaupun penyelidikan menunjukkan pangkat awam mendapat ciri terkini secepat mungkin sebagaiperkara paling tidak penting bagi mereka apabila menggunakan sistem komputer, dengan keselamatan data, ketepatan data dan tiada pepijat yang serius menjadi faktor yang paling penting.

   
   

3. Percubaan pada transformasi organisasi dari bawah ke atas tanpa mendapatkan persetujuan termaklum, mengabaikan kepentingan membenarkan orang ramai belajar daripada kesilapan mereka sendiri yang mereka mempunyai persetujuan termaklum untuk dibuat - dengan program sedemikian dijual sebagai kejayaan yang pasti berakhir dengan kesengsaraan dan kegagalan yang penuh tekanan.

   
   

Semasa saya mula menyelidik bencana perisian dan komputer pembunuh (seperti yang dilaporkan dalam Forbes pada bulan April ), ini adalah tiga faktor yang saya mula menghadapi cabaran moral yang semakin meningkat. Saya tidak mempunyai masalah sebenar dengan pendekatan pembangunan perisian atau teknik pengurusan projek yang berbeza kerana saya tidak melihat pautan yang sama kepada kajian kes bencana yang saya siasat. Saya tidak merasakan keperluan untuk menyatakan pandangan peribadi saya sebagai seorang jurutera berkenaan dengan perkara-perkara lain ini.

Namun begitu, adalah menarik untuk melihat jejari letupan telah melebar melangkaui tiga kawasan awal ini kepada pendekatan lain yang dianjurkan oleh pengarang bersama Manifesto Agile seperti Scrum, Pembangunan Terpacu Ujian (TDD), Pengaturcaraan Berorientasikan Objek (OOP) dan Reka Bentuk. Corak (cth, lihat siaran LinkedIn Soumen Sarkar pada Corak Reka Bentuk ).

Saya mempunyai sedikit untuk menambah dalam bidang ini. Walau bagaimanapun, saya tertanya-tanya sama ada pengarang bersama Agile tidak berjuang keras menentang kematiannya sebagai agama jika komuniti kejuruteraan perisian akan lebih baik terhadap idea mereka yang lain. Persoalannya kini dipertikaikan memandangkan status agama Agile adalah rigor mortis dan segala-galanya kelihatan untuk diperebutkan: OOP, corak reka bentuk, TDD, dll.

Ke Arah Kesedaran Penghindaran Kehilangan

Memandangkan telah menghabiskan sebahagian besar dalam beberapa bulan kebelakangan ini sebagai berita muka depan pelbagai penerbitan teknologi yang bercakap tentang Agile dan dibincangkan secara meluas di kalangan masyarakat secara amnya, mungkin tidak menghairankan jika terdapat beberapa pertemuan yang pelik. Walau bagaimanapun, sebahagian besarnya, mereka telah menjadi pertemuan yang sangat menyenangkan dengan orang yang datang kepada saya di khalayak ramai dan secara rawak terlibat dalam perbincangan tentang Agile.

Namun, ada satu pertemuan yang meninggalkan kesan yang mendalam kepada saya. Beberapa minggu yang lalu, saya akan pergi ke Parlimen UK untuk menangani penggubal dasar mengenai pelbagai skandal teknologi yang sedang saya usahakan untuk menyiasat. Saya sendiri tidak pernah begitu suka memegang kuasa, dan saya selalu merasa hairan bahawa di bar persendirian di Parlimen, mesti ada tanda yang mengingatkan individu supaya tidak menyalahgunakan kuasa mereka apabila mabuk.

Bagaimanapun, memberi ceramah ini, saya bukan sahaja berpakaian kemas dan lebih kemas daripada biasa, tetapi saya juga berada di hadapan khalayak yang bersimpati, diapit oleh seorang Ahli Parlimen dan seorang rakan yang kebetulan merupakan Peguam Raja (peguam kanan yang diberi kuasa. pembezaan oleh raja untuk advokasi yang luar biasa).

Sebaik sahaja saya memberi ceramah dan menjawab beberapa soalan, terdapat seseorang di kalangan penonton yang merupakan pelawat yang mula bercakap tentang Agile (ceramah itu bukan tentang Agile). Berbeza dengan sut tiga helai saya, dia memakai baju bernoda sos tomato dan (tanpa menerangkan secara terperinci) tidak kelihatan rapi mahupun berkaitan politik. Dia mula "Boleh saya beri sedikit maklum balas?"

Apabila dia mula bercakap tentang Agile, saya bertentang mata dengannya secara menyoal, dan dia memandang ke bawah dan berhenti bercakap, hampir seolah-olah dia menyedari dia tidak lagi dalam talian dan sebenarnya berhadapan dengan seseorang dengan kata-katanya. Sebelum saya dapat menjawab, seorang rakan CEO mencelah untuk menjelaskan perkara itu untuk saya.

Pada masa itu, saya sedar saya tidak suka kuasa sehingga satu tahap yang saya tidak sedari setakat ini.

Malangnya, bagi individu ini, nampaknya dia sudah menjadi mangsa mereka yang menjual penyelesaian transformasi pasti yang nampaknya membawa kepada kesukaran dalam hidupnya sendiri. Dalam keadaan ini mengapakah metodologi transformasi ini masih dianjurkan?

Secara lebih luas, mengapa Agile tidak dapat beroperasi di dunia nyata? Dengan komunisme, sekurang-kurangnya kita boleh mengaitkan kegagalan itu dengan ketamakan, jadi apakah psikologi kegagalan Agile? Jawapannya, pada pandangan saya, datang kepada faktor psikologi yang dikenali sebagai loss aversion . Atas permintaan ramai, saya baru-baru ini menulis kertas pracetak mengenai kerja Kejuruteraan Impak dan ia memfokuskan pada peranan kesedaran penghindaran kehilangan boleh bermain dalam mengurangkan kejayaan projek.

Kertas itu, "Jadi Adakah saya Dr. Frankenstein? Atau Adakah Anda Raksasa Sepanjang Masa?”: Mengurangkan Kegagalan Projek Perisian Dengan Metodologi Pembangunan Sedar Kehilangan Kehilangan , menyimpulkan seperti berikut:

Kajian kes telah menunjukkan bahawa bencana perisian boleh menjadi malapetaka apabila masalah tidak ditangani dan sebaliknya ditutup. Faktor psikologi, yang merupakan kunci kepada keengganan kerugian, boleh memberi insentif kepada organisasi untuk melalui jalan ini walaupun akibat yang membawa bencana.

Namun, metodologi perisian secara sejarah mengabaikan faktor psikologi ini, sebaliknya menganggap bahawa manusia akan mahu menangani masalah pada peluang yang paling awal. Penyelidikan terdahulu terhadap pelbagai metodologi telah mendapati keselamatan psikologi untuk membangkitkan dan membincangkan isu menjadi kunci kepada penyampaian perisian yang lebih baik. Walau bagaimanapun, tidak syak lagi optimistik untuk mempercayai perubahan budaya dan psikologi yang ketara itu boleh dicapai dalam semua organisasi. Seperti yang kita dapati, walaupun antara UK dan Amerika Syarikat, keselamatan psikologi kekal sebagai perbezaan terbesar dalam amalan kejuruteraan antara kedua-dua negara.

Dalam kertas ini, kami memberi tumpuan kepada cara yang berbeza ke hadapan. Daripada mencuba untuk mencapai perubahan budaya yang paling mencabar, kami sebaliknya menumpukan pada pendekatan yang lebih pragmatik: mengehadkan pencetus penghindaran kerugian dari awal melalui keperluan yang teguh dan kemudian bertujuan untuk keselamatan psikologi di mana ia diperlukan. Dalam penyelidikan kami, satu-satunya faktor yang kami dapati yang akan meningkatkan kadar kejayaan projek lebih daripada keselamatan psikologi ialah mempunyai keperluan yang jelas dari awal lagi.

Berlawanan dengan hipotesis kami, keputusan yang hanya mempunyai keperluan yang jelas, walaupun apabila ia berubah lewat dalam pembangunan atau tidak sejajar dengan dunia sebenar, nampaknya mempunyai peranan penting dalam kejayaan projek perisian. Ini menunjukkan bahawa mempunyai pintu sebelum permulaan projek untuk membincangkan dan menangani masalah, apabila keengganan kerugian berada pada tahap paling rendah, membolehkan peningkatan terbesar dalam kadar kejayaan.

Lagu Dr. Frankenstein oleh RedHook mengandungi petikan: “Jadi adakah saya Dr. Frankenstein? Atau adakah anda raksasa sepanjang masa?" Untuk projek perisian bencana, kertas kerja ini berpendapat bahawa projek perisian menjadi bencana apabila manusia gagal menangani masalah teknikal skala yang lebih kecil. Metodologi kejuruteraan perisian sedia ada gagal menangani bahawa manusia bukan mesin dan faktor psikologi menghalang keupayaan untuk menangani masalah. Setelah mengenal pasti anakronisme ini dalam metodologi sedia ada, kertas kerja ini membentangkan bagaimana kita boleh bertindak ke atasnya dengan menggunakan keperluan sebelum permulaan projek untuk memberi peluang untuk menangani masalah apabila pengelakan kerugian berada pada tahap paling rendah.