Learn the Rules, Break The Rules, and Create the New Ones...

Hi... My name is Rizky Prihanto. You can call me RQ, or Rizky either. I am currently living on Bandung, Indonesia. Had a lot of works and research about Enterprise Information Systems (majoring on education and e-governments). I have bunch of interests (some friends call it 'freakz') about MySQL Opensource Database and now I am one of the administrator of MySQL Indonesia User Group - the opensource community initialized by Sun Microsystems Indonesia.

My Company PT Cinox Media Insani, Bandung, Indonesia. I work here since 2008 and I take responsibility as Chief of Software Architect. My job is about planning, imaginating, fantasy-ing, concepting, and build the infrastructure of the new information systems (or app engines) which going to be implemented.

This blog This is my blog that represent my current opinion, research and experiences about anything in Software Engineering. Written since 2007 (actually) and has been vaccum for a lot of while. And now I wanna ressurrect this blog (optimistically) from the long-long-hibernation with something fresh and new ideas -- still about MySQL, software engineering, development, and may be something managerial here.

About the tagline I've learned the statement above from some paper written by Kent Beck about Extreme Programming (XP) methodology -- some sort of practical software development methods which have no boundaries. That's very inspiring me a lot. I have written some article on this blog that tell my interpretation about that statement here.

My Another Blogs I have classifying my blogs into some sort of genre. The blog that you read here right now is my primary blog that tell you (majoring) about IT stuff. But if you wanna look another side of me, you can visit here, here, here,or here. Hope it'll be interesting for some of you.

Credits I would thanks to Blogger for this great blog platform. Skinpress who designed this Wordpress template (which is bloggerized by Free Blogger Templates). My appreciate is also going to you who give your generously time for visiting my blog.

Mengoptimalkan Penerapan Extreme Programming

Tertarik menerapkan metode Extreme Programming dalam pengembangan sistem perangkat lunak? Bosan dengan metode-metode klasik yang cenderung bikin susah developer pasca implementasi karena direpotin ama revisi-revisi sistem dan keluhan-keluhan yang datang bertubi-tubi dari client? Silakan...

Postingan ini akan menjelaskan dulu apa-apa aja prasyarat yang musti diperhatikan klo pengen sukses jaya dalam nerapin gaya ngembangin sistem secara cerdas (agile development) makae metode Extreme Programming (XP). Hal-hal yg kudu dipertimbangkan sebelum menjerumuskan diri dan tim development kita ke lembah XP adalah sbb :

  1. User harus memahami benar konteks bisnis yang digelutinya yang akan dikembangkan sistemnya, sehingga developer dapat menangkap sudut pandang sistem secara aplikatif dan dapat mengusulkan ekspansi-ekspansi teknologi apa yang dapat dikembangkan dalam sistem barunya. Kalo user-nya sendiri ngga tau dia sebenarnya musti ngapain-ngapain aja sih setiap harinya -- wahh -- fase analisis requirement bakal berlangsung panjang dan berliku-liku deh... User yang paham *konteks bisnisnya sendiri* tentunya juga paham bagaimana perencanaan yang baik dalam pengembangan sistem. Kadang mereka nggak sadar kalo mereka sebenarnya udah paham, karena mereka hanya bingung saja karena ada seorang dari "galaksi lain" yang ngaku-ngaku sebagai analis sistem sedang bercerita tentang teknologi-teknologi yang selama ini diluar bayangannya. Oleh karena itu, PENTING BAGI analis sistem untuk mampu *memancing* cerita mereka tentang konteks bisnis mereka... - terserah gimana tekniknya, dengan pendekatan moral, material atau spiritual. Pendekatan moral, misalnya : berupaya "memposisikan" diri di posisi client. memahami pola kerja, budaya kerja, dan rutinitas2 harian mereka. Pendekatan material, kadang harus ditempuh - terutama utk client pemerintah (maaf buat pak governments - hehehe) - supaya client mau cerita tentang kebutuhannya, perlu di-stimulasi dengan "$$$". Nah kalo pendekatan spiritual, bisa aja dilakukan supaya client mau cerita banyak tentang organisasinya, budaya kerjanya, rutinitas2 harian mereka, kita dekatin tu client (kalo cewek), ajak nonton bareng, makan bareng, pacarin... sehingga dia lebih open tentang segala hal yang berkaitan dengan bisnisnya ... dan hal-hal di luar bisnis. wakakakakaka...
  2. Akan lebih efektif apabila developer pernah menangani proyek pengembangan sistem yang sejenis dari klien-klien terdahulu sehingga dapat memberikan usulan model pengimplementasian sistem baru, di samping alasan bahwa developer telah memiliki template aplikasi sistem tersebut untuk dijadikan prototype sistem baru. Hal ini akan berimplikasi kepada kemudahan dalam konstruksi sistem karena dikembangkan berdasarkan template yang sudah ada. Template bukan cuman mempermudah developer dalam mbikin aplikasi, tapi bs juga mempermudah developer dalam MENYAMPAIKAN IDE mereka. Udah jadi rahasia, faktor x yang bikin para programmer punya masalah social-disorder klo bicara ama orang awam adalah karena programmer biasanya ngomong dalam bahasa technical... Mereka biasa berbicara dengan karya. Nah, klo dah ada template (atau prototype) - njelasin ke client bakal lebih terasa mudah. "Gini lo pak yang kami maksutkan itu.. jadi aplikasi yg kami tawarkan itu bisanya seperti ini-itu-inu-iti....". Dengan mekanisme template atau prototyping, pekerjaan mendevelop akan lebih ringan banget, karena bisa jadi pengembangan aplikasi cukup dilakukan hanya dengan melakukan code refactoring. Atau, kalo emang "kebetulan" template yg didemokan emang udah cocok, yaa... tinggal ganti caption, beres deh.. hehehe...
  3. Extreme programming menuntut komunikasi antar developer dan user secara intensif dan komunikasi internal antar developer secara komprehensif, sehingga akan lebih representatif apabila tahap pengembangan sistem dilakukan di lokal yang mendukung proses komunikasi tersebut, misalnya bekerja di kantor perusahaan pemesan sistem. Untuk antar sesama tim developer itu sendiri, sudah menjadi keharusan dalam XP bahwa proses konstruksi sistem akan dilakukan secara bersama-sama di tempat yang sama, karena hampir semua kegiatan development dalam konstruksi dikerjakan secara paralel dan pipelining. Dalam agile manifesto (http://www.agilemanifesto.org) disebutkan, komunikasi jauh lebih efektif daripada dokumentasi yang bertele-tele. Bener tuh.. sekarang nostalgia aja... siapa yang pernah bikin DFD.. coba serahin DFD yg pernah sampeyan bikin ke teman programmer sampeyan trus suruh temen sampeyan tsb utk bikinin aplikasi berdasarkan desain dalam DFD itu. ... kemungkinan besar teman programmer sampeyan bakal nolak karna bingung ...
Ya, XP itu akan semakin matang jika developer selalu belajar dari pengalaman-pengalaman pengembangan sistem yang pernah dilakukannya dulu... Anda seorang developer yang (masih ) tanpa pengalaman? Tidak usah berkecil hati. Siapa bilang anda tanpa pengalaman? Pengalaman developing itu bukan mesti harus dalam wujud *berapa kali saya ngerjain proyek software development* - tapi bisa juga dalam wujud pembelajaran, pengalaman orang lain, sharing cerita, dll. Bahkan pengalaman ndevelop software non-profit (misal : tugas kuliah, tugas temen-temen, ato tugas pemrograman utk calon pacar tercinta...-hehehe-) - itu juga merupakan PENGALAMAN BERHARGA. Pengalaman keberhasilan, pengalaman kegagalan, pengalaman dipuji, maupun pengalaman dicaci-maki - itu juga pelajaran berharga bagi kita...

Extreme Programming menuntut kematangan mental developer. Dan mental itu bukanlah sesuatu yang bisa kita pelajari hanya dengan membaca. Musti kita lakukan!

0 comments:

Posting Komentar