Agile, Scrum, dan Kanban: Apa Arti Sebenarnya Kata-kata Ini?

Ketika seorang pengembang perangkat lunak mendengar berita tentang "kerangka kerja JavaScript baru" atau "IDE baru", dia tidak perlu mengajukan lebih banyak pertanyaan untuk mengklarifikasi tentang apa itu. Tetapi jika dia mendengar tentang "kerangka kerja tangkas baru," dia kemungkinan akan melakukan anggukan Homer-Simpsonian, berpura-pura bahwa dia tahu tentang apa itu, tetapi dia akan memiliki satu, dan hanya satu, pertanyaan: Apa sih "kerangka kerja tangkas" berarti?

Dalam lingkungan pengembangan perangkat lunak modern, kita semakin sering mendengar kata-kata seperti “gesit”, “scrum”, dan “kanban”, dan kata-kata tersebut sering digunakan secara tidak tepat. Pada artikel ini, saya akan mencoba menjelaskan dan memperjelas beberapa istilah tersebut.

Lincah

Jika Anda ingin menjadi yang paling pintar di keramaian, Anda harus menggunakan kata "gesit" di setiap kalimat lainnya saat Anda berbicara tentang proses kerja. Ini memiliki jangkauan yang cukup luas, tidak mengharuskan Anda untuk tahu banyak tentang subjek yang Anda bicarakan, dan ini adalah kata sifat atau kata keterangan yang sangat bagus: “thinking agile,” “agile approach,” “sesuai dengan prinsip-prinsip gesit.” Tapi apa sebenarnya arti "gesit"?

"Agile" mengacu pada "pengembangan perangkat lunak tangkas," pendekatan pengembangan yang mengikuti prinsip-prinsip tangkas. Tapi apa sih "prinsip tangkas?" Lihatlah Manifesto Agile dan 12 prinsip tangkas, yang meletakkan dasar pengembangan tangkas. Dari Manifesto:

Prinsip tangkas mendorong pengiriman perangkat lunak yang berfungsi secara berkelanjutan, komunikasi yang erat di antara tim, dan kemampuan beradaptasi yang tinggi terhadap perubahan kebutuhan. Jika Anda mengikuti nilai dan prinsip ini dalam pekerjaan Anda, Anda dapat mengatakan bahwa Anda bekerja di lingkungan yang gesit. Jadi, pengembangan perangkat lunak tangkas bukanlah sebuah metodologi, itu hanya sekumpulan metodologi, kerangka kerja, dan teknik berbeda yang mengikuti prinsip yang sama. Dapat dikatakan bahwa “gesit” adalah kerangka berpikir dan mengambil keputusan.

Tetapi mengapa begitu penting untuk mengikuti asas-asas ini dalam pekerjaan kita?

Manifesto dan prinsip adalah hasil dari pencarian solusi terbaik yang telah berkembang selama beberapa dekade dalam menanggapi tantangan pengembangan perangkat lunak. Sepanjang tahun 70-an, 80-an, dan 90-an, berbagai pengembang dan tim di seluruh dunia telah bereksperimen dengan metode kerja dan pendekatan untuk pemecahan masalah, menciptakan kerangka kerja dan teknik yang berbeda (seperti scrum dan Extreme Programming), dan bahkan sampai pada hal yang sama. ide secara paralel. Akhirnya, pada Februari 2001, tujuh belas pengembang berkumpul dan menemukan kesamaan untuk semua ide dan pengalaman yang beragam ini. Begitulah manifesto dibuat.

Scrum

Jika Anda berbicara tentang metode "gesit" tanpa mengetahui apa artinya, Anda mungkin terpeleset dan mengatakan hal-hal yang akan mengungkap Anda di depan lawan bicara yang mengetahui subjeknya: "Scrum dan metodologi tangkas lainnya."

Scrum bukanlah sebuah metodologi, meskipun kita semua pernah mendengarnya disebut lebih sering daripada jumlah pembunuhan di Game of Thrones . Scrum tidak akan memberikan jawaban untuk setiap pertanyaan, dan tidak akan memberi Anda prosedur yang tepat untuk menanggapi setiap situasi yang Anda hadapi. Dan mungkin sebagai akibat dari interpretasi yang salah ini, sebagian besar implementasi scrum juga salah: Tim tidak mendapatkan nilai. Ini mungkin menghasilkan pernyataan paling bodoh tentang scrum: "Scrum tidak berfungsi."

Apa itu scrum? Panduan Scrum mendefinisikan scrum sebagai:

Jadi ini adalah kerangka kerja , dan seperti kerangka kerja lainnya dapat, dan secara teratur, digunakan dengan cara yang salah. Menggunakan scrum secara efektif membutuhkan tidak hanya mengadopsi struktur yang ditetapkan oleh scrum, tetapi memiliki pemahaman yang mendalam dan penghargaan untuk prinsip-prinsip tangkas di seluruh tim.

Scrum terdiri dari peran-peran berikut: Pemilik Produk, Scrum Master, Tim Pengembang.

Ada juga empat upacara Scrum: Rapat Perencanaan, Scrum Harian, Review Sprint, Sprint Retrospective

Dan tiga artefak: Product Backlog, Sprint Backlog, Product Increment.

Proyek scrum diatur ke dalam kerangka waktu reguler, yang kami sebut sprint. Mereka biasanya berlangsung dua minggu.

Seorang Pemilik Produk bertanggung jawab untuk memandu arah proyek. Saat tugas dan fitur baru ditentukan, pemilik produk menambahkannya ke jaminan simpanan produk. Sprint dimulai dengan rapat perencanaan di mana tim pengembangan memilih tugas dari backlog untuk dikerjakan dan merencanakan bagaimana mereka akan diimplementasikan. Itu diikuti oleh pengembangan, di mana tim pengembangan menggunakan backlog untuk melacak kemajuan dan bertemu untuk pertemuan harian untuk menyinkronkan kegiatan dan menyesuaikan rencana, jika diperlukan. Hasil pengembangan harus berupa peningkatan produk, sesuatu yang dapat diterapkan pada produk dan segera dirilis. Di akhir sprint, product increment dipresentasikan ke Product Owner di sprint review, dimana product backlog ditambah jika diperlukan perubahan lebih lanjut. Setelah itu, seluruh tim menghadiri sprint retrospective di mana mereka berbicara tentang proses kerja dan bagaimana hal itu dapat ditingkatkan.

Sangat mudah untuk belajar dan memahami scrum, tetapi sulit untuk diadopsi. Ada banyak alasan kerangka kerja ini mungkin cocok atau tidak cocok untuk sebuah proyek. Seringkali membutuhkan banyak perubahan, tidak hanya dalam perkembangan sehari-hari, tetapi juga secara budaya. Scrum paling cocok dengan pengembangan produk yang kompleks, produk yang bertahan lama dan mencakup berbagai jenis spesialis.

Mengapa scrum begitu populer, dan mengapa scrum memiliki keunggulan dibandingkan model air terjun tradisional? Sederhananya, karena memberikan nilai lebih kepada produk dan pelanggan. Dengan metode "kelas berat" seperti air terjun, banyak cerita horor di mana tidak ada yang melihat apa pun dari proyek selama berbulan-bulan. Dengan scrum, itu tidak mungkin.

Scrum adalah semua tentang nilai yang diberikan kepada pengguna akhir. Jika Anda benar-benar menggunakan scrum, Anda perlu memberikan sesuatu yang bernilai setiap sprint. Nilai dapat diukur, dan tim juga dipaksa untuk memeriksa hambatan dan beradaptasi, dengan tujuan memberikan nilai lebih pada iterasi berikutnya.

Dalam sebagian besar pengembangan perangkat lunak, kami tidak sedang membangun gedung pencakar langit; kita tidak perlu menyiapkan seluruh rencana sebelum kita mulai, dan tetap berpegang pada rencana itu sampai akhir. Kami sedang mengembangkan perangkat lunak, dan kami memiliki kemampuan untuk beradaptasi dengan situasi yang berbeda dan untuk mengubah persyaratan produk selama pengembangan. Untuk waktu yang lama, banyak pengembang melihat ini sebagai dosa mematikan kedelapan, tetapi dari perspektif produk, ini adalah manfaat besar untuk mengoptimalkan prediktabilitas dan mengendalikan risiko. Scrum dikembangkan di sekitar kemampuan ini, dan implementasinya memberikan cara yang andal dan efisien untuk menangani perubahan yang diperlukan.

Banyak teknik yang digunakan bersama dengan scrum: planning poker, pair programming, test-driven development (TDD), behavior-driven development (BDD), dan lain-lain. Mereka sebenarnya bukan bagian dari scrum, melainkan teknik yang kompatibel. Salah satu metode yang sering disebutkan bersamaan dengan scrum adalah kanban, dan ada banyak kebingungan tentang apa arti kedua hal ini dalam hubungannya satu sama lain.

Kanban

Ketika Anda berbicara tentang scrum dan kanban, satu pertanyaan yang sering diajukan dari orang banyak adalah, “Mana yang lebih baik, scrum atau kanban?” Dan Anda tidak akan tahu harus menjawab apa karena ini seperti membandingkan apel dan jeruk, atau bertanya, “Mana yang lebih baik, panekuk atau bir?” Keduanya lebih baik.

Kanban adalah metode sederhana yang bertujuan untuk pengiriman tepat waktu tanpa membebani anggota tim secara berlebihan. Ini mirip dengan scrum karena tujuannya adalah untuk memberikan nilai maksimum di akhir, tetapi jauh lebih fleksibel daripada scrum.

Kanban tidak ditemukan oleh komunitas pengembangan perangkat lunak. Sebenarnya, ini berasal dari proses manufaktur di Toyota, dan digunakan secara luas di bidang lain. Tidak ada prosedur ketat yang harus Anda ikuti, dan tidak ada cara ketat yang harus Anda terapkan dan gunakan kanban; itu, lebih tepatnya, seperangkat prinsip dan praktik, dan Anda dapat memilih dari praktik ini sesuai dengan kebutuhan Anda. Namun ada satu implementasi kanban yang paling sering digunakan dalam pengembangan perangkat lunak yang mencakup penggunaan papan kanban , yang terdiri dari kolom yang mewakili tahapan pekerjaan, dan tugas.

Kolom mewakili keadaan tugas dalam proses pengembangan. Contoh paling sederhana terdiri dari tiga kolom: “To Do”, “In Progress”, dan “Done”. Jadi, tugas ditambahkan ke "To Do", dipindahkan ke "In Progress" saat pengembangan dimulai, dan dianggap "Selesai" saat dipindahkan ke kolom terakhir. Tapi tentu saja, itu bisa lebih kompleks:

Backlog → Menentukan Spesifikasi → Siap untuk Pengembangan → Pengembangan → Tinjauan Kode → Pengujian → Dikerahkan (→ Tidak ada yang benar-benar menggunakannya → Dihapus Sepenuhnya).

Setiap kolom dapat memiliki subkolom; misalnya, "Pengembangan" dapat dibagi menjadi "Perencanaan" dan "Pengodean"; "Pengujian" dapat dibagi menjadi "Pengujian Unit" dan "Pengujian Integrasi," dan seterusnya. Kolom mungkin didedikasikan untuk spesialis, jika sesuai. Tim mendefinisikan kolom dan tahapan sesuai dengan kebutuhannya. Sesuai dengan filosofi "tarik", tugas hanya boleh masuk ke alur kerja saat permintaannya mendesak.

Tujuan papan ini adalah untuk memvisualisasikan alur kerja , yang merupakan praktik utama pertama dalam kanban. Bahkan, kanban bisa dilakukan tanpa papan sama sekali! Ini bisa berupa daftar tugas sederhana di lembar Google dengan warna latar belakang berbeda yang menunjukkan status tugas, atau bisa juga bagan Gantt, diagram, tabel… Bahkan bisa berupa satu set ember di kantor Anda, yang masing-masing mewakili keadaan tugas, dan di mana bola digunakan sebagai tugas. Cukup visualisasikan alur kerja dan berikan transparansi ke seluruh proses.

Prinsip penting lainnya adalah mengurangi ukuran batch usaha Anda . Sederhananya, ini berarti menghindari multitasking. Itu bisa berarti mengurangi volume tugas yang Anda kerjakan pada saat yang bersamaan. Jika Anda memiliki tiga desainer dalam satu tim, tim tersebut mungkin menetapkan jumlah tugas maksimum di kolom "Merancang" menjadi tiga.

Seperti scrum, kanban juga melihat tim sebagai figur terpenting dalam prosesnya. Tapi itu tidak menyarankan peran seperti scrum, dan Anda dapat mempertahankan peran yang ada untuk menghindari membuat perubahan pada proses yang ada. Hal yang sama untuk perbaikan terus-menerus: Kanban umumnya mendorong Anda untuk belajar dan meningkatkan terus-menerus, tetapi tidak meresepkan acara khusus hanya untuk proses itu, seperti halnya Retrospektif Sprint scrum.

Mana yang Harus Saya Gunakan?

Scrum dan kanban tidak saling eksklusif dan tidak benar-benar sebanding. Di scrum, ada peran yang ditentukan, sementara kanban mengatakan, "Apa-apaan, pertahankan peran dan tanggung jawab Anda saat ini." Scrum akan memaksa Anda untuk mengubah cara kerja Anda; kanban memungkinkan Anda memulai dengan proses yang ada. Dalam scrum, jadwal acara yang jelas ditentukan oleh kerangka kerja; di kanban Anda tidak memiliki acara. Namun, mereka memiliki banyak kesamaan: Keduanya berpusat pada nilai, anggota tim dihormati sebagai "bos" dari sistem, dan pada dasarnya, mereka memiliki misi yang sama: Untuk terus menghilangkan pemborosan dan menghilangkan hambatan.

Tetapi pertanyaannya, "Apa yang harus saya gunakan dalam proyek khusus saya dan dengan tim khusus saya?" jauh lebih masuk akal. Kanban tidak memerlukan begitu banyak proses dan perubahan budaya, dan, dalam banyak kasus, akan lebih mudah untuk diadopsi daripada scrum. Scrum, di sisi lain, menawarkan lebih banyak struktur secara signifikan untuk memandu proses, yang dapat menghilangkan banyak overhead selama semua orang berada di halaman yang sama.

Tetapi keindahan dari keduanya adalah tidak ada aturan yang ketat. Tidak ada yang menghentikan Anda untuk memilih dan memilih elemen scrum terbaik untuk Anda, seperti rapat harian atau ulasan. Dan tidak ada alasan Anda tidak dapat memasukkan papan kanban ke dalam scrum.

Scrum telah terbukti menjadi kerangka kerja yang sangat efektif ketika seluruh tim memahaminya dengan baik. Namun, dalam pengalaman saya, saya merasa sulit untuk bekerja dalam scrum dengan beberapa klien. Proses dan perubahan budaya yang diperlukan untuk implementasi scrum yang tepat bisa jadi terlalu banyak (terutama ketika berhadapan dengan seseorang yang percaya bahwa dia sedang membuat Google baru!). Di sisi lain, kanban lebih fleksibel dan tidak memaksa orang untuk berubah. Beberapa penulis juga mengatakan bahwa kanban adalah jalan yang baik menuju kelincahan, dan menawarkan implementasi scrum yang lebih mudah. Yang lain mengatakan bahwa menggunakan scrum harus mengarah ke kanban di akhir.

Yang benar adalah bahwa setiap proyek berbeda, dan tidak ada solusi satu ukuran untuk semua. Sebagai manajer proyek, terserah Anda untuk menentukan apa yang terbaik untuk tim Anda.