Dari Scrum untuk Lean

Sementara Scrum yang tujuan utama organisasi dan manajemen proyek, Lean lebih tentang cara mengoptimalkan proses untuk cepat menghasilkan produk berkualitas. Ini bisa menjadi langkah pertama Anda menuju mengadopsi prinsip Agile, atau mungkin sesuatu yang tim Anda berevolusi, ketika Scrum tidak cukup. Saya mengundang Anda untuk membaca cerita tim saya, dan bagaimana kami berevolusi dari Scrum menjadi proses pengembangan Lean-ish.

Sejarah Singkat

Lean adalah seperangkat prinsip yang didefinisikan oleh industri manufaktur mobil Jepang pada 1980-an. Insinyur kualitas Toyota, John Krafcik, menciptakan istilah tersebut, sambil mengamati proses dan alat yang digunakan untuk menghilangkan pemborosan dalam produksi mobil massal. Tidak sampai 2003 bahwa Mary dan Tom Poppendieck memperkenalkan Lean sebagai proses pengembangan software dalam buku mereka, Lean Software Development: An Agile Toolkit.

Meskipun Scrum adalah seperangkat aturan dan peran, Lean adalah seperangkat prinsip dan konsep dengan beberapa tools. Keduanya dianggap teknik Agile, dan mereka berbagi ideologi yang sama dalam pengiriman cepat, sekaligus mengurangi cacat dan kesalahan. Saya selalu menekankan kemampuan adaptasi Agile, tetapi tidak dapat mengabaikan fakta bahwa Scrum menampilkan dirinya sebagai seperangkat aturan wajib. Bahkan, penggemar penganut Scrum akan meneriakkan penghujatan karena tidak mengikuti aturan Scrum untuk surat itu.

Lean, di sisi lain, lebih terbuka; pengikutnya menyajikan proses sebagai seperangkat rekomendasi yang sangat mudah beradaptasi.

Ini mendorong tim atau perusahaan untuk membuat keputusan, dan menyesuaikan dengan keputusan dan kejutan setiap hari yang dihadapi tim dan perusahaan Anda.

Ketika tim saya matang dan dieksploitasi Scrum, kita merasa bahwa beberapa aspek itu menahan kami. Kita menjadi tim yang cukup disiplin dan homogen. Beberapa pertemuan tidak sesuai lagi, dan mulai menyadari bahwa rapat harian tidak efisien. Kita belajar bahwa masalah harus diselesaikan lebih cepat, dan merasa perlu untuk menghindari prosedur yang menahan kita.

Kami pindah.

Dua Konsep Utama Lean

Lean memaparkan dua konsep utama, tetapi ide intinya adalah: menghilangkan pemborosan dan meningkatkan alur kerja.

Menghilangkan Limbah

Jika sesuatu akan rusak, itu akan pecah pada hari Jumat.

Apa pun yang menghalangi produksi adalah pemborosan. Ini termasuk waktu yang hilang, bahan sisa, dan tenaga kerja yang tidak digunakan. Cacat dalam produk akhir adalah limbah; itu membuang waktu untuk memperbaikinya, membuang-buang uang untuk menggantikannya, dan membuang-buang sumber daya untuk mencari solusi lain.

Konsep limbah dengan baik diterjemahkan ke dunia pengembangan software. Limbah dapat dijelaskan oleh pengiriman terlambat, bug, dan programer tidak ada hubungannya (jangan bingung ini dengan "programmer harus memprogram delapan jam sehari tanpa jeda dan youtube").

Meningkatkan Aliran

Konsep Lean Toyota berkonsentrasi pada aliran produksi. Di pabrik produksi, aliran adalah rantai prosedur yang mengubah bahan mentah menjadi produk akhir mereka. Prosedur ini bisa sangat berbeda satu sama lain dan membutuhkan waktu yang berbeda untuk menyelesaikannya, tetapi masing-masing dapat diperbaiki untuk membuatnya lebih efisien. Ini adalah penemuan pertempuran konstan dan meningkatkan kemacetan dalam prosesnya.

Aliran ideal adalah satu di mana setiap langkah membutuhkan jumlah waktu dan upaya yang sama untuk menghasilkan jumlah produk yang sama.

Ini tidak berarti bahwa setiap proses harus menghabiskan jumlah uang yang sama, tetapi setiap proses harus dapat diselesaikan dengan jumlah kemudahan yang sama.

Ironisnya, Scrum adalah alat yang pada akhirnya menuntun kami untuk mewujudkan limbah dalam proyek. Sementara kita berpegang pada Scrum murni di beberapa area produksi, kita mulai mengidentifikasi bug dan/atau penundaan yang dapat dengan mudah dihindari dengan mengambil pendekatan yang berbeda.

Kita tahu sedikit tentang Lean pada saat itu. Kita membaca beberapa artikel tentang masalah ini, tetapi melakukan hal yang salah dan mengabaikannya, karena kita begitu fokus pada proses Scrum. Kita hampir yakin bahwa Scrum adalah Holy Grail, tetapi "senapan mesin Scrum" mulai salah tembak. Kita perlu membuka pikiran.

Prinsip-prinsip Lean

Untuk pengembangan software, prinsip-prinsip Lean diadaptasi menjadi tujuh berikut.

1 - Hilangkan Sampah

Perubahan dari Scrum menjadi Lean benar-benar membebaskan.

Dalam pengembangan software, Anda dapat menemukan dan menghilangkan pemborosan dengan mengenali hal-hal yang perlu ditingkatkan. Dalam pengertian pragmatis, apa pun yang bukan merupakan nilai langsung bagi pelanggan adalah pemborosan. Untuk memberikan beberapa contoh: sampah adalah bug, komentar dalam kode, fitur yang tidak digunakan (atau jarang digunakan), tim menunggu di tim lain, mengambil panggilan pribadi... Anda mendapatkan ide. Apa pun yang menahan Anda, tim Anda, atau produk Anda kembali adalah pemborosan, dan Anda harus mengambil tindakan yang tepat untuk menghapusnya.

Saya ingat salah satu masalah kami adalah kebutuhan yang sering untuk bereaksi lebih cepat daripada dua sprint. Berkembang dalam sprint dan menghormati peraturan Scrum melarang Anda mengubah cerita yang ditugaskan ke sprint saat ini. Tim perlu beradaptasi ketika pengguna menemukan bug dan perlu diperbaiki, atau ketika pelanggan yang paling penting menginginkan fitur yang dapat dengan mudah dipuaskan dalam dua hari. Scrum tidak cukup fleksibel dalam kasus-kasus ini.

2 - Amplify Learning

Tempatkan nilai tinggi pada pendidikan.

Anda memiliki limbah, dan secara alami Anda ingin lebih sedikit sampah di masa depan. Tapi mengapa ada sampah? Ini lebih dari mungkin berasal dari anggota tim yang tidak tahu bagaimana mendekati masalah tertentu. Tidak apa-apa; tidak ada yang tahu segalanya. Tempatkan nilai tinggi pada pendidikan.

Identifikasi bidang-bidang yang paling membutuhkan peningkatan (pengetahuan) dan mulailah pelatihan. Semakin Anda dan tim Anda tahu, semakin mudah mengurangi limbah.

Sebagai contoh, belajar Test Driven Development (TDD) dapat mengurangi jumlah bug dalam kode Anda. Jika Anda memiliki masalah dengan mengintegrasikan modul-modul tim yang berbeda, Anda mungkin ingin mempelajari apa artinya Continuous Integration dan menerapkan solusi yang sesuai.

Anda juga dapat belajar dari umpan balik pengguna; ini memungkinkan Anda untuk mempelajari bagaimana pengguna menggunakan produk Anda. Fitur yang sering digunakan hanya dapat diakses dengan menavigasi melalui lima menu. Itu pertanda sia-sia! Anda mungkin awalnya menyalahkan limbah seperti itu pada programmer dan perancang (dan Anda mungkin benar), tetapi pengguna cenderung menggunakan perangkat lunak Anda dengan cara yang tidak pernah Anda maksudkan. Belajar dari pengguna Anda membantu menghilangkan pemborosan semacam ini. Ini juga membantu Anda menghilangkan persyaratan yang salah atau tidak lengkap. Umpan balik pengguna dapat mendorong produk pada jalur yang tidak akan pernah dipertimbangkan.

Pada titik tertentu, tim saya mengidentifikasi bahwa modul tertentu dapat ditulis lebih baik jika mengetahui lebih banyak tentang domain di awal. Tentu saja, tidak ada cara untuk memutar kembali waktu, dan menulis ulang potongan kode yang sangat besar tidaklah praktis. Kita memutuskan untuk menginvestasikan waktu untuk mempelajari domain ketika ditugasi dengan fitur yang lebih kompleks. Ini mungkin memerlukan beberapa jam atau bahkan minggu, tergantung pada kompleksitas masalah.

3 - Putuskan Selambat Mungkin

Setiap keputusan memiliki biaya. Mungkin tidak langsung dan material, tetapi biayanya ada di sana. Menunda keputusan membantu Anda sepenuhnya mempersiapkan masalah yang harus Anda hadapi. Mungkin contoh paling umum dari keputusan yang tertunda adalah dengan desain database.

Keputusan tidak harus bersifat teknis; berkomunikasi dengan pelanggan membantu Anda membuat keputusan yang berdampak pada cara Anda mendekati fitur produk Anda.

Tetapi pengguna tidak selalu tahu apa yang mereka inginkan. Dengan menunda keputusan fitur sampai pengguna benar-benar membutuhkan fitur tersebut, Anda akan memiliki lebih banyak informasi tentang masalah dan dapat menyediakan fungsionalitas yang diperlukan.

Pilih metodologi Agile yang paling sesuai untuk Anda dan tim Anda.

Empat belas tahun yang lalu, tim membuat keputusan untuk menyimpan konfigurasi aplikasi dalam database MySQL. Mereka membuat keputusan ini di awal proyek, dan sekarang tim saat ini (tim saya) memiliki beban yang sulit untuk dipikul. Untungnya, produk itu tidak lagi dalam pengembangan aktif, tetapi kita masih harus mempertahankannya dari waktu ke waktu. Apa yang seharusnya menjadi tugas sederhana akhirnya menjadi monumental besar.

Sisi baiknya, kita belajar dari kesalahan para pendahulu. Membuat keputusan pemrograman, arsitektur dan proyek selambat mungkin. Bahkan, belajar pelajaran sulit ini sebelum mengadopsi Lean. Tulis kode terbuka dan dipisahkan, dan tulis desain yang persisten - dan konfigurasi-agnostik. Ini tentu lebih sulit dilakukan, tetapi pada akhirnya menghemat banyak waktu di masa depan.

Beberapa waktu lalu, kita menambahkan fitur ke produk yang memampatkan data pada disk. Kita tahu itu akan berguna, dan ingin menambahkannya ke produk secepat mungkin. Kita memulai dengan fungsi sederhana, menghindari keputusan terkait opsi dan konfigurasi hingga nanti. Pengguna mulai memberikan umpan balik setelah beberapa bulan, dan mengambil informasi itu untuk membuat keputusan kita tentang opsi dan konfigurasi fitur. Kita memodifikasi fitur dalam waktu kurang dari satu hari, dan tidak seorang pengguna pun yang mengeluh atau meminta lebih banyak fungsi. Itu adalah modifikasi yang mudah dibuat; menulis kode mengetahui bahwa kita akan membuat modifikasi di masa depan.

4 - Serahkan secepat mungkin

Kita hidup di dunia yang terus berubah. Program yang kita tulis hari ini adalah untuk komputer yang akan usang dalam dua tahun. Hukum Moore masih berlaku, dan akan terus demikian.

Kecepatan pengiriman adalah segalanya di dunia yang serba cepat ini.

Mengirimkan produk dalam tiga tahun menempatkan Anda di belakang paket, jadi sangat penting untuk memberikan nilai kepada pelanggan Anda sesegera mungkin. Sejarah membuktikan bahwa produk yang tidak lengkap dengan jumlah bug yang dapat diterima lebih baik daripada tidak sama sekali. Plus Anda memiliki umpan balik pengguna yang sangat berharga.

Perusahaan kami bermimpi: berikan setelah setiap sprint. Tentu, itu tidak praktis dalam banyak kasus. Pengguna kita tidak menginginkan produk yang diperbarui setiap minggu atau bulan. Jadi, sementara kami berusaha untuk merilis setiap versi kode, tidak. Kita belajar bahwa "cepat" adalah apa yang dirasakan pengguna - bukan apa yang secara fisik dapat kita lakukan. Dalam industri produk, cepat berarti pembaruan rutin setiap beberapa bulan dan perbaikan bug penting dalam beberapa hari. Ini adalah bagaimana pengguna kita merasakan "cepat"; jenis produk dan industri lain memiliki definisi "cepat" yang berbeda.

5 - Memberdayakan Tim

Programmer digunakan untuk menjadi sumber daya yang terbungkus dalam bilik, diam-diam melakukan tugas mereka untuk perusahaan mereka. Ini adalah gambar yang menonjol dari seorang programmer pada akhir 1990-an, tetapi itu jelas bukan lagi masalah.

Sejarah menunjukkan bahwa pendekatan itu dan manajemen proyek air terjun tradisional tidak cocok untuk perangkat lunak.

Itu sangat buruk pada satu titik yang hanya sekitar 5% persen dari semua proyek perangkat lunak yang benar-benar dikirimkan. Bisnis dan produk jutaan dolar gagal 95% dari waktu, menyebabkan kerugian besar.

Lean mengidentifikasi bahwa programmer yang tidak termotivasi menyebabkan pemborosan itu. Tetapi mengapa kurangnya motivasi? Nah, programmer dan tim pengembangan tidak didengarkan. Perusahaan mengatur tugas-tugas dan melakukan micromanaged kepada karyawan yang dilihat hanya sebagai sumber daya yang menghasilkan kode sumber.

Lean mendorong manajer untuk mendengarkan programmer, dan mendorong para pemrogram untuk mengajari manajer mereka proses produksi perangkat lunak. Ini juga mendorong pemrogram untuk langsung bekerja dengan klien dan pengguna. Ini tidak berarti para pengembang melakukan segalanya, tetapi itu memberi mereka kekuatan untuk mendorong evolusi produksi. Anehnya, memiliki perasaan seperti itu, "Anda tahu fitur hebat yang disukai para pengguna? Itu adalah ide saya!" adalah faktor motivasi besar.

Tapi jangan berpikir ini hanya berlaku untuk tim besar; tim kita kecil. Perusahaan hanya memiliki sedikit pengembang, jadi kita selalu dekat dengan pengguna. Hubungan itu telah memungkinkan kita untuk mempengaruhi produk melebihi apa yang mungkin diharapkan oleh para manajer pada awalnya.

6 - Membangun Integritas

Apa pun yang menghalangi produksi adalah pemborosan.

Integritas adalah tentang kekokohan produk Anda, dan bagaimana pelanggan melihat produk Anda secara keseluruhan. Integritas adalah tentang keseragaman, keandalan, dan keamanan UI, dan pengguna merasa aman menggunakan produk Anda. Integritas adalah gambar lengkap yang dibuat pengguna untuk produk Anda. Sebagai contoh, integritas UI melibatkan tampilan dan nuansa antara halaman, layar, modul atau bahkan antara UI sistem Anda dan situs web perusahaan.

Tetapi integritas juga dapat diamati dan dipraktekkan pada tingkat kode sumber. Integritas dapat berarti bahwa modul Anda, kelas dan bagian lain ditulis dengan cara yang sama. Anda menggunakan prinsip, pola, dan teknik yang sama di seluruh basis kode Anda - bahkan di antara tim yang berbeda. Integritas berarti Anda harus sering mem-refactor kode Anda. Ini adalah pekerjaan yang terus menerus dan tanpa akhir, dan Anda harus berusaha, tetapi tidak pernah mencapai, itu.

Mempertahankan integritas dalam kode sumber adalah tugas yang sulit. Kita menyadari bahwa menemukan kode duplikat adalah hal yang paling sulit untuk dilakukan, dan dengan duplikasi, saya tidak bermaksud beberapa baris kode duplikat dalam metode atau kelas yang sama.

Ini bukan tentang mencari di modul yang berbeda untuk kode yang sama persis; ini tentang menemukan potongan-potongan logika umum, mengekstraksi mereka ke dalam kelas mereka sendiri, dan menggunakannya di beberapa tempat.

Menemukan duplikasi logis sangat sulit dan membutuhkan pengetahuan yang mendalam tentang kode sumber.

Saya sudah berada di proyek yang sama selama lebih dari satu tahun, dan saya masih terkejut ketika saya menemukan kode duplikat. Tetapi itu hal yang baik; kita mencapai titik ketika benar-benar melihat hal-hal ini dan mengambil tindakan terhadapnya. Karena kita mulai secara aktif menghapus duplikat logika tingkat tinggi, kualitas kode meningkat. Kita selangkah lebih dekat untuk mencapai integritas.

7 - Lihat Utuh

Pengguna tidak selalu tahu apa yang mereka inginkan.

Ketika Anda membuat aplikasi Anda, Anda harus berpikir tentang komponen pihak ketiga yang Anda andalkan untuk mengembangkan produk Anda, serta pihak ketiga lainnya yang berkomunikasi dengan produk Anda. Aplikasi Anda perlu diintegrasikan dengan desain perangkat atau sistem operasi pada PC desktop. Bukankah lebih mudah menggunakan aplikasi yang terintegrasi dengan sistem notifikasi ponsel cerdas Anda, dan UI mencerminkan UI OS?

Ya, melihat keseluruhan tidak semudah itu. Anda harus melepaskan diri dari detail-detail kecil dan melihat produk Anda dari jauh. Salah satu momen mengesankan dalam pengembangan produk adalah ketika kita menyadari bahwa harus bergantung pada apa yang diproduksi oleh programmer lain dalam proyek lain. Kita menyadari bahwa kernel dari sistem, diprogram oleh orang lain, adalah salah satu dari komponen pihak ketiga yang diandalkan.

Pada satu titik, komponen pihak ketiga itu berubah. Kita bisa saja menerapkan band-aids untuk aplikasi kita, atau kita bisa mengambil rute yang mudah dan menyalahkan programmer yang menulis komponen itu. Sebaliknya, kita mengambil masalah dengan tanduk dan memperbaiki masalah di kernel pihak ketiga. Melihat keseluruhan dan bekerja dengannya dapat menjadi berantakan, tetapi dapat membuat perbedaan antara produk dan produk hebat.

Kanban - Alat Luar Biasa

Ada beberapa alat dan teknik untuk membuat Lean bekerja. Saya lebih suka Kanban, alat berbasis papan yang mirip dengan dewan perencanaan Scrum. Bayangkan sebuah papan Kanban sebagai corong ganda.

Di sebelah kiri adalah daftar cerita yang tidak pernah berakhir yang perlu kita bahas. Semua cerita yang sudah selesai menumpuk di sebelah kanan, dan manajer atau pemilik produk menentukan kapan akan menerbitkan rilis baru, berdasarkan daftar ini.

Di tengah adalah proses Kanban kita yang efektif. Produk harus dalam keadaan stabil dan siap rilis ketika menyelesaikan cerita. Ini tidak berarti bahwa fitur telah selesai; produk mungkin memiliki beberapa fitur yang diimplementasikan sebagian. Tetapi stabilitas, keamanan, dan ketahanan produk harus menjadi kualitas produksi.

Lebih Fleksibilitas dengan Rilis

Kita melakukan cukup baik dengan sprint saat ini. Itu hari Senin biasa, hari yang tenang dengan sedikit kegembiraan, tetapi kita mulai melihat beberapa masalah pada hari Rabu. Tidak apa-apa, itu selalu terjadi. Namun, mengatasi kesulitan-kesulitan ini membutuhkan waktu ekstra. Pemilik produk kita setuju dengan untuk terus mengerjakan fitur saat ini dan memperpanjang sprint saat ini sekitar tiga atau empat hari ekstra.

Jumat datang dengan kejutan. Anda tahu aturannya: jika sesuatu akan rusak, itu akan pecah pada hari Jumat. Klien yang penting dan potensial membutuhkan fitur tertentu sebelum menandatangani kontrak dengan perusahaan. Kami harus bereaksi (dan cepat!). Rilis baru adalah wajib ... Tapi tunggu! Kita berada di tengah-tengah sprint. Produk harus siap-siap pada akhir sprint. Apa yang kita lakukan? Scrum akan mengatakan untuk melakukan fitur baru di sprint berikutnya, tetapi kami sudah terlambat dengan sprint saat ini! Saat itulah, ketika kita mulai menyadari bahwa harus berpikir lebih kecil daripada sprint individu. Kita harus mampu beradaptasi lebih cepat, dan kita perlu melepaskannya lebih cepat jika diperlukan.

The Kanban Board

Papan Kanban terlihat sangat mirip dengan dewan perencanaan Scrum, tetapi dengan beberapa tambahan untuk lebih mengakomodasi proses Lean.

Kolom pertama di sebelah kiri adalah backlog penuh: segala sesuatu yang perlu kita lakukan di beberapa titik. Di ujung kanan, Anda memiliki corong lainnya, yang berisi semua cerita yang lengkap (tetapi tidak dirilis).

Di tengah adalah proses kita. Kolom-kolom ini dapat berbeda tergantung pada masing-masing tim dan proses. Biasanya disarankan untuk memiliki setidaknya satu kolom untuk beberapa tugas berikutnya, dan kolom lain untuk cerita yang sedang dikembangkan. Gambar di atas menunjukkan beberapa kolom lagi untuk menyajikan lebih baik proses pengembangan.

Kolom To-Do berisi daftar tugas yang harus diselesaikan. Kemudian, kita memiliki Desain, di mana para pengembang bekerja merancang kisah-kisah saat ini. Kolom keempat adalah Pengembangan, pengkodean yang sebenarnya. Akhirnya, kolom Pengujian berisi daftar tugas yang menunggu untuk ditinjau oleh rekan satu tim lainnya.

Batasi Pekerjaan Sedang Berlangsung

Tidak ada yang tahu segalanya.

Jika Anda membandingkan papan Kanban ini dengan papan perencanaan scrum, Anda akan segera melihat perbedaan yang jelas. Pertama, setiap kolom memiliki angka, mewakili jumlah maksimum cerita yang diizinkan berada di kolom itu. Kita memiliki empat to-do's, empat dalam desain, tiga dalam pengembangan dan dua dalam pengujian. The backlog dan tugas yang selesai tidak memiliki batasan seperti itu.

Setiap nilai kolom harus ditentukan oleh tim. Dalam gambar di atas, saya memberikan nomor acak ke kolom; angka Anda mungkin berbeda secara signifikan. Juga, jumlahnya belum final. Sesuaikan angka ketika Anda mengidentifikasi dan menghapus kemacetan.

Mengalokasikan Sumber Daya Secara Dinamis

Salah satu kualitas Kanban dan Lean yang paling menakjubkan adalah pentingnya kolaborasi dan realokasi usaha. Seperti yang Anda lihat di papan tulis, setiap kolom proses kami berisi kartu dengan orang-orang di dalamnya. Ada delapan pengembang di papan contoh - tim yang cukup besar! Dewan selalu menyajikan status saat ini siapa yang melakukan apa pada waktu tertentu.

Menurut dewan, ada tiga orang yang mengerjakan desain, dua pasang yang bekerja pada pengembangan dan satu pengujian pengembang. Cerita pindah ke kolom berikutnya, pekerjaan mereka di kolom saat ini selesai, dan tergantung pada jenis pengembangan dan organisasi tim, pengembang yang sama dapat terus mengerjakan kisah yang sama saat bergerak melalui proses.

Anggaplah kita memiliki orang-orang yang terspesialisasi. Jadi fungsi utama tiga desainer adalah desain, empat pengembang menulis kode, dan tester yang kesepian terutama menguji produk/fitur. Jika seorang perancang menyelesaikan sebuah cerita, ceritanya berpindah ke pengembangan dan cerita lain dari daftar yang harus dilakukan ditarik ke dalam desain.

Ini adalah proses normal. Sebuah cerita dipindahkan dari desain ke pengembangan, dan sekarang perkembangannya adalah pada cerita maksimumnya. Tetapi bagaimana jika desainer lain menyelesaikan cerita lain? Itu memberi tim pengembang empat cerita - situasi yang tidak diinginkan.

Lean ingin menghindari kemacetan. Dilarang memindahkan cerita ke kolom berikutnya jika melebihi maksimum kolom. Dalam hal ini, sumber daya perlu dialokasikan kembali; perancang yang menyelesaikan tugas mereka harus memilih apa yang harus dilakukan selanjutnya. Pilihan pertamanya adalah menarik tugas lain dari kolom yang harus dilakukan, tetapi dia tidak bisa melakukan itu karena dia harus meneruskan tugasnya yang baru selesai kepada tim pengembangan (yang tidak bisa dia lakukan). Satu-satunya pilihan lainnya adalah mulai mengerjakan cerita pengembangan. Dia mungkin bukan pengembang terbaik, tetapi usahanya akan membantu menjaga aliran proses.

Jika penguji menyelesaikan cerita terakhir di kolomnya, ia dapat membantu perancang pada tugas pengembangannya.

Ini hebat! Tim dapat mengatur kembali dengan cepat! Apakah Anda melihat sampah? Apakah Anda melihat hambatan dalam arus? Segera ambil tindakan!

Setelah sebuah cerita di kolom pengembangan selesai, tester kembali ke pengujian, perancang untuk merancang, dan para pengembang mengambil cerita yang sedang dikerjakan oleh perancang dan penguji. Namun perlu diingat bahwa Anda tidak harus mengikuti resep yang tepat; pengembang bisa mulai merancang sebagai perancang dan penguji selesai mengembangkan cerita mereka. Terserah kamu!

Dewan kita sekarang kembali normal.

Sambut Scrum-Ban

Dilarang memindahkan cerita ke kolom berikutnya jika melebihi maksimum kolom.

Saya menyaksikan dengan nostalgia saat scrum master membongkar papan kita. Sepotong demi sepotong, ia merobohkan papan tercinta, yang kemudian menjadi tumpukan kertas kusut.

Seorang rekan lain memasuki ruangan, beberapa lembar kertas putih segar di tangannya. Dewan kita akan dilahirkan kembali menjadi sesuatu yang berbeda, sesuatu yang lebih cocok untuk kebutuhan. Setelah lembar kertas berada di dinding, kita memulai rapat ad hoc untuk menentukan kolom yang dibutuhkan untuk mendefinisikan proses. Kita kemudian memperdebatkan jumlah cerita yang seharusnya ada di setiap kolom. Setelah semuanya dicat dengan hati-hati dan diatur di dinding, kita mengalami perasaan aneh itu... kesedihan untuk yang lama tapi kebahagiaan untuk yang baru.

Kita melakukan sesuatu yang oleh banyak orang disebut, Scrum-Ban. Kita menyimpan beberapa konsep scrum, seperti master scrum dan peran pemilik produk, dan kami masih memperkirakan dan mengevaluasi ceritanya. Tapi sekarang kita fokus pada Lean dan Kanban, melestarikan aliran, dan menemukan serta memperbaiki limbah dan kemacetan.

Perubahan dari Scrum menjadi Lean benar-benar membebaskan. Anggota tim menjadi lebih ramah satu sama lain, dan memahami bahwa harus menawarkan bantuan segera setelah tidak ada apa pun di kolom. Perasaan bahwa pengembang penting membuat kita berpikir tentang proyek secara keseluruhan; lebih peduli pada proyek daripada sebelumnya.

Pikiran Akhir

Lean tidak selalu dianggap Agile. Bahkan saat ini, beberapa Agilists menolak untuk mengakuinya sebagai metodologi Agile. Tetapi semakin banyak, para programmer menerima Lean sebagai salah satu metodologi Agile akhir.

Seperti yang ditunjukkan oleh salah satu rekan saya yang bijaksana, Lean dan Kanban memungkinkan Anda mengikuti metodologi ini sendiri. Jadi, jika Anda seorang pengembang tunggal dan memerlukan beberapa alat untuk membuat hidup Anda lebih mudah, cobalah beberapa alat Kanban gratis.

Situs web AgileZen menawarkan akun gratis, memungkinkan Anda melacak satu proyek.

Saya menemukan itu menjadi salah satu alat Kanban online gratis terbaik; Saya bahkan menggunakannya setiap hari untuk melacak dan merencanakan perkembangan artikel dan kursus yang saya berikan untuk Tuts+. Tentu saja, Anda selalu dapat meningkatkan akun AgileZen Anda, jika Anda perlu melacak lebih banyak proyek.

Dalam artikel ini, kita meninjau Lean dan Kanban sebagai evolusi Scrum. Apakah ini berarti bahwa Lean lebih baik daripada Scrum? Benar-benar tidak! Itu tergantung pada proyek dan orang-orang yang bekerja dengan Anda. Seperti biasa, pilih metodologi Agile yang paling sesuai untuk Anda dan tim Anda.