Checklist untuk Kualitas
Sebuah praktik penegak Pilar 1 Pilar 3 , dilakukan oleh product-owner prouct-manager development-team CTO
Praktik ini dipopulerkan bersama konsep papan Kanban dari Toyota Lean Manufacture. Di Scrum, praktik ini biasa disebut dengan istilah Definition of Done.
Apa itu Checklist?
Semua orang sudah tahu checklist.
Checklist
Ini yang mungkin belum semua tahu: penerapan checklist oleh tenaga medis bisa mengurangi tingkat kematian sampai 23%1. Checklist bisa mengurangi kelalaian manusia.
Bagaimana Penerapan Checklist di Software?
Checklist bisa digunakan untuk memastikan kualitas produk memenuhi standar, baik di mata pengguna maupun di mata developer.
Terlihat kalau checklist di pengembangan software bisa berguna untuk banyak pihak.
Standar kualitas di mata developer termasuk kualitas kode — sesuatu yang pengguna tidak rasakan. Kalau begitu kenapa harus dikerjakan? Apa nilai bisnisnya? Nilai bisnisnya ada di kecepatan pengembangan di masa depan. Makin berkurang kualitas, kode akan makin susah dibaca di masa depan. Kode yang susah dibaca akan susah untuk dikembangkan.
Pengorbanan atas kualitas kode — demi kecepatan rilis — merupakan fenomena yang wajar. Oleh karena itu, penting bagi pimpinan untuk memahami ini & tidak menego standar kualitas kode yang diminta developer — bahkan kalau bisa, mengajarkan standar kualitas kode yang lebih tinggi.
Di level taktis, checklist akan menjaga para eksekutor untuk pasti mengeksekusinya.
Penerapan checklist di papan kanban repetitif. Terlihat ada checklist di setiap langkah, yang mana harus dipenuhi pekerjaan agar bisa masuk kolom 'Selesai'.
Penerapan checklist di papan kanban proyek di Scrum (biasa disebut 'Sprint Backlog'). Terlihat kalau pekerjaan-pekerjaan di checklist masuk ke task-task di kolom to-do. Terlihat juga kalau penulisan skrip tes otomatis dan pengujiannya dimasuk ke fase development — berbeda dengan papan kanban repetitif di atas.
Siapa yang Berhak Menentukan ‘Checklist’?
Yang pertama, tentu, organisasi. CTO bisa menentukan langkah-langkah wajib apa dari development.
Disarankan agar tidak berhenti dari standar kualitas yang ditentukan organisasi. Berikan developer atau tim developer kebebasan untuk menambah & mengurangi isi checklist mereka — selama tidak mengurangi yang diwajibkan organisasi.
Minta mereka menjelaskan, kenapa sebuah langkah yang mereka tambahkan ke checklist akan bermanfaat untuk produk ke depannya.
Hal ini akan meningkatkan rasa kepemilikan mereka terhadap produk & pekerjaan2. Mereka akan lebih produktif.
Bagaimana Peran ‘Checklist’ ke Pilar 1?
Praktik Checklist meminimalisir kemungkinan meengerjakan ulang pekerjaan yang sama. Hal tersebut jelas-jelas memperlambat waktu rilis. Penyebabnya bisa error atau sekedar lupa melakukan hal penting & wajib terkait pekerjaan.
Bagaimana Peran ‘Checklist’ ke Pilar 3?
Yang sudah jelas:
- Checklist meminimalisir bug.
- Checklist meningkatkan standar minimum kualitas kode, sehingga kode tetap mudah dikembangkan di masa depan.
Selain itu, praktik Checklist juga memberikan penjelasakan ke pihak bisnis (baik yang tiap hari berinteraksi dengan developer maupun yang ‘di atas langit sana’) tentang kenapa mereka bisa berkerja lebih lama.
Karena kualitas kode tidak bisa dicek sendiri dan dipahami oleh mereka — jika tidak diedukasi oleh orang teknis. Mereka hanya tahu apa-apa yang bisa dirasakan langsung oleh pengguna.
-
“Systematic review and meta-analysis of the effect of the World Health Organization surgical safety checklist on postoperative complications”, The British Journal of Surgery (Feb 2014). ↩
-
Bab 4 di Buku Peopleware (1987), “Quality—if Time Permit” ↩
Riwayat perubahan halaman ini github.com/3pillarsofagile/3pillarsOfAgile.github.io/commits/master/_practices/checklist-on-quality.md