Get best of the week

Metode Kanban: Memahami Proses Anda sebagai Proses Pembelajaran Kolektif

Kata pengantar


Dalam komunitas profesional manajer proses berbahasa Rusia, ada sangat sedikit literatur tentang metode Kanban dalam bahasa Rusia. Kami memutuskan untuk memperbaiki ketidakadilan ini dan kami akan menerbitkan artikel paling signifikan dari sudut pandang kami dalam bahasa Rusia, yang memengaruhi pengembangan metode ini.

Memahami proses Anda sebagai proses pembelajaran kolektif


Dan artikel pertama dalam seri tentang cara membangun visualisasi proses kerja Anda secara lebih efisien dan memahami papan. Penulis artikel asli adalah Alexei Zheglov dan dapat ditemukan di sini.Ada

kecenderungan dan keinginan umum untuk membuat karya lebih kolektif. Namun, ketika saya meminta orang di kantor untuk menggambar proses pekerjaan mereka, mereka sering memberikan sesuatu seperti ini (saya sederhanakan):


Dalam pandangan ini, pekerja membentuk ban berjalan, tetapi pekerjaan mereka tidak benar-benar terlihat seperti jalur perakitan. Misalnya, pengembang perangkat lunak dapat mendeteksi inkonsistensi logis dalam spesifikasi persyaratan dan mengirim pekerjaan kembali ke intelijen bisnis. Seorang insinyur kualitas (QA) dapat melakukan hal yang sama ketika menguji perangkat lunak yang dibuat. Analis akan memperbarui spesifikasi dan mengirim tugas kembali ke QA. QA dapat menemukan kesalahan di dalamnya dan mengirimkannya kembali ke pengembang. Seorang spesialis implementasi mungkin menemukan sesuatu dalam kode yang mencegah pengiriman. Kemudian pengembang melakukan perubahan yang diperlukan. Sekarang kode perlu diuji ulang, sehingga kembali ke QA, setelah itu kembali ke implementasi.

Interaksi seperti itu terjadi tidak hanya antara anggota tim individu, tetapi juga (penting) antara departemen perusahaan, layanan dan tim lintas fungsi. Oleh karena itu, orang menggambar banyak panah yang terhubung dalam konfigurasi berbeda untuk menunjukkan semua program ini.

Beberapa mencoba memvisualisasikan proses ini di papan yang mereka sebut "kanban":


Kemudian mereka bertanya pada diri sendiri: Bagaimana jika, misalnya, tester mengembalikan item pekerjaan kembali ke analis atau pengembang? Haruskah kartu tetap di tempatnya atau bergerak? Bagaimana jika kita memiliki batas WIP (angka-angka ini ada di tajuk kolom)? Bagaimana jika kolom ini sudah terisi hingga batas, kartu lain harus kembali?

Apakah ada cara yang lebih baik?


Pertanyaan ini cukup umum dan berakar pada kesalahpahaman tentang sifat pekerjaan layanan profesional. Alih-alih serangkaian transmisi antara pekerjaan khusus, ini terutama tentang menciptakan informasi dan mengumpulkan pengetahuan. Ini menjadi kendala ketika mencoba membuat prosesnya terlihat seperti bagan alur. Serta batasan ketika mencoba memvisualisasikannya, mengikuti pelaksanaan pekerjaan.

Dalam contoh pengiriman fungsionalitas baru produk perangkat lunak, pengetahuan berikut dapat dibuat (tidak harus dalam urutan ini):

  • konfigurasi yang tepat dari lingkungan kerja (OS, server web, server basis data, perangkat lunak pihak ketiga)
  • contoh kunci dari perilaku fungsionalitas yang dikembangkan, kasus penggunaan, kriteria penerimaan, spesifikasi yang dapat dieksekusi, dll.
  • ( , . .)
  • -
  • : , , ..
  •   , .

Setiap orang dalam layanan profesional apa pun dapat membuat daftar pengetahuan mereka sendiri yang mereka buat dalam proses pengiriman mereka. Ketika pekerjaan selesai, semua pengetahuan ini sudah ada di sana, tetapi ketika kita baru mulai bekerja pada kebutuhan klien atau permintaan untuk penyediaan sesuatu, ini semua hilang.

Jika kami mencoba memvisualisasikan proses mengumpulkan pengetahuan ini, hasilnya bisa terlihat seperti ini:


Dalam contoh ini, spesifikasi pekerjaan dominan pada tahap awal dalam proses pengiriman. Analis bisnis dapat melakukan analisis fungsional, dekomposisi, dan penyempurnaan persyaratan. Tetapi pada saat yang sama, profesional lain dapat berkontribusi. Penguji dapat membantu mengubah kriteria penerimaan menjadi tes yang dapat dieksekusi. Spesialis dan pengembang penyebaran dapat mengevaluasi dampak pada basis kode dan infrastruktur.

Kegiatan ini menghasilkan banyak pengetahuan di awal, tetapi pada akhirnya memudar. Kami tidak dapat menganalisis tanpa henti hingga pengiriman. Dengan demikian, pengembangan kode di beberapa titik menjadi cara utama mengumpulkan pengetahuan.

Tentu saja, sebagian besar pengembangan kode berada di pundak pengembang, tetapi yang lain juga bisa membantu. Persyaratan mungkin masih membutuhkan klarifikasi dan klarifikasi (halo analis). Penguji dapat mengambil sebagian perangkat lunak yang sudah jadi, mengujinya dan memberikan umpan balik kepada pengembang. Pengembang dapat berkolaborasi dengan spesialis implementasi untuk melihat bagaimana perubahan yang muncul akan berdampak pada penerapan.

Namun aktivitas ini akan memudar. Kami tidak dapat membuat kemajuan lebih lanjut dengan memoles kode. Jadi, kami beralih ke mengujinya.dan fokus untuk menyelesaikan kesalahan yang tersisa. Aktivitas lain dalam studi pengetahuan mulai mendominasi. Penguji bertanggung jawab untuk itu, tetapi mereka membutuhkan bantuan dari pengembang, perbaikan bug, serta spesialis lainnya.

Perhatikan bahwa tiga titik kritis dalam diagram proses baru bukanlah transfer antara spesialis fungsional atau departemen. Ini adalah perubahan dalam aktivitas dominan dan perubahan yang sesuai dalam pola interaksi.

Kesimpulan


Kami tidak perlu mempertimbangkan proses sebagai jaringan spesialis dan transfer otoritas. Ketika kami mencoba memvisualisasikan proses kami secara visual, kami tidak perlu menampilkannya dalam bentuk balok yang menggambarkan spesialis, dan banyak panah yang menghubungkannya ke segala arah.

Sebaliknya, kita dapat melihat proses pengiriman kami sebagai memperoleh informasi dan menciptakan pengetahuan. Bertanya pada diri sendiri pertanyaan, tindakan apa yang kita lakukan untuk mengumpulkan pengetahuan untuk memberikan apa yang kita berikan , kita dapat memvisualisasikan proses kita sebagai urutan tindakan bersama.

Apa berikutnya?


Dalam beberapa artikel berikutnya, saya ingin memberikan contoh refleksi dari proses akumulasi pengetahuan, untuk proses di luar dunia pengembangan perangkat lunak.

Saya perlu menyiapkan sejumlah artikel, sebagai rekomendasi: bagaimana spesialis proses dapat menyusun refleksi proses dengan tim layanan profesional . Bagi mereka yang menggunakan sistem Kanban, pendekatan ini memiliki beberapa keunggulan dalam desain dan pengoperasian sistem ini.

Terima kasih banyak kepada Aleksey Pimenov danStepev.

More articles:


All Articles