Mengucapkan selamat tinggal pada Agile

• Tinjauan ulang yang kritis bahwa metodologi Agile yang telah mendominasi industri perangkat lunak pada kenyataannya hanyalah kumpulan prinsip yang kabur dan pengemasan ulang atas masalah yang sebenarnya sudah lama diselesaikan
• Kerangka pertentangannya dengan Waterfall nyaris merupakan ilusi, dan konsep inti seperti pengembangan iteratif dan keterlibatan pelanggan sebenarnya sudah diajukan dalam riset tahun 1970-an
• Agile selalu didefinisikan hanya sebagai lawan dari model Waterfall, padahal keterbatasan model Waterfall sudah dikenal luas sejak 1970-an
• Dengan kemunculan large language model (LLM) belakangan ini, Spec-Driven Development kembali menjadi penting dan pengembangan yang berpusat pada dokumentasi sedang bangkit
• Slogan Agile, “working software over comprehensive documentation”, kini bergeser menjadi pemahaman bahwa “comprehensive documentation creates working software”
• Sudah waktunya melampaui kekaburan yang ditinggalkan Agile dan kembali ke prinsip yang jelas serta pendekatan rekayasa

---

> RIP Agile, we hardly knew ye.
> And I mean that literally - because no one was ever clear on what it was.
> Selamat jalan, Agile. Kami bahkan tak pernah benar-benar mengenalmu.
> Dan itu secara harfiah benar — karena tak seorang pun pernah benar-benar jelas tentang apa itu.

Masalah identitas Agile

• Agile adalah gelombang besar yang menyapu seluruh industri perangkat lunak, tetapi pada praktiknya ia menyebar sebagai konsep yang maknanya tidak pernah jelas
• Setiap kali muncul pertanyaan, jawaban yang terus berulang adalah, “itu bukan Agile yang sesungguhnya”
• Jika benar-benar membaca Manifesto Agile (2001), hampir tidak ada panduan yang konkret, dan isinya berada di tingkat aforisme yang kabur seperti “kolaborasi dengan pelanggan lebih penting daripada negosiasi kontrak”
• Prinsip seperti “menyambut perubahan kebutuhan bahkan di tahap akhir pengembangan” bersifat tidak realistis secara komersial
• Di bawah klaim tentang “True Agile”, persoalan di lapangan kerap dihindari seolah-olah tidak ada kaitannya dengan manifesto itu sendiri
• Jika industri Agile tidak benar-benar mempraktikkan Agile, dan manifestronya sendiri juga minim makna, maka patut dipertanyakan apa sebenarnya substansi Agile itu

"Hantu Waterfall menghantui perangkat lunak"

• Agile selalu didefinisikan berdasarkan apa yang bukan dirinya yakni Waterfall; logikanya, jika Anda tidak menjalankan Agile maka Anda sedang menjalankan Waterfall, dan Waterfall tidak berhasil
• Namun fakta bahwa Waterfall tidak berhasil sebenarnya sudah diketahui sejak 1970, dan Winston W. Royce menjelaskan alasannya dengan tepat
• Royce merekomendasikan alternatif berupa memulai dari desain program, membuat prototipe perangkat lunak untuk memurnikan kebutuhan, serta melibatkan pelanggan secara formal, mendalam, dan berkelanjutan
• Semua ini kemudian diklaim sebagai inovasi Agile, padahal sebenarnya sudah ditulis pada 1970, setahun setelah pendaratan di Bulan
• Catatan kaki 1: bagaimana para programmer Apollo Guidance Computer bisa mencapai prestasi sebesar itu tanpa story point, bahkan tanpa mengetahui prinsip bahwa “perhatian terus-menerus pada keunggulan teknis meningkatkan agility”?

Makalah Bell-Thayer 1976 dan sejarah pengembangan iteratif

• Makalah Bell dan Thayer tahun 1976 adalah literatur yang pertama kali menggunakan istilah "Waterfall", dan istilah itu sendiri dipakai sebagai contoh tentang apa yang tidak boleh dilakukan
• Kesimpulan studi empiris dalam makalah tersebut: cacat dalam kebutuhan baru ditemukan selama proses pengembangan perangkat lunak saat orang mencoba memenuhi kebutuhan itu lewat desain
• Pengembangan iteratif bukanlah hal baru, melainkan sesuatu yang terus disempurnakan selama puluhan tahun sebelum Agile
• Bahkan sebelum manifesto itu “membebaskan” industri, Waterfall bukanlah teknik mutakhir, dan tidak ada yang secara serius meragukan efektivitas kebutuhan serta spesifikasi

Kebangkitan Spec-Driven Development dan sesudah Agile

• Dengan meluasnya large language model (LLM), arus programmer yang kembali menulis spesifikasi (specification) semakin menguat
  • Karena LLM rentan terhadap input yang ambigu, mendeskripsikan masalah secara jelas kini menjadi cara penting untuk membantu menghasilkan kode yang benar
  • Jika Agile menekankan “working software over comprehensive documentation”, maka Spec-Driven Development mengajukan proposisi sebaliknya: "comprehensive documentation creates working software"
• Royce sudah menegaskan pada 1970 bahwa “dokumentasi, spesifikasi, dan desain adalah konsep yang sama sampai saat penulisan kode dimulai; jika dokumentasinya buruk, desainnya juga buruk”
  • Ia menekankan bahwa jika dokumentasi tidak ada, maka desain juga tidak ada
• Ketika meninjau kembali riset dari 1970 dan 1976, terlihat bahwa Manifesto Agile tahun 2001 gagal menawarkan wawasan baru
  • Agile hanya menggantikan pendekatan rekayasa yang sudah ada dengan definisi yang kabur dan kemasan komersial, tanpa menghasilkan kemajuan yang nyata
  • Makalah para insinyur itu justru memuat makna yang jauh lebih jelas
• Di tengah pengembangan perangkat lunak yang terus berubah dan berevolusi, sudah waktunya mengirim Agile ke ranah sejarah dan beralih ke sudut pandang baru
  • Kita perlu kembali pada prinsip yang jelas dan cara berpikir rekayasa yang ditinggalkan para insinyur serius di masa lalu

[savvykang]

Saya tidak mengerti kenapa metodologi diperlakukan seperti kitab suci. Menurut saya, penulis aslinya juga sama-sama dogmatis, hanya arahnya saja yang berbeda.

[tekart]

Kesimpulannya terasa agak berlebihan. Komersialisasi atau formalisasi mungkin bisa jadi masalah, tetapi bukan berarti alat seperti sprint atau backlog sudah tidak berguna. Itu juga membantu membentuk budaya rapat yang lebih horizontal dan berfokus pada tujuan. Memang benar SDD menjadi lebih penting, tetapi karena spesifikasi itu sendiri bisa ditulis dengan cepat secara kolaboratif bersama AI, itu tetap agile. Hanya saja sprint dua minggu dipersingkat menjadi beberapa jam; esensi iteratif untuk terus menyempurnakan tetap sama, menurut saya.

[unknowncyder]

Saya setuju.

Pesan yang tersisa bagi kita juga besar hanya dari upaya mendobrak pengambilan keputusan yang vertikal dan perbaikan berulang dalam siklus pendek saja (tentu saja hal yang sama juga berlaku untuk teknik/alat manajemen proyek).

Kesimpulan yang 'mengatakan bahwa agile sendiri tidak mampu memberikan wawasan baru, serta menggiring seluruh orang yang membela agile sebagai fanboy agile yang buta' tampaknya agak berlebihan.

[lukeskywalker]

Saya setuju. Agile masih tetap relevan. Rasanya seperti omongan orang-orang yang tidak pernah bekerja di lapangan dan berbicara ke udara.

[dopeflamingo]

Tulisan yang bodoh. Intinya justru spec. itu sendiri harus ditulis secara agile... Agile adalah soal cepat berubah dan beradaptasi terhadap kebutuhan pelanggan.

Karena orang-orang yang punya kesalahpahaman seperti ini tentang agile dan imajinasi setengah matang, baik agile maupun budaya pengembangan jadi berjalan ke arah yang salah.

[snisper]

Apa maksudnya menulis spec secara agile?

1. Menulis spec secara asal.
2. Menulis spec persis seperti yang didiktekan pelanggan.
3. Saat kebutuhan pelanggan berubah, memeliharanya dengan bantuan alat agar spec bisa cepat diubah.
4. Menulis spec secara agile.

Inti tulisan itu dari awal adalah bahwa penulis sendiri tidak tahu sebenarnya agile itu apa. Mereka hanya terus bicara bahwa agile punya karakteristik seperti ini dan harus dilakukan begini begitu, tetapi saya belum pernah melihat tulisan yang benar-benar menunjukkan, “ini adalah produk yang dibuat dengan metodologi agile.” Bahkan saat melihat manifestonya pun rasanya masih samar. Mungkin bisa ditunjukkan sekali?

[dopeflamingo]

Itu adalah isi yang pada dasarnya muncul di sebagian besar buku tentang teknik Agile, seperti Extreme Programming dari Kent Beck dan Scrum dari Jeff Sutherland. Anda juga bisa melihat user story. Kebanyakan orang tampaknya tidak benar-benar memahami bahwa fondasi Agile adalah sprint pendek dan demo untuk beradaptasi dengan cepat terhadap kebutuhan pelanggan.

[lukeskywalker]

Poinnya 3 dan 4. Menulis spesifikasi secara detail punya kedalaman yang nyaris tak terbatas. Maksudnya, ada tingkat yang sesuai dengan organisasi. Jika melihat sejarah bagaimana layanan-layanan sukses dibuat, saya paham bahwa dalam 99% kasus, salah satu hal utama justru adalah tidak mengerahkan terlalu banyak tenaga untuk menulis spesifikasi secara presisi. Intinya, jangan sampai terjebak di situ. Kalau melihat bagaimana Summoners War, Dungeon & Fighter, Zigbang, dan Lineage dibuat, itu sudah jelas.

[nvkzrx]

Bagaimana jika siklus waterfall berputar hanya dalam satu hari?

[aciddust]

Akhir-akhir ini saya lebih sering melihat kasus seperti ini.

[osw0124]

Parahnya, ini sepertinya yang paling sering saya lihat...

[fnwinter]

Selain rilis dalam siklus pendek, saya tidak tahu apa lagi yang tersisa dari agile.
Backlog dan sprint juga sudah ada sebelumnya dalam bentuk lain, dan komunikasi dengan pelanggan punya banyak bagian yang tidak sesuai dengan kenyataan. Pada akhirnya, saya pikir perbaikan DevOps membawa peningkatan pengembangan yang lebih besar daripada agile.

[myc0058]

Di dalam negeri, agile tidak lebih dan tidak kurang dari sekadar alat untuk menekan jadwal para developer.

[galadbran]

Dalam ukuran tertentu, semua orang itu agile. Rasanya belum pernah ada zaman seperti sekarang, ketika kita bisa merilis secepat ini dan menerima umpan balik.

[flowkater]

Tulisan ini sendiri tidak lincah!

[develosopher]

Karena bukan berarti kita sama sekali tidak perlu membaca kode, dari sudut pandang ini ungkapan bahwa kode lebih penting daripada dokumentasi tampaknya memang valid. Dan karena dokumentasi sebagai instruksi harus dibaca oleh LLM sebagai pihak yang mengimplementasikan, dari sudut pandang ini saya juga setuju. Jadi kesimpulannya, bukankah keduanya sama-sama penting pada saat yang sama?
Masalah produk yang dihasilkan LLM saat ini adalah utang teknis yang menumpuk pada tahap operasional. Untuk operasional yang berkelanjutan, developer harus terlibat pada kode, dan untuk itu, setidaknya sampai sekarang, saya pikir kode masih harus bisa menggantikan dokumentasi.

[snisper]

Kalau saya menyampaikan sanggahan ini dengan hati-hati, saya berpendapat bahwa kode tidak bisa menggantikan dokumentasi. Sampai sekarang, programming language masih belum memiliki kekayaan ekspresi dan daya penyampaian bahasa alami, dan secara realistis, siapa yang sempat membaca kode sebanyak itu?
Berharap memiliki kode yang bisa menggantikan dokumentasi memang adalah harapan dan angan-angan, tetapi itu seperti Menara Babel yang tak akan pernah bisa dicapai.
Menurut saya, lebih baik serius mendalami OOAD.

[willom2c]

Sebaliknya, saya juga melihat bahwa akan sulit bagi bahasa alami untuk menggantikan kode. Bahasa alami memang lebih cepat dibanding kode, tetapi terlalu abstrak. Untuk komputasi, pada akhirnya detail tetap harus diisi, dan tampaknya bahasa alami terlalu terbatas untuk menjalankan peran ini.

[snisper]

Dalam penulisan SW, masalahnya bukanlah abstraksi, melainkan ambiguitas. Bahasa alami pada dasarnya ambigu. Juga bisa memiliki lebih dari satu makna. Karena itu, mungkin inilah alasan mengapa upaya untuk melakukan coding dengan bahasa alami tidak berjalan dengan baik. Dalam situasi seperti ini, membayangkan bahasa alami menggantikan kode saja rasanya sudah jauh dari kenyataan.

[develosopher]

Saya memahami dan setuju dengan pendapat yang Anda sampaikan.
Jelas ada bagian-bagian yang tidak bisa digantikan oleh kode.
Dalam konteks itu, jika saya jelaskan dengan sedikit berbeda, yang ingin saya sampaikan adalah bahwa kode yang memiliki keterbacaan tinggi membuat kita tidak perlu menghasilkan dokumentasi.
Dokumen yang menumpuk seiring perangkat lunak berjalan dalam jangka panjang juga menambah beban kognitif bagi developer. Intinya adalah mengurangi pekerjaan bolak-balik antara kode dan dokumen.
Saya tidak berpikir bahwa pada akhirnya kita bisa hanya menyisakan kode saja.
Menurut saya, ini bisa berbeda tergantung konteks dan situasi yang dihadapi.
Terima kasih atas komentarnya.

[GN⁺]

Komentar Hacker News

• Melalui Agile, saya melihat fenomena yang menarik
  Jika gagal, strukturnya ditafsirkan seolah-olah “belum dilakukan dengan cukup baik”
  Saya melihat pola yang sama pada cloud, microservices, kebijakan penghematan, dan lainnya — penyebab kegagalan selalu dianggap sebagai kurangnya eksekusi, sementara pendekatannya sendiri dipercaya tidak pernah salah

  • Agile-ism favorit saya adalah definisi bahwa “proses yang cocok untuk tim itulah Agile”
    Jika tim mencoba Agile lalu hasilnya tidak baik, muncullah logika defensif bahwa “itu bukan Agile yang sesungguhnya”. Pada akhirnya, Agile menjadi konsep yang tidak bisa gagal
  • Akar kebingungannya adalah karena Agile disalahpahami sebagai proses
    Agile Manifesto hanya membahas nilai dan prinsip. Masalahnya adalah budaya organisasi yang memaksanya masuk ke dalam bentuk proses
  • Pola ini juga terlihat dalam agama maupun spiritualitas
    Struktur yang membuat orang bercermin ke dalam saat gagal tidak selalu buruk. Dibanding menyalahkan faktor luar, ini bisa menjadi sistem yang sehat karena mendorong refleksi diri
  • Kebanyakan perusahaan sebenarnya tidak sungguh-sungguh menginginkan Agile
    Roadmap yang sudah dijanjikan ke pelanggan sulit disejajarkan dengan respons yang fleksibel. Kenyataannya, organisasi yang berpusat pada perencanaan hanya meniru Agile di permukaan
  • Diskusi ini mengingatkan saya pada Agentic software development
    Jika gagal, kesimpulannya menjadi “seharusnya kita memakai agent lebih banyak”. Terdengar seperti lelucon bahwa “token tidak akan pernah cukup”

• Saya jadi takut pada formalisasi Agile
  Saya pernah berhasil menjalankan tim beranggotakan 40 orang, tetapi Agile yang sesungguhnya bisa diringkas hanya dalam empat kalimat — manusia, perangkat lunak yang berfungsi, kolaborasi dengan pelanggan, dan respons terhadap perubahan
  Masalahnya, ‘Agile’ dengan huruf besar justru berubah menjadi proses yang kaku

  • Empat kalimat itu luar biasa, tetapi dalam praktiknya paling cocok untuk tim kecil
    Saat jumlah orang bertambah, penyelarasan tujuan menjadi sulit, dan pada akhirnya kontrol serta prosedur pun dibutuhkan
  • Saya sudah tak terhitung kali melihat proyek yang disebut “Agile”, padahal kenyataannya Waterfall
  • Kebanyakan organisasi menerima framework seperti Scrum, SAFE layaknya doktrin
    Bahkan sampai membatasi hak untuk membuat ticket, jadi sangat jauh dari fleksibilitas
  • Ungkapan “perangkat lunak yang berfungsi lebih penting daripada dokumentasi” justru berdampak buruk untuk sistem yang kritis terhadap keselamatan
    Jika dokumentasinya kurang, pemeliharaan menjadi mustahil, dan akhirnya mengarah ke pengembangan YOLO
  • Saya selalu ingin tertawa saat melihat organisasi berkata, “Kami bekerja secara Agile,” lalu menampilkan diagram SAFE

• Agile di perusahaan-perusahaan besar tempat saya bekerja adalah kebohongan
  Seorang rekan pernah berkata, “Kalau pekerjaan sprint berikutnya dikerjakan lebih dulu, semuanya selalu selesai tepat waktu.”
  Artinya, Agile berfungsi sebagai sistem produksi metrik, bukan sistem untuk pekerjaan nyata

  • Saya juga pernah melihat Agile yang berpusat pada metrik seperti itu
    Para manajer puas hanya dengan melihat angka naik, dan produk jatuh menjadi sekadar produk sampingan dari statistik
  • Tapi saya tetap penasaran bagaimana rekan itu bisa memprediksi pekerjaan sprint berikutnya lebih dulu

• Layak untuk membaca kembali teks asli Agile Manifesto
  Itulah satu-satunya titik kesepakatan. Kita perlu ingat betapa buruknya Waterfall sebelum Agile muncul

  • Jika bertanya pada orang dengan pengalaman 30 tahun, mereka akan bilang bahwa meskipun penuh masalah, Agile pada akhirnya tetap merupakan perubahan yang positif
    Itu adalah alat yang mengakhiri era pemaksaan jadwal dan hasil yang serba tetap
  • Namun para manajer menengah tidak ingin memahami Agile yang sesungguhnya
    Karena jika tim bekerja secara otonom, posisi mereka sendiri bisa terasa terancam
  • Sekali lagi, Agile Manifesto memang perlu dibaca ulang

• Seperti yang dikatakan Kent Beck dalam “Extreme Programming”, Agile adalah upaya untuk menghindari tirani kemahatahuan yang dibayangkan
  Waterfall di masa lalu berusaha memprediksi semuanya pada tahap desain, sambil mengabaikan pembelajaran dan umpan balik
  Namun seiring waktu, ritual dan bentuk formal Agile menutupi esensinya
  Saya masih menyukai Agentic programming, tetapi pada akhirnya yang penting adalah peran manusia yang menyambungkan konteks

• Artikel aslinya terasa membingungkan
  Katanya Agile tidak menciptakan hal baru, tetapi lalu mengklaim bahwa jika LLM menulis kode maka Agile sudah mati
  Namun inti Agile adalah mengakui spesifikasi yang tidak sempurna dan memperbaikinya secara iteratif
  Prinsip ini masih tetap valid

  • Pengembangan iteratif adalah konsep yang setua sejarah manusia
    Agile hanyalah salah satu variannya, dan masalahnya lebih banyak pada implementasi yang buruk
    Produk yang baik pada akhirnya lahir dari siklus spesifikasi → pembelajaran → perbaikan
  • agile dengan huruf kecil berarti pengembangan yang fleksibel, tetapi Agile dengan huruf besar berubah menjadi ritualisme Scrum
    Prosedur seperti Backlog Grooming dan Sprint Review justru menekan perubahan

• Pengembangan berbasis spec tampaknya tidak akan bertahan lama
  Tetap lebih cepat untuk membangun perangkat lunak yang berfungsi lalu mengiterasinya — pada akhirnya ini adalah kembalinya Agile

  • Namun belakangan ini, strukturnya adalah agent yang menulis spec lalu manusia meninjaunya
    Kualitas spec membaik, dan review menjadi lebih mudah daripada membaca kode
  • Ada juga upaya seperti Compound Engineering untuk mencari titik tengah antara spec dan iterasi
    Lihat tautan GitHub

• Dalam manifesto itu tidak ada istilah seperti Daily Standup atau Agile Coach
  Esensinya adalah “jangan melakukan micromanage terhadap programmer”
  Dengan kata lain, pesannya adalah berikan lingkungan dan kepercayaan kepada individu yang termotivasi

• Para pendiri seperti Kent Beck dan Martin Fowler awalnya bermaksud membuat panduan yang fleksibel
  Namun seiring waktu, ini menjadi terkomersialisasi, dan para pengikut fanatik pun muncul sehingga kebingungannya makin besar
  Keberhasilan pada akhirnya bergantung pada kemampuan dan sikap manusia
  Panjang sprint juga harus disesuaikan dengan situasi, dan jika tidak ada spec, tim harus membuatnya sendiri
  Di era AI pun, selama ada orang yang menggunakan Agile dengan bijak, itu tetap relevan

• Saya penasaran apa tepatnya arti dari “menulis spec”
  Semua proyek Agile yang pernah saya kerjakan punya dokumen desain, dan ticket diturunkan dari dokumen tersebut
  Pengembangan berbasis ticket tanpa dokumen terdengar seperti neraka

  • Benar, kami juga punya dokumen, tetapi penuh dengan kebohongan
    Semua orang menafsirkannya sesuka hati
  • Namun jika “dokumen desain adalah titik awal”, maka itu bukan Agile yang sesungguhnya
    Pendekatan yang berpusat pada ticket justru lebih dekat dengan Agile yang murni
  • Dalam Agile yang sesungguhnya, percakapan dengan pengguna adalah sumber kebenaran
    Agile palsu berpura-pura bahwa dokumen buatan PO atau PM adalah kebenaran
  • Sebagai penulisnya sendiri, saya akan mengatakan bahwa pada akhirnya nama “Agile” bisa ditempelkan ke apa saja
    Cara yang Anda sebutkan itulah yang paling dekat dengan makna ‘menulis spesifikasi’ yang saya maksud