Anda terbiasa dengan Scrum, bukan? Saya kira ya mengingat The Scrum Alliance memiliki lebih dari 400.000 anggota, dan dari mereka, sebagian besar berhasil menggunakannya dalam organisasi mereka.
Tapi, itu bukan satu-satunya cara untuk membangun perangkat lunak dengan cara yang gesit - dengan serius! Pernahkah Anda mendengar tentang Kanban?
Untuk sedikit informasi latar belakang, ini awalnya diterapkan pada lean manufacturing sebagai cara untuk memvisualisasikan input dan output pekerjaan saat mengalir melalui pabrik. Visualisasi ini disajikan di papan yang dikenal sebagai - tunggu - Kanban. Baru-baru ini dan lebih berkaitan dengan Anda, ini telah diadopsi sebagai metode untuk mengelola pengembangan perangkat lunak.
Pertama kali digariskan oleh ahli saraf David J. Anderson, ini adalah cara mengatur pengembangan dan perencanaan perangkat lunak yang memungkinkan Anda untuk mengungkap masalah proses dan secara konsisten memberikan peningkatan berharga pada produk Anda - yang saya tahu, terdengar ideal. Sederhananya, pada titik waktu tertentu, Anda dapat melihat di mana pekerjaan (diwakili oleh kartu) sedang dalam proses pengembangan.
Bagaimana itu bekerja
Papan Kanban dasar menggunakan enam kolom yang menunjukkan di mana setiap karya berada dalam siklus pengembangan produk. Contoh kasar seperti apa di bawah ini.
Lihat contoh papan Kanban ini di Trello.
Kolom 1: Backlog
Kolom Backlog harus berisi daftar ide, bug, atau kebutuhan bisnis yang diprioritaskan. Kartu tidak harus memiliki banyak detail, tetapi harus memiliki informasi yang cukup sehingga anggota tim Anda mengerti mengapa itu penting.
Kolom 2: Perencanaan
Dalam kolom ini, manajer produk akan mengisi spesifikasi untuk fitur tersebut dengan bertemu dengan pemangku kepentingan bisnis, insinyur, dan desainer. Ketika sudah siap, ia akan memindahkannya ke kolom "Ready for Engineering".
Kolom 3: Siap untuk Teknik
Pada tahap ini, semua kartu harus memiliki spesifikasi terperinci. Meskipun Anda mungkin masih memiliki pertanyaan tentang detail teknis, persyaratan bisnis harus jelas.
Kolom 4: Sedang Berlangsung
Anda dapat memindahkan kartu ke “Sedang Berlangsung” kapan saja. Sistem "tarikan" yang digerakkan sendiri ini membangun budaya akuntabilitas dan rasa ingin tahu pribadi.
Kolom 5: Pengujian
Ketika Anda telah menyelesaikan pekerjaan pada kartu, pindahkan ke "Pengujian" di mana insinyur lain (atau seseorang di tim QA) akan mengambilnya.
Kolom 6: Dikerahkan
Fitur lain yang menentukan adalah bahwa pekerjaan harus dikirim terus menerus ke lingkungan pementasan atau produksi. Kolom ini memungkinkan siapa pun di tim untuk melihat pekerjaan apa yang telah dirilis baru-baru ini.
Keuntungan dan Pengorbanan
Saat Anda memutuskan antara Kanban dan metodologi yang lebih umum seperti Scrum atau Waterfall, ingat manfaat dan tantangan ini:
Manfaat: Meningkatkan Kolaborasi
Dalam beberapa tim pengembangan yang pernah saya tangani, insinyur adalah spesialis. Setiap tim akan memiliki beberapa insinyur frontend dan insinyur backend. Ini berarti pekerjaan sering terhambat karena seorang insinyur sibuk dengan hal lain.
Kanban, di sisi lain, membatasi pekerjaan yang sedang berjalan dan mencegah penyumbatan. Setiap anggota tim hanya dapat mengerjakan satu item pada satu waktu, dan siapa pun yang tidak sibuk dapat menarik pekerjaan dari bagian atas kolom "Siap untuk Rekayasa". Ini mendorong generalis teknik dan kolaborasi di antara anggota tim.
Tingkatkan Manfaat: Jangan Biarkan Segala Sesuatu Berlalu Sebelum Mereka Siap
Kanban hanya berfungsi ketika Anda menunggu untuk memindahkan kartu ke kolom berikutnya sampai semuanya selesai. (Bonus: Ini sangat meminimalkan cacat.)
Tantangan: Mencegah Waktu untuk Bercermin
Secara default, tidak ada sprint kotak waktu dengan tujuan yang jelas, target tanggal, dan siklus rilis. Sebagai gantinya, anggap setiap kartu sebagai karya independen yang dapat diselesaikan dan dirilis kapan saja.
Dengan aliran pekerjaan yang berkelanjutan ini, tidak ada opsi "tunggu sampai sprint berikutnya". Anda harus terus memeriksa papan, menarik item berikutnya, dan memindahkan item yang sudah selesai ke hilir. Kecuali Anda membangun waktu untuk retrospektif dan standup, mungkin sulit bagi anggota tim untuk mengikuti perkembangan mereka.
Berkelilinglah: Pinjam Apa yang Berhasil Dari Scrum
Saya telah menggunakan standup harian dan retrospektif dengan Kanban dan menemukan bahwa mereka menambah nilai. Jika ada rapat atau pola reguler yang berfungsi untuk tim Anda, jangan mengubahnya menjadi dogmatis sesuai dengan Kanban. Anggaran waktu untuk berbicara tentang prioritas dan bagaimana mereka telah berubah sehingga semua orang tahu apa yang terjadi dalam siklus pengembangan produk.
Manfaat: Meningkatkan Transparansi
Setiap pengembang harus mengambil inisiatif untuk memindahkan kartu ke kolom “Sedang Berlangsung”. Berarti, pada waktu tertentu, manajer tim dapat melihat siapa yang sibuk, siapa yang tidak sibuk, dan berapa lama setiap pekerjaan telah berlangsung.
Ketika produksi melambat atau berhenti, Kanban memungkinkan Anda untuk mengetahui alasannya. Entah itu karena tim bisnis belum memprioritaskan item dalam tumpukan, tim produk belum menyelesaikan spek, tim pengembang bergerak lebih lambat dari yang diharapkan, atau tim QA tidak dapat menguji sesuatu; hambatannya jelas.
Tingkatkan Manfaat: Biarkan Kemajuan Menjadi Publik
Salah satu kelebihannya adalah Kanban sangat visual. Bahkan anggota tim non-teknis dapat melihat papan Kanban dan memberi tahu di mana bagian-bagian pekerjaan sedang dalam proses. Gunakan ini untuk keuntungan Anda dan biarkan prestasi tim bersinar dengan meletakkan papan Anda di tempat umum.
Tantangan: Tidak Mengizinkan Perencanaan Jangka Panjang
Khawatir tentang tenggat waktu dan perkiraan bukanlah penggunaan waktu Anda yang paling produktif, sehingga Anda dapat menghargai bahwa Kanban lebih banyak tentang hasil harian. Yang mengatakan, itu saja tidak menyediakan sistem untuk membangun rencana jangka panjang. Ini dapat menyebabkan Anda mengerjakan proyek secara sporadis daripada berfokus pada satu hal untuk waktu yang lama. Sulit untuk menghabiskan satu hari di Proyek A lalu sehari di Proyek B lalu kembali ke Proyek A.
Berkelilinglah: Gunakan saat Prioritas Anda Akan Berubah
Setiap kolom di papan Anda tidak tergantung pada yang lain, sehingga anggota tim dapat memindahkan barang kapan saja. Ini dapat mengganggu pengembang dalam pengaturan Scrum (di mana perkiraan untuk sprint dibuat di muka), tetapi Kanban berkembang dalam lingkungan yang berubah dengan cepat ini.
Semua orang ingin menjadi lebih banyak produk, tetapi mungkin sulit untuk mencoba sesuatu yang baru jika Anda bahkan tidak yakin harus mulai dari mana. Saya telah menemukan Kanban sangat membantu dan berharap Anda juga akan merasakan manfaatnya untuk alur kerja pribadi Anda (atau bahkan untuk seluruh tim Anda!).
Tweet saya jika Anda memutuskan untuk mencobanya!
