Dalam generative programming, kita juga akan menemukan konsep Aspect-Oriented Programming serta Generic Programming. Dapat dikatakan bahwa dengan mempelajari generative programming, kita akan mempelajari berbagai konsep/paradigma sekaligus. Ini dapat menjadi nilai tambah tersendiri.

Bagi yang berminat mempelajari Generative Programming dapat membaca tesis Generative Programming – Principles and Techniques of Software Engineering Based on Automated Configuration and Fragment-Based Component Models

Berbagai paper/jurnal tersedia secara online, maupun buku Generative Programming edisi cetak.

Pada dasarnya, Lean memiliki 7 prinsip, yaitu:

1. Eliminate waste.

Buang apapun yang tidak memberi nilai tambah bagi produk yang dapat dirasakan oleh konsumen.

2. Amplify learning.

Dalam software development, kita berbicara Lean Development bukan Lean Production. Development berbeda dengan production. Development mirip dengan membuat resep masakan, sedangkan production mirip dengan memasak masakan. Jadi dalam proses development dibutuhkan pemikiran, inovasi, percobaan, dsb yang proses tersebut merupakan proses pembelajaran. Belajar, belajar, dan terus belajar.

3. Decide as late as posible.

Dunia terus berubah, maka sepatutnya bila keputusan tidak diambil secara tergesa-gesa, maka keputusan tersebut diharapkan semaksimal mungkin supaya sesuai dengan fakta yang ada, bukan keputusan yang berbau spekulasi.

4. Deliver as fast as posible.

Dulu saat era web 2.0 sedang booming, ada mantra yang cukup terkenal, yaitu ‘realase early release often’. Dengan pengembangan yang cepat, kita bisa menunda keputusan (sejalan dengan prinsip ke-3) dan kita bisa memperoleh feedback yang reliabel. Pada umumnya siklus yang terjadi adalah: Design, implement, feedback, improve.

5. Empower the team.

Karena pengambilan keputusan ada di akhir dan proses eksekusi sangat cepat, tidak mungkin dilakukan pengaturan secara terpusat. Lean menggunakan ‘pull techniques’ untuk penjadwalan pekerjaan dan memiliki mekanisme pensinyalan lokal yang memungkinkan masing-masing pekerja memberitahu apa yang harus dikerjakan berikutnya. Mekanisme ‘Pull’ dalam lean development merupakan perjanjian untuk membuat perangkat lunak yang lebih baik secara bertahap dalam interval tertentu. Pensinyalan lokal terjadi melalui chart, pertemuan harian, integrasi berkala, dan pengujian (testing) yang komprehensif.

6. Build integrity in.

Perangkat lunak dengan integritas, maka dia memiliki arsitektur yang koheren, usability yang baik, sesuai dengan tujuan, dan dapat beradaptasi dengan perkembangan jaman.

7. See the whole.

Integritas pada suatu sistem yang kompleks membutuhkan pengetahuan dari berbagai bidang yang beragam. Tidak bisa berpikir untuk mengembangkan suatu bagian tertentu dari sistem tanpa memperhatikan dampaknya yang terjadi pada bagian lain.

Sumber:
“Lean Software Development: An Agile Toolkit” (Mary Poppendieck, Tom Poppendieck), Addison Wesley – 2003

]]> http://agilini.us/2010/10/23/lean-software-development/feed/ 0 http://agilini.us/2010/10/20/dsl-dengan-interpreter-pattern/ http://agilini.us/2010/10/20/dsl-dengan-interpreter-pattern/#comments Wed, 20 Oct 2010 08:10:44 +0000 Agi Putra Kharisma http://agilini.us/?p=178 Beberapa waktu yang lalu saya sempat menulis tentang Membuat DSL Tanggal Dengan Scala. Kali ini sebenarnya hampir sama, hanya saja implementasinya dengan bahasa Java dan memiliki grammar yang sedikit berbeda. Kebetulan sedang membaca-baca tentang behavioral design pattern, salah satunya adalah interpreter pattern, maka DSL yang ini dibuat menggunakan interpreter pattern. Karena saya sendiri masih belum begitu paham dengan konsep interpreter pattern, maka tidak ada jaminan bahwa code yang saya tulis telah memenuhi kriteria interpreter patter.
Berikut ini grammar-nya:


Grammar DSL Tanggal

Contoh implementasi DSL-nya:

Kemarin dikurangi 3 tahun ditambah 7 bulan

Hampir mirip dengan versi Scala di tulisan terdahulu, hanya saja DSL kali ini tidak menggunakan Conjunction (kalau yang versi Scala ada Conjunction “dan” nya).
Dalam interpreter pattern, semua expression dijadikan class, baik non-terminal expression maupun terminal expression.
Beruikut ini source code-nya:

Code di atas bukanlah code untuk produksi, mungkin lebih cocok sebagai prototype saja, hanya sebagai contoh bagaimana kita membuat DSL dengan interpreter pattern. Code di atas sangat tidak efisien dan harus di-refactor ulang, jadi jangan coba-coba memasukannya ke dalam production code, karena secara coding tidak elegan dan performanya juga payah. Silahkan dicoba sendiri dan Anda akan mengetahui bahwa waktu eksekusi code tersebut tergolong lambat.

]]> http://agilini.us/2010/10/20/dsl-dengan-interpreter-pattern/feed/ 0 http://agilini.us/2009/10/11/the-pomodoro-technique/ http://agilini.us/2009/10/11/the-pomodoro-technique/#comments Sun, 11 Oct 2009 11:27:42 +0000 Agi Putra Kharisma http://agilini.us/?p=96

Remember, Time is a greedy player who wins without cheating, every round! –Baudelaire

Inti dari teknik pomodoro adalah bagaimana kita memanage waktu sehingga dapat meningkatkan fokus dan konsentrasi, meningkatkan dan mempertahankan motivasi, meningkatkan kinerja maupun proses belajar.

Konsep yang digunakan sangat sederhana sekali. Pomodoro sejatinya adalah sebuah timer untuk memasak dengan interval 25 menit. Nama pomodoro sendiri diambil dari timer yang berbentuk buah tomat (dalam bahasa italia, tomat = pomodoro).



The Pomodoro Technique

Pomodoro tradisional berdurasi 30 menit (25 menit kerja + 5 menit istirahat). Satu pekerjaan dapat membutuhkan waktu lebih dari 25 menit, sehingga membutuhkan lebih dari satu pomodoro. Misal, Anda membutuhkan waktu 60 menit untuk menyelesaikan suatu pekerjaan, maka Anda memerlukan 3 pomodoro. Supaya lebih efektif, karena keterbatasan fisik dan psikologis manusia, sebaiknya Anda melakukan istirahat yang lebih panjang untuk setiap 4 pomodoro, misal 15-30menit.

Ada berbagai teknik atau aturan untuk mengoptimalkan teknik pomodoro, misalnya untuk pekerjaan yang membutuhkan lebih dari 5-7 pomodoro, sebaiknya pekerjaan tersebut dipecah-pecah menjadi sub-sub yang lebih kecil supaya lebih mudah dimanage. Untuk penjelasan yang lebih lengkap tentang pomodoro, Anda dapat membaca buku pomodoro berjudul The Pomodoro Technique [PDF].

Bila Anda bekerja dengan komputer, Anda dapat memanfaatkan beberapa perangkat lunak yang dirancang untuk mempraktekan teknik pomodoro. Pengguna Mac OS dapat menggunakan Pomodoro Desktop, sedangkan pengguna sistem operasi lainnya (termasuk Mac), Windows maupun Linux dapat menggunakan focus booster (butuh Adobe AIR).



Pomodoro Technique in 5 minutes
View more presentations from Staffan Nöteberg.
]]> http://agilini.us/2009/10/11/the-pomodoro-technique/feed/ 2 http://agilini.us/2009/10/05/berbagai-framework-untuk-behaviour-driven-development/ http://agilini.us/2009/10/05/berbagai-framework-untuk-behaviour-driven-development/#comments Mon, 05 Oct 2009 15:52:29 +0000 Agi Putra Kharisma http://agilini.us/?p=81 Behaviour-Driven development (BDD) secara prinsip kurang lebih sama dengan test-driven development (TDD), hanya saja (bila Anda mengembangkan perangkat lunak secara object-oriented) BDD lebih fokus pada pengujian terhadap perilaku suatu objek, bukan mengenai perihal seperti apa objek itu (misal: struktur objek). Ada cukup banyak framework yang dapat kita gunakan untuk mempermudah pengembangan perangkat lunak secara BDD. Bagi yang masih asing terhadap BDD namun sudah pernah mengenal tentang teori BDD, atau siapapun Anda yang merasa tertarik tentang topik ini, ada baiknya untuk mencoba mengimplementasikannya secara langsung dengan bantuan framework yang Anda sukai.
• Cucumber (Ruby) http://cukes.info
• Rspec (Ruby) http://rspec.info
• JBehave (Java) http://jbehave.org
• easyb (Java) http://www.easyb.org
• specs (Scala) http://code.google.com/p/specs
• ScalaTest (Scala) http://www.scalatest.org
• conducta (Clojure) http://code.google.com/p/conducta

Selamat mencoba BDD. Red – Green – Refactor – Red – Green – Refactor – …

O ya, kalau ada yang tahu framework BDD lainnya, silahkan berbagi melalui komentar di posting ini.

]]> http://agilini.us/2009/10/05/berbagai-framework-untuk-behaviour-driven-development/feed/ 1 http://agilini.us/2009/09/27/generalizing-specialist/ http://agilini.us/2009/09/27/generalizing-specialist/#comments Sun, 27 Sep 2009 13:33:08 +0000 Agi Putra Kharisma http://agilini.us/?p=76 Salah satu masalah besar dalam industri IT adalah spesialisasi skill yang kebablasan. Dalam suatu organisasi, bisa jadi terdapat departemen-departemen yang beranggotakan spesialis basis data, spesialis analisis bisnis, spesialis manajemen projek, spesialis Java/pemrograman, dsb. Pendekatan seperti ini didasarkan pada paradigma bernama Taylorism (Frederick Taylor). Idenya adalah memecah-mecah proses pabrikasi menjadi tahap-tahap yang terpisah, karena hal ini dianggap lebih baik daripada menyerahkan kepada individu yang memiliki banyak kemampuan sekaligus. Taylorism terbukti sukses pada proses manufaktur, tapi tidak demikian untuk pengembangan perangkat lunak.

Masalah yang terjadi dalam pengembangan perangkat lunak, seringkali para spesialis kesulitan dalam bekerjasama dengan spesialis lainnya atau bahkan dengan spesialis yang sebidang. Mengapa demikian? Karena spesialis tersebut tidak memiliki latar belakang pengetahuan yang memadai untuk dapat mengerti masalah yang sedang dihadapi oleh spesialis lainnya, mereka cenderung terlalu fokus dengan bidang yang digelutinya namun celakanya dia mengabaikan hal-hal mendasar lain yang juga penting. Alhasil, hal tersebut menjadi hambatan mereka dalam berkolaborasi.

Apa solusinya? Generalizing specialist (GS). GS adalah seseorang yang memiliki pengetahuan tentang bagaimana suatu sistem secara keseluruhan dapat bekerja. Dia memiliki pengetahuan tentang apa yang sedang dikerjakan oleh rekan kerjanya. Dengan pengetahuan itu, dia akan memberikan apresiasi lebih terhadap pekerjaan rekannya tersebut. Sehingga terbentuk tim dengan kinerja yang baik.

Adalah hal yang hampir mustahil untuk tahu banyak hal dan menguasai semuanya, sedangkan sangat mungkin bila seseorang mengetahui banyak hal dan menguasai secara mendalam beberapa diantaranya.

GS bukan sekedar generalis. Generalis adalah orang yang tahu segala hal tapi tidak satupun yang dia dalami, cuma kulit luarnya saja. Sedangkan GS adalah orang yang tahu banyak hal namun tetap memiliki keahlian khusus yang mendalam pada beberapa hal.

Dalam dunia rekayasa perangkat lunak dengan metodologi agile, semakin sedikit spesialis yang dapat bertahan, mau tidak mau mereka harus melebarkan ilmu mereka.

Kesimpulannya, kita kitak bisa serta merta menyamakan antara industri manufaktur dengan industri IT (pengembangan perangkat lunak), sehingga sistem yang berjalan baik pada industri manufaktur, seperti Taylorism, tidak dapat diadopsi begitu saja ke dalam industri IT. Hal lain yang masih menarik perhatian saya saat ini adalah bagaimana kita mengimplementasikan Lean Software Development, karena Lean berangkat dari industri manufaktur, yaitu pabrik mobil Toyota, namun kini IBM sepertinya telah sukses menerapkan Lean.

Untuk lebih jelas tentang GS, Anda dapat membaca buku “The Object Primer: Agile Model-Driven Development with UML 2.0 Third Edition” yang ditulis oleh Scott W. Ambler.

]]> http://agilini.us/2009/09/27/generalizing-specialist/feed/ 0 http://agilini.us/2009/08/21/agile-dan-extreme-programming-dalam-kartun-dilbert/ http://agilini.us/2009/08/21/agile-dan-extreme-programming-dalam-kartun-dilbert/#comments Fri, 21 Aug 2009 07:16:27 +0000 Agi Putra Kharisma http://agilini.us/?p=35


Dilbert - Agile Programming





Dilbert - Extreme Programming (1)





Dilbert - Extreme Programming (2)





Dilbert - Extreme Programming (3)


Sumber: “Dilbert” on Extreme and Agile Programming
]]> http://agilini.us/2009/08/21/agile-dan-extreme-programming-dalam-kartun-dilbert/feed/ 1 http://agilini.us/2009/08/21/beberapa-mitos-seputar-agile/ http://agilini.us/2009/08/21/beberapa-mitos-seputar-agile/#comments Fri, 21 Aug 2009 05:47:20 +0000 Agi Putra Kharisma http://agilini.us/?p=28
8. Silver bullet, dapat digunakan untuk menyelesaikan semua permasalahan.

Tidak semua permasalahan dapat diselesaikan dengan agile. Kondisi dan kultur tim juga berpengaruh terhadap keberhasilan penerapan agile.

9. Dengan agile, kita dapat melakukan apapun sesuka hati, tanpa aturan yang jelas.

Agile membutuhkan kedisiplinan yang sangat ketat dan aturan yang jelas, karena agile didesain untuk menghadapi lingkungan yang sangat dinamis. Tanpa ini semua, agile tidak akan pernah berhasil.

10. Tidak memiliki perancangan, dokumentasi, arsitektur, dsb.

Seperti metodologi lain pada umumnya, agile juga membuat perancangan, dokumentasi, arsitektur, dsb. Justru semua ini dilakukan secara transparan dan menitik beratkan pada kebutuhan, kecepatan dan kualitas. Memang kadang kala agile menghasilkan dokumentasi yang minimalis, tapi bukan berarti dokumentasi tersebut dibuat minimalis dengan cara mengabaikan banyak hal esensial sehingga tidak dapat merepresentasikan sistem yang dibangun secara komprehensif. Hal ini karena agile selalu berusaha meminimalisir pemborosan tenaga dan waktu, sehingga menghasilkan iklim kerja yang efektif dan efisien.

11. Menghasilkan produk yang tidak terjamin kualitasnya.

Pengujian (testing) adalah bagian yang krusial pada agile. Salah satu parameter perangkat lunak yang berkualitas adalah perangkat lunak yang telah lolos uji. Pada metode tradisional, pengujian kadang kala malah dianggap remeh dan hanya untuk seremonial semata.

12. Tidak digunakan oleh perusahaan-perusahaan besar.

Berdasarkan Forrester Research, 14% enterprise di Amerika Utara dan Eropa telah menggunakan agile, dan 19% lainnya tertarik dan berencana untuk menggunakan agile di masa mendatang. Google dan Yahoo adalah dua dari sekian perusahaan ternama yang telah menggunakan agile.

Dan masih banyak lagi mitos seputar agile…

Ada berbagai jenis metodologi yang digunakan dalam rekayasa perangkat lunak, salah satunya adalah agile. Agile development sendiri masih mencakup berbagai metodologi, antara lain Scrum, Extreme Programming, Agile Unified Process (AUP), Feature-Driven Development, Lean Development, Dynamic System Development Method (DSDM), OpenUP, Agile Modeling, Crystal, dsb. Ciri khas dari semua metodologi agile ini adalah sifat iterative dan incremental, hal ini sangat berbeda dengan metodologi tradisional (baca: waterfall). Sebagai catatan, Scrum adalah metodologi (atau lebih tepatnya framework) yang paling banyak digunakan dan paling berkembang hingga saat ini.

Perubahan yang cepat, kebutuhan pasar yang terus meningkat, menuntut untuk menggunakan suatu metodologi yang fleksibel, responsif, adaptif terhadap perubahan, dan terjamin kualitasnya. Agile memberikan solusi terhadap masalah ini, perusahaan besar seperti Google, Yahoo, Microsoft, Cisco, Siemens, Motorola telah mengembangkan agile untuk meningkatkan bisnis dan menjaga supaya perusahannya tetap kompetitif di pasar.

Secara cepat, kini agile mulai beranjak menjadi de-facto standard untuk proses pengembangan perangkat lunak.