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 - mengingatkan dakwaan lain berikutan kekeliruan "tiada orang Scotland sebenar" seperti "komunis sebenar tidak pernah dicuba." belum dilaksanakan dengan betul Walaupun yang berbeza-beza daripada keguguran keadilan kepada bencana perisian penerbangan, realitinya Agile telah memegang jawatan sebagai agama profesional kejuruteraan perisian. kehadirannya dalam malapetaka perisian Keadaan ini telah berubah dengan ketara sejak beberapa bulan kebelakangan ini. Sejak saya bekerja pada 6 bulan yang lalu menunjukkan bahawa projek perisian Agile mempunyai kadar , banyak penyelidikan telah dikeluarkan untuk menyokong kerja ini. penyelidikan kegagalan 268% lebih tinggi 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 sudah tentu membantu memahami perkara yang saya cuba buat.) kemas kini perisian yang gagal CrowdStrike 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 . Perkara yang lebih luar biasa apabila ia datang kepada pilihan raya AS : antara ramalan yang paling tepat 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 . Tambahan pula, Synodus (pembekal teknologi global yang membekalkan (syarikat Fortune 500 seperti BOC Aviation, KPMG dan Unilever) melaporkan bahawa , mereka mendapati mereka menyampaikan projek 2-3x lebih pantas dan melaporkan syarikat penerbangan terkemuka menyelamatkan 63 % daripada kos pembangunan mereka. pembangunan AI dan tangkas tidak bergaul dengan baik dengan berpindah dari Agile 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 " ," dakwaan yang dikemukakan oleh "Agile Mafia" sebagai tindak balas kepada kajian kadar kegagalan Agile telah disangkal secara menyeluruh, hanya meninggalkan serangan peribadi yang menyedihkan. P-Hacking with Dinosaurs 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 (sejak saya mengubah fikiran saya tentang Agile, DevOps, dll.) kerana metrik utama yang mereka gunakan untuk mengukur sesuatu adalah tertumpu pada kelajuan penghantaran ( ), tetapi hakikatnya mereka melihat ini walaupun menggunakan pendekatan mereka menunjukkan sesuatu yang lebih mendalam berlaku di sini. saya telah mengkritik metodologi pasukan DORA yang kita tahu adalah apa yang pengguna mahukan 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 mempersoalkan pendekatan tersebut. penyelidikan psikologi dalam bidang ini 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 dan . Projek Pheonix 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 , saya tidak merahsiakan tiga faktor yang saya hadapi dalam pendekatan moden untuk Agile, DevOps dan transformasi digital: " " Studi backer: Catastrophic take on Agile terlalu menekankan ciri baharu Pendekatan Agile yang menafikan keperluan, walaupun . berlaku bencana termasuk skandal Pejabat Pos dan nahas Boeing 737 Max 8 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 sebagai bagi mereka apabila menggunakan sistem komputer, dengan keselamatan data, ketepatan data dan tiada pepijat yang serius menjadi faktor yang paling penting. perkara paling tidak penting 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 ), 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. dalam Forbes pada bulan April 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 dan segala-galanya kelihatan untuk diperebutkan: OOP, corak reka bentuk, TDD, dll. rigor mortis 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 . 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. loss aversion Kertas itu, , menyimpulkan seperti berikut: "Jadi Adakah saya Dr. Frankenstein? Atau Adakah Anda Raksasa Sepanjang Masa?”: Mengurangkan Kegagalan Projek Perisian Dengan Metodologi Pembangunan Sedar Kehilangan Kehilangan 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.
