Kapan tim mendiskusikan persyaratan saat menggunakan Kanban?

Saya telah membaca sedikit tentang Kanban dan saya sedikit bingung dengan topik Persyaratan.

Dalam proyek saya saat ini, kami menggunakan Scrum. Pada awal Sprint, kami memiliki sesi di mana BA melakukan walkthrough dari Kisah dan menggambarkannya sebaik mungkin. Kami kemudian mengambil cerita, mengulasnya, membahasnya dan menyiapkan pertanyaan untuk BA untuk sesi perencanaan Sprint berikutnya. Pada sesi berikutnya, BA menjawab semua pertanyaan dan sesi selesai dengan kami setelah memahami persyaratan (sebagian besar waktu).

Langkah selanjutnya adalah kami kemudian menghasilkan desain teknis dan mengembangkan solusi / cerita.

Dengan Kanban, semua yang saya baca menunjukkan tidak ada Perencanaan Sprint di Kanban. Pertanyaan saya adalah pada titik apa (di Kanban) para teknisi dan orang-orang bisnis duduk bersama untuk membahas persyaratan cerita? Bukankah Manajer Produk atau BA memberikan panduan tentang Kisah di Kanban?

Dengan Scrum, BA biasanya tersedia di seluruh Sprint untuk mendukung pengembangan dan saya menganggap itu sama dengan Kanban. Tidak jelas bagi saya bagaimana dengan Kanban, para teknisi memahami cerita jika tidak ada perencanaan sprint.

Anda benar bahwa Kanban tidak memiliki konsep Sprint atau Sprint Planning seperti yang dilakukan Scrum. Itu karena metodologi yang lebih ramping . Lebih banyak hal dilakukan tepat waktu .

Terserah Anda untuk memutuskan bagaimana menjadwalkan kegiatan perencanaan, tetapi saya akan merekomendasikan melakukannya sedekat mungkin dengan awal pekerjaan. Ini paling efektif ketika ada perwakilan dari semua pemangku kepentingan utama yang tertanam dalam tim (hal yang sama juga membuat Scrum lebih efektif).

Saya pikir diagram ini, yang didasarkan pada Pengiriman Agile yang Disiplin , memberikan representasi gambar yang bagus dari proses perangkat lunak lean:

Acara-acara dari Harian Standup dan Perencanaan Sprint ditangkap di Rapat Koordinasi dan Pemodelan Pengisian Sesi. Rapat Koordinasi lebih seperti Standup Harian dari Scrum dan Sesi Pemodelan Pengisian lebih seperti Backlog Refinement dan Sprint Planning. Namun, tidak masalah untuk membawa beberapa diskusi persyaratan ke dalam Rapat Koordinasi jika itu berhasil untuk tim Anda.

Seperti kebanyakan hal dalam proses lean, ini terjadi tepat waktu. Tidak ada kotak waktu dan peristiwa tidak terjadi pada irama tertentu seperti yang mereka lakukan di Scrum. Anda melakukan pekerjaan saat itu menambah nilai bagi tim dan pemangku kepentingan.

Yang dapat Anda bandingkan dengan representasi gambar dari suatu proses berdasarkan Scrum yang dimodelkan dalam konteks Pengiriman Agile yang Disiplin:

Alih-alih memaksa diri Anda untuk 2-4 minggu Sprint dengan perencanaan di awal, stand-up harian, dan review dan retrospektif pada akhirnya, metodologi yang lebih ramping akan memberlakukan rapat demonstrasi, koordinasi, dan retrospektif Anda setiap kali para pemangku kepentingan berpikir bahwa itu sesuai .

Kanban akan memberikan panduan untuk mengelola simpanan pekerjaan Anda dan work-in-progress (WIP). Anda dapat beralih ke teknik dan metode lain untuk implementasi yang tepat dari aktivitas lain karena Kanban pada umumnya diam.

Anda sedikit salah mengartikan / salah paham tentang apa yang dilakukan rapat Perencanaan Sprint di Scrum yang saya pikir merupakan penyebab kebingungan Anda. Pertemuan Perencanaan Sprint biasanya merupakan tempat yang salah untuk menyelesaikan rincian cerita. Selain beberapa penyesuaian terakhir dan pencarian cepat untuk memastikan tidak ada kekhawatiran luar biasa yang akan secara signifikan memengaruhi perkiraan, kisah-kisah yang dianggap sebagian besar harus siap untuk melangkah. Dari sana, Perencanaan Sprint melakukan apa yang tertulis di kaleng: ia merencanakan apa yang akan ada di sprint mendatang. Jika Anda tidak memiliki sprint, maka tidak perlu Perencanaan Sprint.

Jadi, kapan detail dari cerita itu disempurnakan? Biasanya melalui Backlog Grooming atau dalam komunikasi yang sedang berlangsung selama sprint sebelumnya. Tujuannya di sini adalah untuk mendapatkan kejelasan yang cukup sehingga estimasi yang cukup percaya diri dapat diberikan. Ini tidak memerlukan setiap detail untuk dikerjakan sebelumnya. Tidak peduli berapa banyak Anda mencoba, akan selalu ada pertanyaan yang muncul selama implementasi. Sasaran dalam Scrum adalah agar pertanyaan-pertanyaan yang muncul selama implementasi relatif kecil (pada dasarnya, cukup kecil sehingga tidak memengaruhi perkiraan yang seharusnya).

Di Kanban, estimasi adalah opsional. Jika Anda benar-benar memperkirakan, maka kemungkinan besar Anda akan melakukan sesuatu yang mirip dengan Scrum dalam arti bahwa sebelum cerita diambil, dibahas untuk menyusun perkiraan. Jika Anda tidak melakukan estimasi, maka perilaku aktualnya serupa kecuali Anda tidak boleh mendiskusikan sebuah cerita sampai dimulai.

Dalam pengalaman saya, saya biasanya bekerja pada tim yang menggunakan pendekatan seperti Scrum untuk pengembangan utama dan kemudian beralih ke pendekatan yang lebih Kanban untuk fase pemeliharaan. Pekerjaan dalam fase pemeliharaan cenderung lebih sporadis, dan cerita-ceritanya lebih jelas didefinisikan pada skala kecil dan initio. Pada fase pengembangan utama, cerita seringkali dimulai pada tingkat tinggi dan perlu disempurnakan dan dipecah untuk mencapai titik di mana cerita tersebut dapat diterima untuk sprint. Memulai cerita seperti itu dalam konteks Kanban tidak masuk akal dan benar-benar akan membuat metrik Anda tenggelam.

Tidak ada peran "Analis Bisnis" resmi di Scrum atau Kanban. Adalah tim yang menganalisis dan memperkirakan cerita. Jika Perencanaan Sprint adalah pertama kalinya tim pengembangan mendengarkan detail cerita maka ada yang tidak beres. Saya tidak mengatakan Anda tidak dapat menggunakan BA atau bahwa setiap pengembang harus ada di setiap pertemuan pengumpulan persyaratan, tetapi beberaparepresentasi dari pengembang harus muncul di beberapa titik selama pengumpulan persyaratan sebelum Perencanaan Sprint. Seorang BA biasanya tidak memiliki pengetahuan yang cukup tentang rincian implementasi untuk mengetahui biaya barang atau pertanyaan apa yang mungkin memiliki dampak signifikan pada biaya. Ini berarti bahwa mungkin ada detail yang secara drastis dapat mempengaruhi taksiran yang tidak akan dikenali sampai tim pengembang melihatnya. Lebih lanjut, pengembang mungkin dapat memberikan panduan ke arah pendekatan yang lebih hemat biaya atau menyarankan fitur yang relatif mudah diimplementasikan tetapi mungkin menambah banyak nilai bagi pengguna. Apa yang saya curigai mungkin terjadi dalam kasus Anda, adalah bahwa pengembang membantu BA karena BA melakukan pengumpulan persyaratan (misalnya menjawab pertanyaan untuk BA atau memberikan beberapa perkiraan besarnya), dan bahwa ini secara kasar menggantikan Backlog Grooming. Atau, Anda melakukan pekerjaan (mis. Pekerjaan pemeliharaan) yang secara alami datang dalam paket yang relatif kecil, dalam hal ini Kanban mungkin merupakan proses yang lebih tepat.

Saya mengedit jawaban saya berdasarkan umpan balik yang saya terima untuk membantu lebih lanjut memahami bagaimana dan kapan Anda harus bekerja pada tahap Persyaratan dan Perencanaan Sprint Sprint Anda; seperti juga pada penerapan Metode Kanban untuk proses Anda saat ini. Untuk keperluan tanggapan saya, saya menggunakan istilah "Kanban" dan "Metode Kanban" secara bergantian, yang keduanya saya maksud sebagai rekomendasi dari Metode Kanban. Saya harap ini membantu.

Pertama, Anda tidak boleh mengubah apa pun tentang pengembangan Persyaratan / proses elaborasi "untuk Kanban" - karena Kanban tidak membuat rekomendasi apa pun di sana. Semua rekomendasi Kanban adalah bahwa Anda memvisualisasikan proses Anda saat ini, termasuk di sekitar manajemen Persyaratan dan Perencanaan Sprint, menerapkan Batas WIP dan mengelola Flow. Setelah itu, buat perubahan apa pun pada proses Anda berdasarkan hambatan dan peluang untuk perbaikan yang diamati.

[Saya sangat menyarankan, bahwa jika Anda belum melakukannya, silakan baca buku - " Kanban: Perubahan Evolusi Sukses untuk Bisnis Teknologi Anda " oleh David Anderson, pelopor Metode Kanban. (Penafian penuh - Saya adalah salah satu pendiri di perusahaan produk Kanban. Saya juga seorang Pelatih dan Pelatih Kanban yang bersertifikat Universitas Lean Kanban.)

Kanban sendiri bukanlah pengembangan perangkat lunak / metodologi manajemen proyek. Tanpa proses yang ada, Anda tidak dapat menerapkan / mengimplementasikan Kanban. Ini adalah metode untuk membantu Anda meningkatkan secara evolusioner (bertahap, tanpa gangguan) apa pun proses Anda saat ini. Dalam kasus Anda, itu adalah Scrum. Jadi, Anda harus benar-benar menerapkan Kanban pada proses Scrum Anda untuk membantu tim Anda meningkatkan pengiriman perangkat lunaknya. Kombinasi ini dikenal sebagai Scrumban.

Anda akan mulai dengan mengikuti 3 prinsip dasar Kanban -

1. Mulailah dengan apa yang Anda lakukan sekarang
2. Setuju untuk melakukan perubahan evolusioner dan bertahap
3. Hormati proses, peran, jabatan, dan tanggung jawab saat ini

Dengan menggunakan ini sebagai prinsip panduan Anda, Anda kemudian menerapkan praktik standar Metode Kanban - yaitu -

1. Visualisasikan proses Anda saat ini (dan pekerjaan yang sedang berlangsung)
2. Limit WIP (Work-in-Progress)
3. Kelola Aliran
4. Buat kebijakan proses eksplisit

Mulailah dengan 4 praktik ini. Ada 2 praktik lain yang didefinisikan dalam Metode Kanban yang dapat Anda lihat segera setelah Anda memulai dan memiliki pegangan. Ini adalah (5) Terapkan Umpan Balik, dan (6) Tingkatkan & Berkembang Secara Kolaboratif, menggunakan Metode Ilmiah.

Ini adalah ringkasan cepat - buku ini akan sangat membantu Anda mendapatkan pemahaman yang lebih baik tentang ini. Ada juga Panduan Kanban komprehensif yang tersedia di situs web kami.]

Yang penting untuk fokus pada situasi Anda adalah memvisualisasikan (di papan Kanban) apa yang Anda lakukan hari ini. Proses Persyaratan Anda saat ini harus diikuti selama proses Perencanaan Sprint atau beberapa sub-langkah yang mungkin Anda pilih untuk divisualisasikan. Papan Kanban Anda harus, pada kenyataannya, mencerminkan perencanaan Sprint sebagai tahap spesifik dari proses pengembangan secara keseluruhan, diikuti oleh desain teknis, pengembangan dan pengujian, tergantung pada kasusnya.

Sementara cerita pengguna berada dalam tahap perencanaan sprint, Anda akan mengikuti langkah-langkah di dalamnya seperti BA memberikan Anda detail, pengembang menyiapkan pertanyaan dan membuat mereka dijawab sebelum cerita bergerak ke tahap desain teknologi dan seterusnya.

(BTW, jika proses Persyaratan Anda memiliki aspek-aspek hulu yang mungkin dianggap sebagai bagian dari perencanaan peta jalan atau perawatan tunggakan, ada keseluruhan topik "Kanban Hulu" yang membantu Anda mengelola aktivitas hulu dengan lebih baik sedetail mungkin mereka ada hari ini. Anda atau BA / PO Anda dapat mempertimbangkan untuk menggunakan papan Kanban hulu terpisah untuk mengelola semua aktivitas itu.)

Aliran papan Dev Kanban Anda mungkin terlihat seperti di bawah ini -

Backlog -> Perencanaan Sprint -> Desain Teknologi -> Dev -> Tes -> Integrasi -> Selesai

Masing-masing tahap mungkin memiliki sub-kolom "In-Progress" dan "Done" sendiri - walaupun jika satu pengembang mengambilnya melalui semua tahap, Anda mungkin tidak memerlukan sub-kolom tersebut di setiap tahap. Jika Anda merasa itu penting, Anda dapat memecah Perencanaan Sprint menjadi 3 sub-tahap - Perincian Cerita, Klarifikasi, dan Selesai, sehingga berpotensi Anda dapat mempelajari kemacetan di setiap aspek pekerjaan. Misalnya, di tim pengembang kami sendiri, peninjauan kode sering kali menjadi penghambat!

Di akhir siklus sprint 2 atau 3 minggu Anda, semua cerita pengguna yang selesai dapat keluar secara kolektif - dan Anda mulai dengan kumpulan cerita berikutnya dari Backlog.

Selama periode waktu tertentu, Anda mungkin memutuskan bahwa beberapa tantangan melakukan Scrum (kebocoran cerita, tenggat waktu sprint yang terlewat, dll.) Mungkin dapat diatasi dengan menghilangkan beberapa kendala / aturan Scrum - yang mungkin tampak seperti haram bagi sebagian orang. Kami sendiri melakukan Siaran 4-6 minggu - dan jangan melakukan Sprint. Tapi sama baiknya, Anda bisa terus bekerja dengan Sprint dan Rilis. Dalam pengalaman kami, di sinilah Kanban membantu Anda memutuskan apa yang tepat untuk bisnis atau tim Anda dan mengadopsi atau memodifikasi proses Anda yang membantu Anda memberikan pekerjaan Anda dengan cara terbaik, yang memaksimalkan aliran, kecepatan / kecepatan dan mengurangi waktu pengiriman yang cepat ( waktu ke pasar).

Apakah Anda memutuskan untuk tidak menggunakan Sprint dan hanya membuat rilis saat dan ketika sejumlah fitur telah dibangun (atau cacat diperbaiki atau kombinasi keduanya) - atau apakah Anda mempertahankan Sprint - Kanban harus membantu tim Anda bekerja lebih lancar, menghilangkan kemacetan dan meningkatkan kinerja waktu siklus. Jika itu membantu Anda membuat rilis yang lebih sering yang pada gilirannya membantu Anda mendapatkan umpan balik pelanggan yang lebih cepat, sekarang Anda pindah ke apa yang Anda sebut keadaan "lebih gesit", tetapi yang mungkin tidak selalu sesuai dengan definisi klasik dari metode Scrum.

Namun, jika tujuan bisnis dipenuhi dengan lebih baik, pelanggan lebih bahagia dan tim Anda dapat berfungsi secara optimal, maka Anda akan mencapai tujuan Anda menerapkan Kanban.

Semoga ini membantu. Jika Anda memiliki pertanyaan, saya akan dengan senang hati menjawabnya.

Untuk secara khusus mengasah pertanyaan Anda ...

Apa gunanya (di kanban) para teknisi dan pengusaha duduk bersama untuk membahas persyaratan cerita? Bukankah Manajer Produk atau BA memberikan panduan tentang Kisah di Kanban?

Metode Kanban seperti yang dipelopori oleh David Anderson tidak mengandung praktik atau rekomendasi spesifik kapan aktivitas ini terjadi. Jawaban yang akan diberikan oleh setiap praktisi Kanban adalah bahwa pada awalnya ketika Anda mengadopsi Metode Kanban , Anda harus melakukan kegiatan ini dengan cara yang sama seperti yang Anda lakukan sebelum Anda memutuskan untuk mengembangkan cara Anda mengelola pekerjaan. Jika Anda melakukannya setiap 2 minggu, Anda harus terus melakukannya setiap 2 minggu.

Tim Anda akan mengetahui apakah ada peluang dan nilai dalam mengubah jadwal. Ingat bahwa jadwal 1 bulan lebih gesit dari 1 tahun, jadwal 2 minggu lebih gesit dari 1 bulan, 1 minggu lebih gesit dari 2 minggu. Pemikiran ini pada akhirnya membuat kita tepat pada waktunya sebagai yang paling gesit . Menjadi yang paling gesit tidak harus menjadi kondisi target bahkan sebelum Anda mulai.

Dengan Scrum, BA biasanya tersedia di seluruh Sprint untuk mendukung pengembangan dan saya menganggap itu sama dengan Kanban. Tidak jelas bagi saya bagaimana dengan Kanban, para teknisi memahami cerita jika tidak ada perencanaan sprint.

Metode Kanban sebagai pola pikir dan serangkaian praktik tidak menempatkan kondisi atau kendala pada keberadaan Sprint, pertemuan Perencanaan Sprint, atau praktik lainnya. Ini sepenuhnya menghormati tim Scrum dan praktik mereka. Jika Anda memiliki pertemuan hari ini di mana Techies mendiskusikan cerita tersebut, Anda akan terus mengadakan pertemuan itu, menggunakan jadwal yang sama.

Dengan hati nurani yang baik saya tidak bisa memberi tahu Anda apa jadwalnya / seharusnya / bisa tanpa memahami tim Anda dan organisasi di sekitarnya. Jika Anda tidak melakukan kegiatan ini hari ini, ada banyak sumber informasi lain untuk mengajari Anda cara melakukan kegiatan ini. Metode Kanban dapat memberikan panduan tentang mengajar Anda untuk mengetahui apakah pilihan Anda adalah pilihan yang baik.

Silakan baca tulisan blog dalam dua seri ini. Satu dari saya sendiri, dan satu dari Steve Porter, anggota Tim di Scrum.org.

Tidak ada di Kanban Mencegah Scrum - Dave White - WesternDevs.com

Scrum dan Kanban - Stronger Together - Steve Porter - Scrum.org

Sebagian besar yang dikatakan Mahesh Singh di atas berasal dari materi pelatihan yang diterbitkan Lean Kanban Inc. Jadi, sungguh ... tidak ada yang perlu diperdebatkan di sini. Bicaralah dengan AKT atau KCP dan dia akan mengatakan hal yang sama.

Untuk pertanyaan awal tentang di mana Anda bisa melakukan klarifikasi persyaratan, ada berbagai opsi:

1. Anda bisa melakukan apa yang Anda lakukan hari ini tetapi dengan memvisualisasikan dan menempatkan langkah-langkah itu pada aliran nilai, identifikasi hambatan Anda. Kemudian, buat satu perubahan dan lihat bagaimana itu bekerja. Komunitas Toyota Kata menyebut ini sebagai percobaan faktor tunggal.

2. Lakukan papan hulu untuk Pemurnian, dekomposisi, perancangan UX / interaksi hulu, dll. Dalam tim kami sendiri, kami memecah Tema menjadi Epik, melakukan siklus desain UX penuh dan baru kemudian memecahnya menjadi cerita. Kemudian, cerita diprioritaskan dengan mengajak semua pemangku kepentingan dalam pertemuan. Akhir dari aliran nilai ini menghasilkan cerita-cerita yang disempurnakan dan diprioritaskan. Itu merupakan jaminan kami untuk tim pengembangan. Sebenarnya, aliran ini membutuhkan banyak waktu siklus, terutama karena dibutuhkan waktu untuk beralih dari persyaratan level Epic ke wireframe di Sketch atau Zeppelin untuk tim Pengembang.

3. Jika Anda tidak memiliki aliran nilai yang signifikan atau waktu siklus untuk mengonversi sesuatu dari keharusan menjadi cerita yang disempurnakan, maka Anda bisa memiliki tahapan dalam aliran nilai Pengembangan Anda (seperti klarifikasi Persyaratan). Namun, Scrum mengharapkan kejelasan tingkat tinggi untuk estimasi dan menerobos tugas. Jadi, apakah Anda melakukan pertemuan sebelum pertemuan perencanaan Sprint atau melakukan pertemuan perencanaan Sprint yang diperpanjang, itu akan tergantung pada tim dan organisasi Anda.

Jika kita mengingat prinsip-prinsip dan terbuka pada praktik yang ditentukan, siklus Inspeksi dan Adaptasi menjadi lebih mudah.