Meluruskan Mitos CMMI
Posted by Endy Muhardin | Filed under Manajemen
Di milis manajemen proyek IT sedang rame diskusi tentang CMMI dan Scrum.
Seperti layaknya diskusi yang rame, perdebatan dibumbui dengan segala macam mitos dan ‘FUDification’.
Berikut adalah tanggapan saya tentang mitos yang berkembang mengenai CMMI, dicopy-paste dari posting milis dengan sedikit penyesuaian.
Beberapa mitos yang akan diluruskan :
- CMMI adalah metodologi manajemen proyek yang cenderung waterfall
- CMMI mewajibkan kita bikin banyak dokumen
Pada artikel ini, kita akan meluruskan mitos-mitos tersebut.
CMMI = metodologi, cenderung waterfall
CMMI bukanlah metodologi manajemen proyek seperti
Scrum, IBM Rational Unified Process, XP, apalagi Waterfall.
CMMI sebetulnya sudah pernah saya jelaskan di posting saya sebelumnya.
Tapi untuk lebih menyederhanakan lagi, kita bisa analogikan CMMI seperti akreditasi perguruan tinggi.
Kalau kita mau daftar kuliah, biasanya kita cari tahu akreditasi kampus yang kita tuju.
Semakin tinggi akreditasinya, semakin tinggi ekspektasi kita terhadap kualitas perguruan tinggi tersebut.
Akreditasi perguruan tinggi ditentukan oleh banyak hal, diantaranya :
- berapa jumlah dosen yang S3
- berapa karya ilmiah dan penelitian yang dihasilkan dalam satu periode
- dsb
Untuk menentukan suatu kampus mendapat level A, B, atau lainnya, maka ada tim assessor yang akan memeriksa apakah kampus tersebut sudah memenuhi apa yang dipersyaratkan.
Demikian juga dengan CMMI, berisi seperangkat checklist yang bentuknya kira-kira seperti ini:
| Level | Process Area | Ok | Not Ok |
|---|---|---|---|
| 2 | Requirement Management | ||
| 2 | Configuration Management | ||
| 2 | Measurement and Analysis | ||
| 2 | Project Planning | ||
| 2 | Project Management and Control | ||
| 2 | PPQA | ||
| 2 | Supplier Agreement Management |
Nah, checklist itu nanti akan dicentang sesuai dengan kapabilitas perusahaan yang diperiksa.
Adapun urusan Scrum, Waterfall, XP, whatever metodologi yang kita gunakan,
hanyalah mencakup sebagian saja dari CMMI.
CMMI itu model untuk menggambarkan organisasi pembuat software yang mature. Apa itu mature? Salah satu karakteristiknya adalah konsistensi. Perusahaan yang gak mature, hasil kerjanya gak konsisten. Project A ontime, Project B molor 3 tahun. Project X bugnya dikit, Project Y isinya bug doang gak ada fiturnya.
Kalau kita bisa mengeksekusi project dengan sukses, kita hanya bisa lulus CMMI level 2.
Untuk bisa mendapatkan level 3, kita harus bisa mengeksekusi project dengan sukses secara konsisten.
Untuk bisa konsisten, maka kita harus bisa menduplikasi project sukses ke seluruh perusahaan.
Jadi, kalau kita sudah sukses pakai Scrum di project kita sekarang, tetap saja baru level 2.
Hanya setelah kesuksesan Scrum bisa direplikasi di keseluruhan perusahaan, barulah bisa level 3.
Seperti juga halnya replikasi resep McDonalds ke seluruh cabang, untuk bisa mereplikasi project sukses ke seluruh perusahaan,
dibutuhkan kegiatan tambahan di level organisasi, misalnya :
- Menulis SOP (OPD)
- Membuat program pelatihan internal (OT)
- Selalu menganalisas prosedur yang sekarang berlaku, supaya bisa diimprove (OPF)
Yang di dalam kurung adalah process area yang bersesuaian di CMMI.
Berurusan dengan perusahaan yang mature akan mengurangi resiko di client.
Apa itu resiko?
Buat orang awam seperti kita, resiko adalah simply sekian persen
kemungkinan adanya masalah di kemudian hari.
Nah, ada perspektif finansial yang kita orang teknis biasanya gak kepikiran.
Buat orang finance, persentase tersebut bisa diuangkan.
Misalnya kita mau bikin aplikasi costnya 100 M, uangnya minjem ke bank.
Karena pada dasarnya bank gak mau rugi, 100 M itu akan diasuransikan sama dia.
Jadi kalo projectnya bubaran, kita gak sanggup bayar, hutangnya akan
ditalangin sama asuransi.
Asuransi akan lihat, kita pakai vendor siapa.
Kalo vendornya gak mature (baca: resiko tinggi) maka premi asuransinya
akan tinggi.
Akibatnya, biaya pinjaman kita (cost of money) juga tinggi.
Bisa aja kita bayar 100 M (pokok) + 20 M (bunga) + 20 M (asuransi)
Padahal kalo vendornya mature, premi asuransinya cuma 5 M.
Nah, jadi urusan resiko dan maturity ini bukan semata jargon2 aja,
tapi ada duit beneran yang tersangkut di dalamnya.
Demikianlah mitos pertama, CMMI bukan metodologi manajemen proyek, melainkan manajemen keseluruhan perusahaan.
CMMI mewajibkan kita bikin banyak dokumen
CMMI sama sekali tidak mengharuskan kita bikin dokumen apa-apa.
Yang ada, kita harus :
- melakukan project planning (level 2)
- melakukan project monitoring & control (level 2)
- mendefinisikan project life cycle : bisa waterfall, scrum, spiral,
cowboy programming juga boleh
Planning : merencanakan apa yang akan dilakukan
Monitoring : melihat kondisi aktual, apakah sesuai dengan plan
Control : melakukan tindakan kalau kondisi aktual tidak sesuai dengan plan
Nah, kita harus membuktikan bahwa kita benar2 melakukan apa yang disuruh.
Gimana cara membuktikannya?
Kita bisa :
1. Tunjukin dokumen hardcopy, atau
2. Tunjukin bahwa kita melakukan planning, monitoring, dan control di
aplikasi yang kita pake (Redmine, planningpoker.com,
pivotaltracker.com, basecamphq.com, fogbugz, whatever)
Nah, dari 2 cara di atas, kalo kita benar-benar melakukan, akan
lebih mudah menunjukkan yang #2.
Tapi kalo akal2an, sebenarnya gak planning tapi mau ngakunya planning,
akan lebih mudah memalsukan yang #1.
Soalnya #2 gak bisa di-back-dated, sedangkan #1 bisa.
Jadi, fokusnya lebih ke melakukan proses, bukan membuat dokumen
Kemudian, ada kesalah-kaprahan juga yang umum terjadi tentang planning.
Planning itu tidak sekali saja lalu dipakai sepanjang project.
Project plan harus mencerminkan kondisi yang terbaru dari project.
Misalnya, kita bikin plan awal (versi 1) selesai 3 bulan.
Ternyata waktu monitoring di akhir bulan 1, kita udah tau bahwa gak
bakalan selesai dalam 2 bulan sisanya.
Kita harus melakukan controlling terhadap projectnya.
Tindakan control bisa macam2, bisa kita tambah orang biar tetap
selesai dalam 3 bulan,
bisa juga revisi plannya sehingga mencerminkan kondisi setelah 1 bulan berjalan.
UUD 45 aja bisa diamandemen, masa project plan gak bisa 
Contoh lain, mengelola requirement (Requirement Management), Level 2.
S.P 1.1 : Understand Requirement : kita harus memastikan bahwa
requirement dipahami.
Gimana cara membuktikannya?
Kalo prosesnya beneran dijalanin, kita bisa tunjukkan email dari BA ke
Client yang isinya
mengkonfirmasi pemahaman BA tentang requirement yang diminta Client.
Atau kalo seperti Scrum, Clientnya hadir di ruangan yang sama, gak
nyatet apa2, rekaman audio juga boleh.
Intinya, ada sesuatu yang bisa ditunjukkan ke auditor bahwa kita sudah
Understanding Requirement.
Kalo prosesnya palsu, artinya sebenarnya gak dilakukan, tapi mau lulus
Level 2, maka dibuatlah dokumen palsu.
Bentuknya biasanya review report, isinya item2 requirement, lalu nanti
ada tandatangan client palsu.
So, overhead dokumen (mis: review report) itu ada kalo kita memalsukan proses.
Selama kita beneran menjalankan apa yang disuruh, pasti ada evidence
bahwa kita menjalankan,
entah itu bentuknya chat YM, email, Skype call, apalah terserah, tidak
ada CMMI mewajibkan formatnya harus mp3 atau apa.
SP 1.2 : Obtain Commitment to Requirement : semua pihak harus commit
terhadap requirement yang sudah dibuat.
Gimana cara membuktikan bahwa kita comply dengan SP ini?
Paling gampang, BA kirim email ke Client, “Pak, di iterasi ini, kita
kerjakan req #12, #14, sama #15 ya. #13 pending dulu aja”
Client reply, “Ok”
That’s it, tunjukin emailnya ke auditor, beres.
Kalo gak dijalanin, nanti ribet dikemudian hari, usernya client bilang
A, bosnya user bilang A+, programmer bilang C, PM bilang lain lagi.
Sekali lagi, selama prosesnya dilakukan, emailnya pasti ada.
Kalo prosesnya palsu, atau clientnya gaptek gak kenal email, ya
dibuatlah dokumen requirement sign off.
Orang2 tandatangan. Dokumennya dijadikan evidence.
SP 1.3 : Manage Requirement Changes : kalo requirement berubah, harus
di-manage.
Apa itu dimanage? Harus jelas :
- apa yang berubah
- siapa yang minta berubah
- siapa yang approve
- apa impactnya ke schedule/cost/effort/cuaca hari ini
Apa buktinya? Email boleh, chat log boleh, rekaman cctv boleh.
Ok, lalu kenapa semua harus ada evidence ??
Auditor kita di Sigma dulu becandanya gini,
In God We Trust, everybody else brings data.
Jadi, CMMI = banyak dokumen hanyalah mitos belaka. Untuk bisa melakukan verifikasi, auditor tentu butuh melihat evidence. Di jaman modern seperti sekarang, evidence bentuknya tidak harus dokumen tertulis yang dibuat dengan aplikasi office.
Enterpreneur, software developer, live in Bogor, Indonesia.
August 24, 2011 at 2:57 pm
Thank you for sharing dan sudah meluruskan. CMMI ternyata menarik. Tapi apakah organisasi tetap bisa tidak bikin dokumen apa-apa di level 5? Di level 4 saja proyek harus bisa dinilai secara kuantitatif. Untuk bisa menilai secara kuantitatif bukannya kita perlu dokumen?
August 24, 2011 at 3:36 pm
Level 4 itu Quantitatively Managed, artinya organisasi (dan semua project di dalamnya) dikelola dengan menggunakan data, bukan lagi penilaian subjektif.
Bayangkan kita punya company dashboard yang menampilkan daftar semua project yang sedang jalan, masing-masing projectnya menampilkan :
- jumlah task (selesai,in progress,belum start)
- jumlah open bug
- test coverage
- trend build result
- schedule variance saat ini (perbedaan durasi plan vs actual)
- effort variance saat ini (perbedaan effort plan vs actual)
- dan metrik lain yang dirasa perlu
Berdasarkan info di dashboard inilah kita kelola projectnya. Misalnya kita lihat bahwa jumlah open bug sudah mepet ambang batas kritis, maka kita take action.
Level 5 : Optimizing.
Kalo di Level 4 kita sebatas manage (menjaga agar sesuai jalur), maka di level 5, data2 ini kita gunakan untuk mencari bottleneck sehingga organisasi bisa improve.
Jadi, intinya level 4 ke atas adalah :
- mengumpulkan dan menganalisa data (sebenarnya sudah dilakukan di Level 2, PA Measurement & Analysis)
- menggunakannya untuk manajemen
- menggunakannya untuk improve
Tidak ada disebut harus bikin dokumen, yang harus adalah mengumpulkan dan menganalisa data.
Lalu dari mana datangnya data?
Ya dari tools yang kita pake dong.
Contoh sederhana, kalau kita pakai Continuous Integration tools semacam Jenkins lengkap dengan JUnit, Sonar, Gerrit, dsb, maka data-data tersebut sudah ada tinggal dipanen dan diolah.
August 25, 2011 at 1:34 pm
Ok itu make sense sih untuk process area development. Tapi kan process area di CMMI gak cuma development saja. Kalau di process management dan project management kan yang dinilai secara kuantitatif bukan defect saja. Contoh: ROI kas pasti dihitung secara kuantitatif di process area project management. Apa ada tool yang mengotomasi dan ngeluarin nilai ROI seperti Jenkins?
August 25, 2011 at 2:48 pm
Sebetulnya tools apa yang digunakan sudah diluar scope CMMI. Yang penting datanya ada dan digunakan. Tools/software available for gathering/analyzing/reporting metrics is left as an exercise for the reader/implementor
Tapi tentunya jawaban seperti di atas tidak banyak added-valuenya ;p.
Jadi baiklah saya bantu google.
Tools apa yang mau dipakai tentu tergantung dari metric apa yang mau digunakan.
Metric yang biasa kita gunakan untuk project management diantaranya:
- project size: berapa besar aplikasi yang dibuat, satuannya KLOC.
- effort : berapa jam orang kerja untuk menyelesaikan task tertentu, satuannya manhours atau mandays.
- duration : berapa hari kalender untuk menyelesaikan task tertentu, satuannya days.
Project size bisa dihitung menggunakan Sonar. Begitu kita jalankan, dia akan menghitung berapa ribu baris kode program aplikasi yang kita buat.
Effort tracking, tidak semudah itu. Yang jelas perlu ada partisipasi aktif dari team member untuk mencatat waktu yang dia habiskan untuk melakukan tugas tertentu.
Beberapa tools yang bisa membantu effort tracking diantaranya :
- Eclipse Mylyn : programmer aktifkan task, kemudian mulai coding. Begitu selesai, tasknya di-deactivate. Nanti Mylyn akan menghitung jumlah waktu yang digunakan untuk task tersebut. Hasilnya bisa kita upload ke Redmine.
- Hamster Applet (plugin Gnome di Ubuntu)
- Redmine Time Tracking : programmer bisa entri langsung di halaman issue atau mencantumkan effortnya di commit log.
Kalau sudah dapat effortnya, maka mudah untuk menghitung cost. Setelah cost didapat, ROI bisa dihitung.
Bisa juga pakai tools khusus Scrum, seperti iceScrum
August 25, 2011 at 5:19 pm
Sorry, sebenarnya arah pembicaraan bukan ke masalah tools sih. Intinya gw tetap meragukan tidak adanya dokumentasi untuk bisa di Level 5. Mungkin di process area development hal itu masih make sense. Tapi di process area lainnya metrik ini kecil sekali peranannya. Maksud gw sih sebenarnya di process area lain supaya bisa dinilai secara kuantitatif pasti ada dokumen. U
August 25, 2011 at 9:28 pm
Untuk bisa quantitatively managed, yang dibutuhkan adalah data, bukan dokumen. Data sama dokumen kan beda.
Contoh :
- Change Request Form : dokumen
- Jumlah change request : data
- User Story : dokumen
- Jumlah story point : data
- Programmer bikin timesheet : dokumen
- Project velocity : data
Dari contoh di atas, coba kita tanyakan:
- Bisakah mendapatkan jumlah change request tanpa membuat change request form? Bisa aja, asal request for change tercatat, entah di email, chat log, notulensi meeting, whatever
- Bisakah mendapatkan jumlah story point tanpa bikin dokumen user story? Bisa aja, asal user storynya dientri somewhere, kemudian ditotal jumlahnya.
- Bisakah mendapatkan data tanpa dokumen? Go figure.
November 14, 2011 at 3:58 pm
Well, saya cukup impressed dengan pendapat Anda, apalagi dengan teknologi yang berkembang saat ini.
Sebenarnya hal ini juga tergantung dari metodologi project, mungkin kalau menggunakan Waterfall agak sulit tanpa dokumen.
Saya yakin artikel ini cukup berguna untuk para PM dan analyst yang saat ini berorientasi pada dokumen dan bukan pada data.
Salam