kodelokus

After Snowbird

Setelah pertemuan 2 hari di Snowbird, Uncle bob dan semua rekannya yang terlibat dalam pertemuan itu bekerja keras untuk menuntaskan dokumen dan prinsip-prinsip dari agile, merapihkannya, merumuskannya dan menambahkannya di website. mereka bekerjasama untuk menuntaskan pembukuan dan dokumentasi dari pertemuan itu, mengenai empat nilai itu, mereka semua setuju tanpa ada satupun yang mau untuk merubahnya. mereka bekerja dengan baik dan semakin dekat layaknya sebuah keluarga.

Mereka melakukan komunikasi menggunakan email untuk saling menambahkan, atau berdiskusi untuk menyempurnakan prinsip empat value tersebut, sampai akhirnya selesai dan mereka kembali ke pekerjaan mereka masing-masing.

Uncle bob sempat terpikir mengenai Idea dari Alistair yang ingin membuat pertemuan serupa, dan masi banyak orang-orang lain di sana yang mempunyai idea yang sama, yaitu membuat pertemuan untuk membahas masa depan pembangunan software, dan mereka pun akan menemukan akhir yang sama dengan pertemuan snowbird .

Dapat disimpulkan bahwa banyak programer yang mempunyai keresahan yang sama dengan masa depan software development, mereka pun merasakan hal yang dirasakan oleh uncle bob, merasakan bagaimana waterfall saja tidak cukup dalam pembangunan software kedepannya, sehingga dibutuhkan alternatif yang bisa memudahkan seorang programer, perusahaan, customer dan yang berkaitan, untuk membuat metode pembangunan software. Dan inilah Agile, hasil dari diskusi yang panjang dan kesepakatan dari 17 senior programer dengan keunikan dan sudutpandang yang berbeda namun mempunyai tujuan yang sama. Bravooo

Part 4 sudah selesai , kita lanjut ke part 5 ” Agile Overview “

SNOWBIRD

Bagian ini adalah tentang pertemuan snowbird di Utah, pertemuan dari 17 orang senior programer yang sudah berumur yang berkumpul untuk membahasa sebuah topik , yaitu “The Light Weight Process Summit“, para senior yang mencoba untuk memecahkan permasalahan di dunia programing dan software untuk kedepannya. Kita akan bahas berdasarkan kisah dari Uncle bob, sehingga bisa mengetahui kondisi yang digambarkan oleh uncle Bob.

Uncle bob menceritakan tentang pertemua snowbird,
Semua undangan hadir dalam forum itu, terdapat 17 orang yang berkumpul mepresentasikan pandangan yang berbeda, termasuk 5 pandangan yang berbeda tentang “Light Weight Process“. kelompok paling besar dihadiri oleh XP Team (Extream Programing) yang terdiri dari: Kent Beck, Uncle Bob, James Grenning, Ward Cunningham, Dan Ron Jeffries. dari The Scrum Team diwakilkan oleh: Ken Schwaber, Mike Beedle, dan Jeff Sutherland. Jon Kern mempresentasikan Feature-Driven Development, Arie van Bennekum mempresentasikan The Dynamic Systems Development Method (DSDM), Alistair Cockburn mempresentasikan Crystal family of processes.

Sebagian dari peserta tidak berafiliasi. Andy Hunt dan Dave Thomas merupakan programer yang pragmatis, Brian Marick sebagai Test Consultant. Jim Highsmith adalah seorang software management consultant, Steve Mellor yang mempresentasikan the Model-Driven philosophy, dan Martin Fowler seseorang yang dekat dengan kita semua.

Saya tidak begitu ingat tentang pertemuan 2 hari itu, namun beberapa dari teman saya membantu saya mengingat diskusi pada hari itu, karna cukup sulit untuk menggambarkan semua dari seorang yang berumur 65 tahun, tapi saya jamin jika yang saya ingat adalah hal-hal yang penting.

Saya memulai pertemuan itu, menjelaskan kepada peserta undangan untuk membuat suatu tujuan dan manifestasi dari Light Weight Process beserta pengembangan software dimasa yang akan datang, kami melakukan hal pada umumnya, yaitu menulis semua masalah-masalah yang kami temui dan memulai mengurutkannya sesuai dengan kelompok persamaannya. Saya tidak sadar saat hal yang menakjubkan terjadi, saat seseorang menuliskan di sebuah papan mengenai empat hal: Individuals and Interactions, Working Software, Customer Collaboration, and Responding to Change. dan hal itu dapat mewakilkan the complementary values of processes, tools, documentation, contracts, and plans, tanpa mengurangi maknanya sedikitpun.

Ini adalah Pusat/inti dari Agile, semua orang tidak mengingat siapa yang pertama kali menuliskannya di papan, ada yang berkata itu adalah ward Cunningham, namun Ward sendiri yakin jika yang menulis di papan adalah martin fowler.

Dalam agilemanifesto.org Ward menunjukkan jika seseorang yang lebih banyak menulis di papan adalah martin fowler, Ward menujukkan kepercayaannya bahwa martinlah yang memberikan Idea cemerlang tersebut.

Kami semua bersatu, dan ini merupakan keajaiban. dalm tim kecil itu ada yang menuliskan beberapa kata, ada yang mengoreksinya dan memperbaikinya, memberikan saran dan masukan, ward menulis dalam sebuah pembukaan ” We are uncovering better ways of developing software by doing it and helping others do it”, dan dari sini yang kami sadari bahwa kami sudah menyelesaikannya, ada perasaan yang melegakan di ruangan itu, tidak ada perbedaan pendapat lagi, tidak ada perbedaan argumen lagi, dan tidak ada yang memberikan alternatif lainnya, yang tersisa hanya 4 baris ini:

– Individuals and interactions over processes and tools.
– Working software over comprehensive documentation.
– Customer collaboration over contract negotiation.
– Responding to change over following a plan.

Apakah ini sudah selesai ? hmm, saya rasa begitu, meskipun akan banyak detail yang belum terungkap yang harus kita selesaikan. Namun, apa yang akan kita sematkan untuk hal yang belum terindetifikasi ini ? dari sinilah kita mulai memberi nama yang pantas untuk 4 nilai tersebut, saya lebih suka menyebutnya Light Weight Process, ada yang memberi sematan inconsequential, Adaptive dan ada yang menyebutkan Agile, namun kata yang paling baik di antara yg baik adalah ” Agile”. dan ward mengajukan untuk di muat dalam website agilemanifesto.org, sebagai bentuk persetujuan dari semua peserta perkumpulan ini.

Inilah hasil dari pertemuan 17 orang senior programing, yang menciptakan metode untuk membuat dan mengembangkan software dimasa yang akan datang. dari sinilah pijakan yang dibuat oleh ke 17 orang tersebut, dan pertemuan itu di abadikan di agilemanifesto.org. sebagai bentuk kesatuan mereka.

Seru kan, kita akan terus lanjutkan yang ke part ke 4 “After Snowbird”

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