Prinsip Pareto atau prinsip 80/20

Satu nilai lagi yang saya dapat dari Dynamic Systems Development Method (DSDM) adalah Pareto Principle.

Tanpa sengaja minggu ini saya jalan-jalan ke toko buku dan menemukan buku, "Living the 80/20 Way" yang ditulis Richard Koch. Hal ini berarti tepat ketika pada hari yang sama saya baca sebelumnya di Internet tentang prinsip yang sama yaitu prinsip pareto yang digunakan sebagai nilai pada DSDM. Awalnya saya ragu apa yang dimaksud buku tersebut adalah pareto principle yang saya baca di Internet karena di buku tersebut tidak ada penjelasan sejarah tentang prinsip tersebut. Setelah beberapa bagian penting buku dibaca, ternyata itu buku kedua Koch tentang prinsip 80/20. Tidak lama saya menemukan buku pertamanya yaitu "The 80/20 Principle", dan dibuku tersebut dijelaskan mengenai prinsip 80/20 mulai dari awal. Barulah jelas bahwa prinsip yang dimaksud adalah memang prinsip pareto.

DSDM percaya pada filosofi prinsip Pareto ini, seperti yang dinyatakan dalam pernyataan berikut:

"A fundamental assumption of the DSDM approach is that nothing is built perfectly first time, but that 80% of the solution can be produced in 20% of the time it would take to produce the total solution."

Prioritaskan dengan MoSCoW

Saya belum pernah mempelajari Dynamic Systems Development Method (DSDM), sebuah Agile methology yang banyak dipakai di Eropa (karena memang metodologi ini lahir disana). Tapi proses belajar saya pada Agile methodology, mengantarkan kepada cara memprioritaskan dengan metode metode MoSCoW yang ada pada DSDM.

Methode MoSCoW merupakan cara pembagian prioritas dengan level yang ditentukan untuk suatu kebutuhan (requirement/customer need), fungsi dari produk ataupun bagian dari proyek yang akan dibuat. MoSCoW sebenarnya adalah singkatan dari Must, Should, Can, Won't yang merupakan tingkatan pada suatu item yang diprioritaskan.

• MUST berarti sesuatu yang harus dimiliki (MUST have this)
• SHOULD berarti harus dimiliki jika memungkinkan (SHOULD have this if at all possible)
• CAN berarti dapat dimiliki jika tidak berefek pada yang lain (CAN have this if it does not effect anything else)
• WON'T berarti tidak perlu dimiliki, tapi mungkin nanti (WON'T have this time but would like in the future)

Pemriositasan sebaiknya dilakukan pada fungsi ditingkat yang tinggi (high level fungtionality) yaitu kebutuhan/fungsi yang belum didetailkan (masih general) misalnya waktu menentukan kebutuhan modul-modul utama pada aplikasi, dan juga pada tingkatyang lebih rendah yaitu kebutuhan/fungsi yang lebih spesifik.

Melakukan prioritas, baik dilakukan untuk menentukan bagian mana yang akan dikerjakan atau tidak, juga untuk menentukan mana akan dikerjakan lebih dulu.Prioritas fungsi atau kebutuhan pada high-level juga membantu kita untuk menentukan yang bagian mana yang merupakan out-of-scope dari project.

Komponen penting yang menjadi pertimbangan prioritas adalah project scope, kualitas, waktu, resources, dan resiko [referensi]. Komponen tersebut bisa saling berbenturan sehingga melakukan prioritas bukan hal yang mudah.

Kadang-kadang project scope tidak didefinisikan dengan detail atau jelas pada saat proyek mulai berjalan. Klien atau customer juga cenderung ingin semuanya kebutuhannya dipenuhi. Hal ini semua menyulitkan kita dalam memprioritaskan kebutuhan.

Dalam perjalanannya, prioritas suatu kebutuhan/fungsi sangat mungkin sering berubah sehingga meprioritaskan kembali (reprioritisation) jangan menjadi hal tabu. Yang perlu diwaspadai adalah banyaknya perubahan prioritas yang drastis misalnya dari level WON'T ke level MUST. Jika hal itu terjadi maka ada sesuatu yang salah dengan awal proses prioritisasi atau tujuan awal (goal) dari proyek.

Gratis: IBM DB2 Express-C Database

Seperti Oracle, IBM juga memberikan versi gratis dari produk databasenya yaitu DB2 Express.
Database DB2 Express-C (community edition) adalah versi gratis dari DB2 Express, bedanya DB2 Express-C hanya boleh digunakan pada mesin sampai dengan 2 CPU dan memory 4 GB saja, dan tentu tidak mendapatkan support komersial dari IBM. DB2 Express-C juga memiliki beberapa batasan fitur dibanding versi yang tidak gratis.

DB2 Express-C is completely "free" to download, develop, deploy, test, run, embed, and redistribute. For more information click here

Dengan adanya versi gratis seperti ini, ISV tidak perlu beli untuk menggunakan dan mempaketkannya bersama software yang dibuatnya. Dan jika konsumen yang membeli software membutuhkan database yang lebih powerfull, maka ISV tinggal memberikan opsi untuk updgrade databasenya ke versi yang lebih besar, dalam hal ini untuk DB2 bisa menggunakan DB2 Enterprise Server Edition (ESE).

Gratis: Oracle Database 10g Express Edition

Oracle Database 10g XE benar-benar gratis, dan dapat didistribusikan secara bebas. Jadi kita bisa buat aplikasi dan menjualnya dalam satu paket dengan Oracle Database 10g XE.

Hanya saja Oracle edisi ini memiliki batasan seperti yang tertera di situsnya:

"Oracle Database XE can be installed on any size host machine with any number of CPUs, but this free version of the world's leading database will store up to 4GB of user data, use up to 1GB of memory, and use one CPU on the host machine."

Feature-Driven Development (FDD)

FDD diinisialisasi oleh Jeff De Luca dan diperkenalkan ke publik lewat buku "Java Modeling In Color With UML" pada chapter 6, "Feature-Driven Development"

** Proses

FDD terdiri dari 5 proses atau aktifitas yaitu:

1. Pembuatan model keseluruhan (Develop an Overall Model)
2. Buat daftar fitur (Build a Feature List)
3. Rencanakan dengan fitur (Plan By Feature)
4. Desain dengan fitur (Design By Feature)
5. Membangun dengan fitur (Build By Feature)


Dan proses tambahan yang tidak kalah penting adalah (Track by Feature)

Domain Walkthough | Design | Design Inspection | Code | Code Inspection | Promote to build

** Best practises

# Domain Object Modeling
# Developing by Feature
# Individual Class (Code) Ownership
# Feature Teams
# Inspections
Inspeksi/review merupakan suatu hal yang penting dalam FDD. [http://www.featuredrivendevelopment.com/node/566]
# Regular Builds
# Configuration Management.
# Reporting / Visibility of Results

UI screen design is not a prototype.

Di perusahaan tempat saya bekerja sekarang, hampir dalam setiap proyeknya selalu membuat prototipe. Prototipe biasanya berupa screen yang dibuat dengan HTML dan javascript. Seiring dengan berjalannya proses requirement gathering dan pembuatan dokumentasi requirement, prototipe tersebut diubah-ubah mengikuti kebutuhan. Prototipe tersebut kemudian di capture dan dimasukan dalam dokumen desain software.

Apa yang client lihat adalah screen capture dari prototipe dalam sebuah dokumen. Client tidak benar-benar bisa menyentuh atau menggunakan prototipe tersebut. Biasanya client tidak jeli (malas) untuk me-review dokumen. Apalagi membayangkan 'flow of process' dari fungsionalitas software dengan hanya melihat screen-capture dan penjelasan teks. Hal ini membuat client setuju untuk mendatangani dokumen tanpa pernah merasakan bagaimana nantinya dia akan menggunakan software tersebut.

Hasilnya setelah software selesai dibuat, bisa terjadi banyak kekurangan-kekurangan yang dirasakan oleh client pada software yang diberikan (deliver). Kita bisa saja berargumen bahwa memang seperti itulah software yang diberikan, telah tertera dalam dokumentasi dan telah ditandatangani. Tapi akibatnya adalah ketidakpuasan client terhadap software yang kita berikan, karena bisa jadi kekurangan yang ada pada software adalah common functionality seperti misalnya fungsi menghapus (delete) pada suatu item.

Hal tersebut bisa terjadi sebenarnya karena prototyping sebenarnya tidak dilakukan.
Kesalahnya adalah:

• User tidak dibiarkan menggunakan sendiri 'prototype software'
• Prototipe berubah wujud menjadi UI screen design, karena hanya menjadi screen-capture yang ada dalam dokumentasi.
• Menggap tanda tangan adalah segalanya (sign-off is everything). Yaitu aggapan selama sudah dokumen sudah ditandatangani maka semuanya yang ada didokumentasi menjadi 'argueable' dan perubahan/tambahan terhadap feature akan menjadi change request.
  

Oleh karen aitu kita bisa meminimalisasi kesalah tersebut dengan membuat prototipe dan membiarkan user (client) menggunakan prototipe tersebut. Kita sebagai vendor sebaiknya hanya memberikan asistensi saat user mencoba protipe. Kesalahan atau kekurangan pada prototipe akan lebih mudah diterima oleh client dibanding, bugs yang ada pada software yang sudah diberikan atau dirilis.

Earned Value Management

Earned value management (EVM) atau earned value analysis adalah metodologi untuk mengukur dan mengkomunikasikan progress dari kinerja suatu project. Varibel penting dalam metodologi ini adalah: waktu (schedule), biaya (cost), pekerjaan (work).

Tujuan yang ingin dicapai dari metodologi ini adalah proyek yang efisien, yang berarti menyelesaikan pekerjaan dengan waktu yang ditelah ditentukan dengan meminimalisasi biaya atau materi yang dikeluarkan untuk proyek. Tujuan tersebut diharapkan dapat dicapai dengan cara mengevaluasi dan mengontrol resiko proyek dengan cara mengukur progres secara berkala.

EVM merupakan hal sudah biasa pada manajemen proyek software. Project Management Body Of Knowledge (PMBOK) memasukan EVM sebagai salah satu alat untuk memonitor proyek. Pada metodologi 'agile' juga sering digunakan earned value analysis dengan menggunakan S-curve atau burn chart sebagai alat monitoring pekerjaan atau biaya yang sudah atau belum diselesaikan.

EVM sebenarnya lebih memberikan petunjuk (guidance) pada cara mengkalkulasi biaya dari suatu project. Dengan perangkat pengontrol yang diberikan EVM diharapkan meningkatkan performance proyek dan mengurangi resiko (risk) yang terjadi.

Earned value analysis menggunakan beberapa variabel untuk memonitor performansi dari proyek yang sedang berjalan. Beberapa variable tersebut adalah:

• Planned Value (PV) atau budgeted cost of work scheduled (BCWS)
• Earned Value (EV) atau budgeted cost of work produced (BCWP)
• Actual Cost (AC) atau actual cost (AC) of work produced (ACWP)
  

Dari nilai-nilai tersebut dapat dihitung:

Schedule Variance (SV) = EV - PV
Cost Variance (CV) = EV - AC

Cost Performance Index (CPI) = EV/AC
Schedule Performance Index (SPI) = EV/AC


Nilai-nilai tersebut dimonitor selama proyek berjalan dan digambarkan dengan menggunakan grafik seperti ini.

Hasil UAT

Saya baru saja menyelesaikan UAT, dan dibawah ini beberapa kendala yang dihadapi:

• Software yang masih memiliki banyak bug karena kurang intensifnya internal test.
• Tim UAT dari client hanya terdiri dari 4 orang dan yang benar-benar terlibat hanya sastu orang.
• Tester hanya satu orang dan merupakan orang baru (orang yang tidak mengerti betul requirement)
• Tidak ada kontrol yang ketat dari project owner terhadap tester.
• Tim UAT dari vendor juga hanya satu orang, yang pekerjaannya adalah mengenalkan software, membantu testing secara teknis dan bug fixing.
• Tidak ada test scenario, yang ada adalah list modul yang akan ditest.
• Tidak menggunakan tools untuk test, sehingga retesting memakan waktu yang tidak sedikit.
• Test dilakukan di tempat client dengan keterbatasan evirontment seperti, tidak tersambungnya komputer development dengan test server.
• Repository berada di tempat saya bekerja (vendor) sementara development fase kedua yang masih berlangsung ketika UAT fase pertama dapat mengakibatkan perubahan dari code yang dihasilkan dari fase pertama.
• Birokrasi yang lama di tempat client seperti saat meminta account email untuk test.
  

Hasil keseluruan: UAT selesai dengan sukses.
Bagaimana bisa? Bisa, kuncinya adalah:

• Close relationship dengan client. Beri impresi bahwa kita selalu working on improvement.
• Selalu cepat untuk fixing bug atau solve issues.
• Jangan tekan client karena keterbatasan-keterbatasan atau problem internal yang mereka hadapi, selama mereka tidak menekan kita.
• Berikan pengertian, bahwa kendala/masalah tidak hanya datang dari vendor tapi juga dari client. Sehingga mereka tidak selalu menyalahkan kita. (Intinya sih cari alasan yang tepat deh)
• Jangan memberikan ide-ide baru untuk testing, biarkan apa yang mereka mau test tapi jangan tambah degan item yang seharusnya mereka test.
• Fokus pada fungsi utama, jika ada bug dan tidak menghalangi test berikutnya, lanjutkan test berikutnya.
• Restest semua fungsi (secara cepat) saat akhir UAT.
  

Catatan, sukses disini berarti client happy (paling tidak, mereka tidak kecewa) dan kita sebagai vendor juga akhirnya happy :-)

Sekilas tentang metodologi pembuatan software, SCRUM

Scrum adalah suatu metodologi yang mengatur (manage) proses pembuatan software.
Scrum yang dikategorikan pada agile software development methodology.
Lihat agile manifesto, untuk mengerti filosofi dibalik kata agile pada konteks software development methodology atau project management.

** Kenapa Scrum?

Scrum menarik karena scrum lebih condong pada cara me-manage proyek secara praktikal (practical process model). Lebih menuntun tim untuk melakukan hal-hal yang perlu dan menyarankan hal-hal yang tidak perlu dalam menginspeksi proses dan melakukan adaptasi terus meneus untuk menyetir arah dari proses. Tidak seperti metodologi manajemen proyek lain yang cenderung deskriptif dan heavyweight.

** Scrum Role
Orang yang terlibat dalam proses scrum dibagi menjadi 3 jenis peran (role), yaitu:

• Product Owner yaitu orang yang menentukan spesifikasi atau feature dari software yang akan di-deliver.
• ScrumMaster yang bertanggung jawab untuk mengatur scrum process selama proyek berjalan. Oleh karena itu ScrumMaster harus menguasai Scrum process. ScrumMaster adalah fasilitator, yang mempersiapkan dan memimpin pertemuan (meeting)
• Project Team (tim 7 plus minus 2) yang merupakan self-organizing team yang menjalankan project, seperti business analyst, software architect, developer, tester dan lain-lain.
  

** Teminologi ayam dan babi (chickens and pigs)

Terminologi ini dapat dijelaskan dengan lelucon dibawah ini:

A chicken and a pig decide to start a restaurant.
The pig says, "What should we call it?"
The chicken says, "How about 'Ham & Eggs'?"
The pig says, "No thanks. I'd be committed, but you'd just be involved."

Terminologi ayam (chicken) berarti orang yang berkepentingan terhadap proyek (involved) tapi tidak sepenuhnya terlibat dalam proyek.
Terminologi babi (pig) adalah orang yang terlibat sepenuhnya dalam proyek. Yang termasuk dalam kategori pig adalah anggota project team.


** Proses

Proses eksekusi proyek dengan menggunakan scrum, dapat dilihat pada gambar ini

• First meeting
• Proses scrum diawli dengan pebuatan tujuan yang akan dicapai dan product backlog.
  Product backlog dikuantisasi waktu dengan satuan hari (antara 1-20 hari)
  Product backlog merupakan ombinasi antara story-based work (pekerjaan yang berbasis use case/product feature) dan task-based work misalnya "Tambahkan validasi pada semua form"
  Product backlog diprioritaskan oleh product owner.
  
• Product backlog yang berisi list yang diprioritaskan dari fitur-fitur atau perubahan yang akan ada pada produk.

• Sprint planning meeting
• Meeting untuk product owner, scrum team dan orang-orang yg berkepentingan.
  
• Menentukan sprint goal yaitu tujuan yang ingin dicapai pada scrum sprint berikutnya (30 hari kedepan).
  Sprint goal biasa adalah minimum fungsinalitas yang harus dicapai.
  Jika sprint goal tidak dicapai maka dilakukan abnormal termination
• Membuat sprint backlog yaitu list dari pekerjaan yang akan dilakukan selama sprint.
  Sprint backlog merupakan bagian produck backlog yang didetailkan.
  Sprint backlog dikuantisasi waktu berdasarkan jam (bukan hari yaitu antara 1-16).
  Sprint backlog harus tranparan untuk semua orang dalam tim
• Meeting yang tidak lebih dari 8 jam saja.
  Dengan 4 jam pertama adalah waktu yang digunakan untuk Product Owner menjelaskan atau presentasi tentang prioritas dari product backlog.
  Kemudian tanya jawab dari tim tetang isi, maksud, tujuan dari item yang ada di product backlog.
• Empat jam berikutnya adalah sesi untuk tim merencanakan Sprint.
• Fokus pada melakukan pekerjaan bukan berfikir mengenai bagaimana mengerjakannya.
  

• Daily Scrum meeting (Inspect and adapt cycle)
• Meeting harian selama tidak lebih dari 15 menit
• Yang boleh bicara dalam tim ini adalah scrum master dan anggota tim (pigs)
• Orang lain yang bekepentingan (chickens) dapat ikut dalam tim tetapi tidak boleh berkomunikasi (berbicara)
• Scrum master menanyakan 3 pertanyaan dari kepada anggota tim:
• Apa yang sudah kamu lakukan kemarin (selama 24 jam kebelakang)?
• Apa yang akan dikerjakan pada esok hari (24 jam mendatang)?
• Hal apa yang bisa menghentikan pekerjaan besok hari (kendala)?
  

• Sprint review meeting
• Meeting setelah aktivitas selama 2 minggu atau 1 bulanan (Sprint) berakhir, yang kemudian diikuti oleh sprint planning meeting untuk Sprint berikutnya.
• Meeting sebagai review atas Sprint yang sudah dilaksanakan.
• Memperbarui (update) sprint backlog yang merefleksikan berapa lama waktu yg dibutuhkan untuk menyelesaikan pekerjaan (task)
  

• Sprint retrospective meeting
• Meeting setelah sprint review meeting dan sprint planning meeting ScrumMaster dengan tim untuk merevisi proses dan cara kerja Scrum, proses development agar Sprint berikutnya lebih efektif dan enjoyable.
• Meeting ini sebaiknya tidak lebih dari 3 jam.
  

** Burndown charts

Burndown charts adalah grafik yang menunjukan seberapa banyak waktu yang dibutuhkan untuk menyelesaikan proyek. Grafik ini merefleksikan progress dari proyek.

Y-axis: Sisa waktu yang diperlukan untuk menyelesaikan pekerjaan (dalam jam)
atau jumlah item pekerjaan yang masih harus diselesaikan
X-Axis: Tanggal

Referensi tentang burndown chart yang cukup detail bisa dibaca di artikel "Earned-Value and Burn Charts"

** Artikel lain
Adaptive Project Management Using Scrum.
File presentasi yang bagus tentang SCRUM