Sejarah Agile
Jika kita bertanya, sejak kapan dimulainya agile ?
bisa jadi saat zaman dahulu disaat sekelompok orang saling berkolaborasi/bekerjasama untuk tujuan bersama, untuk kepentingan bersama. Begitu juga agile di era industri, terciptanya mesin uap, pesawat dan penemuan lainnya, yang terukur, dan berjalan secara natural. itulah agile.
Jadi kapan agile dimulai dalam software? Uncle Bob menggambarkan sesosok Alan Turing, bagaimana Alan sudah banyak membuat program mulai dari tahapan awal yang sederhana dengan telaten, begitu juga saat Alan membuat Automatic Computing Engine dengan hati-hati, Alan membuat langkah kecil, dengan banyak trial, Cek dan real testing. begitu juga dengan Mercury Space capsul yang dalam sela-sela pembuatan control Software nya selalu melakukan testing.
Kisah-kisah hebat sudah banyak tertulis dimana-mana, Ward Cunningham menuliskan dalam wikinya sejarah tentang Larman’s book, Agile & Iterative Development: A Manager’s Guide, dan banyak persaingan metodologi yang bisa membuat sukses industri manufaktur dan industri sekala besar lainnya dengan menggunakan: Scientific Management. Scientific Management merupakan metodologi top-down dari atasan ke karyawan dengan pendekatan perintah dan kontrol, manajer dan team bisa memastikan tercapainya semua tujuan yang sudah di sepakati, hanya saja kebutuhan dan rencana dibahas di awal dan harus berhati2 dengan detail-detail yang belum ada sebelumnya. pastinya butuh gabaran yang utuh dengan detail yg spesifik, dan mungkin bisa jadi masalah besar jika saat proses berjalan, ada ide-ide atau perubahan pada software tersebut.
Scientific Management merupakan metode yang cukup kuno, mungkin sama kunonya dengan pembuatan piramida, stonehenge, bahkan candi borobudur. Namun metode ini sukses membuat banyak karya yang menakjubkan dimasa lalu. dan ide dari metode itu akan terus diulangi sehingga manusia bisa mencapai hal semacam revolusi.
Scientific Management menjadi semakin viral ditangan Frederick Winslow Taylor pada tahun 1880. Dengan pemahaman tersebut mengantarkan Taylor menjadi seorang konsultan menejemen, dan metode itu secara bertahap menjadi sukses dan membuat perusahaan menjadi lebih produktif pada masanya dan setelahnya.
Pada tahun 1970 an, dunia software di hadapkan dengan 2 teknik/metode yang saling bersebrangan, Pre-agile dan Scientific Management. Pre-agile memerlukan langkah yang tepat yang terukur dan dapat di perbaiki secara perlahan, langkanya acak namun bisa menghasilkan hasil yang bagus. Scientific Management lebih mengutamakan spesifikasi software yang detail diawal, sehingga pengerjaan belom bisa dilakukan selama detail belom lengkap. Pre-agile sangat cocok/pas untuk projek dengan cost perubahan yang kecil, karna dapat menyelesaikan masalah secara parsial, dengan perubahan Kesepakatan secara informal. Scientific Management lebih cocok untuk projek dengan cost perubahan yang mahal/tinggi, dengan pemecahan masalah yang baik dengan tujuan yang spesifik.
Jadi, dalam software development manakah yang lebih cocok ? Scientific Management atau Pre-Agile. Uncle bob pun hanya menjelaskan jika pada tahun 1970, software dikerjakan karna sebuah ketidak sengajaan bukan karna persiapan yang jelas.
Pada tahun 1970 Wiston Royce menulis makalah yang mendeskripsikan idenya untuk memenej projek software sekala besar, makalah tersebut terdapat diagram yang menggambarkan rencananya. Royce bukan pencetus diagram tersebut dan hanya menggunakan diagram tersebut sebagai gambaran yang nantinya akan Royce gunakan untuk meruntuhkan diagram tersebut pada halaman selanjutnya dalam makalahnya.
Namun, penempatan Diagram yang mencolok ini membuat pembaca dapat menyimpulkan sendiri isi dari halaman pertama dan kedua dari makalah ini, sehingga menyebabkan perubahan yang dramastis dalam industri perangkat Lunak.
Royce mulai mencermati diagram tersebut, dan melihatnya seperti air yang jatuh dari dinding batu, dari sinilah Royce menyebutnya ” Water Fall ” . hmm begini toh ceritanya .
Waterfall sendiri bisa dikatakan adalah turunan dari Scientific Management. Waterfal melakukan analisa menyeluruh diawal berdasarkan gambaran dan asumsi kita sesuai dengan pengalaman kita di dunia software, membuat rencana dengan detail dan melakukan eksekusi rencana tersebut hingga selesai. meskipun pada dasarnya hal ini bukan yang royce rekomendasikan, itu hanyalah konsep yang orang-orang dapatkan dari membaca makalahnya dan hal ini bertahan hampir selama 30 tahun berikutnya.
Pada tahun 1970, usia Ucle Bob masih 18 tahun, ia bekerja sebagai programer di sebuah perusahaan A. S. C. Tabulating di Lake Bluff, illinois. Perusahaa tersebut mempunyai IBM 360/30 dengan 16K core, IBM 360/40 dengan 64K core, dan variasi 620/f komputer mini dengan 64K core. Uncle bob memprogram 360s dengan mengguakan COBOL,PL/1, Fortran, dan assembler. dan hanya menulis meggunaka Assembler pada 620/f.
Uncle Bob menceritakan kondisi saat itu,
“sangat penting untuk mengingat atau merasakan menjadi programer di masa itu, kami menulis pada sebuah kartu khusus untuk code dengan menggunakan pensil, kami menggunakan tombol operator supaya komputer membuka alatnya untuk kami. kami memasukkan kartu yang sudah kami buat dengan sangat berhati-hati ke operator komputer untuk melakukan compile dan testing pada shift ke tiga, karna selama siang hari komputer terlalu sibuk. terkadang memerlukan berhari-hari dari awal code sampai selesai di-compile, dan saat melakukan compile berikutnya biasanya memerlukan satu hari lagi.
Bagiku 620/f sedikit berbeda, mesin itu sudah di dedikasikan untuk Tim kami, kami bisa megaksesnya 24 jam selama 7 hari, kita dapat melakukan 4 kali testing setiap hari, tim kami terdiri dari bermacam-macam orang dan tidak seperti programer saat ini, hanya mengetik, kami dapat menekan tombol kartu kami masing-masing, dari pada memberikan ke mesi operator yang aneh.
Jadi, proses apa yang kami lakukan waktu itu ? pastiya bukan waterfall. kami tidak puya konsep dan detail dari gambaran software sebelumnya. kami hanya berusaha hari demi hari, melakukan compile, testing kode, dan fixing bugs terus menerus, karna kami tidak mempunya acuan metode yang baku, ini juga bukan agile, atau pre-agile. Tidak ada acuan saat kami bekerja, tidak ada rangkaian test dan waktu yang membatasi. kami hanya melakukan koding dan fixing, koding da fixing hingga berhari-hari dan berbulan-bulan”.
Uncel Bob melanjutkan dalam kisahnya,
“pertama kali aku membaca tetang waterfall di sebuah jurnal di sekitara tahun 1972, itu seperti berkah, apakah benar kita bisa menganalisa sebuah masalah di awal, dan mendesain penyelesaiannya, dan implementasi semua desain yang sudah di selesaikan? bisakah merancang kegiatan berdasarkan tiga fase itu? ketika kami selesai dengan analisa, apakah benar kita sudah mencapai sepertiga dari projek itu ? aku dapat merasakan kekuatan dari konsep ini dan harus meyakininya , ini seperti sebuah mimpi yang jadi nyata.
Tampaknya, aku tidak sendiri, banyak programer dan perusahaan programing menangkap kesempatan ini. dan seperti yang sudah saya sampaikan, jika waterfall benar-benar mendominasi pemikiran di masa itu. waterfall sangat mendominasi, tapi tidak berhasil, selama tigapuluh tahun kedepan , asosiasi dan semua programer di seluruh dunia mencoba dan selalu mencoba untuk membuat analisa dan desain yang benar, namun saat kita merasa semua berjalan sesuai rencana, masalah selalu ada saat fase implementasi, semua yang sudah kami rencanakan dan persiapkan selama berbulan-bulan menjadi tidak relevan karna kesalahan yang tidak terencana/terduga, hal itu di saksikan didepan para menejer dan pelanggan, dan lebih buruk lagi, waktu Pekerjaan tidak sesuai dengan deadline.
Meskipun kegagalan ini selalu berulang-ulang. kami tetap menggunakan waterfall sebagai pedoman. lagipula kenapa bisa gagal ? bagaimana menganalisa masalah, merancang solusi dan mengimplementasikan solusi dari desain yang gagal terus menerus ? tidak bisa di bayangkan jika permasalahan terletak pada strategi kami, Permasalahan itu terletak pada kami. tanpa kami tau kenapa kami bisa salah. Dominasi metode waterfall sangat tampak pada bahasa pemrograman hari ini, Dijkstra hadir dengan struktur pemrograman pada tahun 1968, struktur analis dan design juga tidak lama dari itu muncul, ketika OOP (Object-Oriented Programing) menjadi populer di tahun 1988, Object oriented analis dan desain (OOA dan OOD) juga Muncul tak lama dari itu, ketiga serangkai itu membuat kondisi semakin rumit, dan kami tidak mudah untuk merubah cara kerja kami yang sebelumnya, namun kemudian kami bisa.
Awal mula reformasi agile mulai tampak pada akhir 1980 dan awal 1990, hal itu tampak pada beberapa komunitas dan beberapa makalah yang di tulis pada tahun 1980, semisal The Smalltalk Community, buku Boock tahun 1991 tentang OOD. cockburn Crystal methode 1991, The Design patterns community 1994, dan makalah spurred dari james Coplien. Pada tahun 1995 Beedle, Devos, Sharon, Schwaber, dan sutherland telah menulis makalah yang sangat terkenal yaitu Scrum, Konsep ini bisa menjadi alternatif dari WaterFall. Begitulah uncle bob mencoba menggambarkan tetang kondisi saat scrum muncul.
Uncle bob beberapa kali bertemu dengan Kent beck pada 1994 saat seminar PLOP, Illinois, dan pada tahun 1999 seminar OOP di munich. dan itu sangat luar biasa bagi uncle bob. Pada masa itu, Uncle bob sebagai konsultan C++ dan OOD, ia terbang kesana kemari untuk membantu banyak orang dalam desain dan implementasi aplikasi menggunakan C++ dan teknik OOD. pada saat itu konsumennya bertanya mengenai proses dan pernah mendengar jika waterfall tidak mix dengan OO (Object Oriented), dan meminta pendapat uncle bob, pertanyaan itu membuat uncle bob sempat terpikir untuk menulis proses OO nya sendiri, namun ia urungkan niat itu setelah membaca tulisan Kent Beck tentang Extreme Programing (XP). Saat uncle Bob membaca Extreme Programing (XP), ia merasa terpesona, ide XP sangat revolusioner, sehingga membuat ia ingin terus belajar.
Pada sebuah seminar di Munich, Uncle Bob menjadi salah satu pematerinya, Dia cukup kaget karna bisa bertemu dengan kent back yang juga berada di forum itu, dia bertemu dengan kent beck saat perjamuan makan siang dan dari pertemuan itu tercapailah kerjasama antar keduanya, dari situlah bermula kunjungan pertama uncle bob kerumah kent beck, selama kunjungan itu uncle bob mengenal Test-Drivent Development (TTD) yang membuat dia semakin tertarik.
Uncle bob mempunyai perusahaan bernama Object Mentor, dan telah melakukan kerjasama dengan kent yang diberinama XP Immersion,kerjasama tersebut adalah membuat sebuah boot camp selama 5 hari untuk pelatihan XP, dan menuai kesuksesan yang cukup besar di akhir tahun 1999 hingga 11 september 2001. mereka berhasil melatih ratusan orang.
Pada musim panas tahun 2000 kent mengundang beberapa orang dari komunitas XP and pattrents Community untuk melakukan pertemuan kecil di dekat rumahnya, mereka sedang membicarakan dan memutuskan bagaimana kelanjutan XP kedepan. Ada sebuah idea yang mengusulkan untuk membuat lembaga non-profit yang berkaitan dengan XP, uncle bob setuju, namun banyak orang tidak setuju, karna sebagian besar dari mereka pernah mempunyai pengalaman yang kurang baik dengan idea tersebut, sengitnya diskusi tersebut uncle bob meninggalkan forum itu, dan di ikuti oleh Martin fowler dan Martin mengajak uncle bob untuk berdiskusi hal ini di chicago.
Pada musim gugur tahun 2000, uncle bob bertemu dengan martin di kantor ThoughtWorks tempat martin bekerja, uncle bob menjelaskan kepada martin tentang keinginannya untuk mengumpulkan orang-orang yang tertarik dengan Lightweight Process, untuk berkumpul dan membuat manifestasinya, Martin yang setuju dengan idea uncle bob langsung membuat undangan untuk orang-orang yang akan mereka undang dalam The lightweight Process Summit.
Alistair Cockburn adalah salah satu undangan dalam acara itu, yang bermaksud untuk membuat acara yang serupa, namun setelah berdiskusi dengan Uncle bob, Alistair cockburn pun merekomendasikan untuk menggabukan acaranya, dan dari sinilah mulai terbentuk pertemuan di Snowbird tersebut.
Gimana, Seru nggk ceritanya ? kita sudah tau kan asal muasal metode Waterfall , TDD, dll.
keseruan ini masih berlanjut di part 3 , di tunggu ya
kodelokus 