Sudah beberapa kali, berkomunikasi dengan kolega di konferensi dan kuliah, saya mendapat pertanyaan ini:
Sepertinya sudah waktunya untuk memperbaiki suatu jawaban dan merujuk pada kesempatan :)
Jadi, apakah manajemen pengetahuan Agile diperlukan, di mana informasi ditransfer dari orang ke orang? Bahkan, ini adalah kasus ketika jawabannya terkandung dalam pertanyaan itu sendiri. Informasi ditransmisikan dari orang ke orang, yaitu, ada pertukaran pengetahuan . Tradisi lisan adalah salah satu alat manajemen pengetahuan. Sangat tidak bisa diandalkan, tetapi tentu saja yang paling populer. Tugas orang yang bertanggung jawab atas manajemen pengetahuan adalah menciptakan lingkungan yang nyaman untuk berbagi pengetahuan. Tentu saja, dalam tim yang gesit, lingkungan akan berbeda dari struktur organisasi klasik. Tapi pada dasarnya jawabannya, tentu saja, "ya, itu perlu." Mari kita pahami lebih detail.
Mari kita mulai dengan manifest Agile itu sendiri. Penulisnya langsung mengatakan itu
“Artinya, tanpa menyangkal pentingnya apa yang ada di kanan, kami masih lebih menghargai apa yang ada di sebelah kiri”
Agile Manifesto tidak memberi tahu kami untuk "tidak mendokumentasikan apa pun"! Dia mengatakan bahwa pelanggan membayar uang untuk produk yang berfungsi. Jika dia menerimanya, maka dengan tidak adanya dokumentasi yang indah dia bisa menutup matanya, tetapi tidak sebaliknya. Manifes membantu memprioritaskan, tetapi tidak melarang. Dan bahkan jika Anda tidak punya waktu untuk berlabuh besar, dalam proses kerja sejumlah besar artefak manajemen pengetahuan dibuat, yang dapat Anda operasikan saat membuat keputusan baru: tiket, changelog, dll.
"Orang-orang dan interaksi lebih penting daripada proses dan alat."
Dalam satu penelitian yang dilakukan di antara pekerja TI, jelas bahwa
orang -
orang di industri TI menempatkan berbagi pengetahuan (yaitu
interaksi ) di tempat kedua di antara tantangan yang ada dalam pengembangan perangkat lunak.
Secara umum, hasil penelitian ini mengkonfirmasi tesis manifesto pertama. Tampak bagi saya bahwa kaki pertanyaan tumbuh dari fakta bahwa manajemen pengetahuan oleh banyak orang dalam pembangunan dipahami sebagai dokumentasi, dan bukan interaksi antara orang-orang dalam transfer pengalaman.
Ya, ngomong-ngomong, di salah satu posting sebelumnya saya sudah mengatakan bahwa pengetahuan bukan dokumentasi, tetapi pengalaman yang diperoleh dalam pelaksanaan proyek tertentu oleh karyawan tertentu . Bahkan jika Anda belum membuat dokumentasi produk, Anda pasti mendapatkan beberapa pengalaman selama proyek. Selain itu, alat Agile secara tidak langsung berkontribusi pada fakta bahwa pengalaman ini terus-menerus digeledah.
Misalnya, retrospektif . Apa ini jika bukan proses berbagi pengetahuan? Tim mengumpulkan, berbagi masalah yang ada (di bidang KM ini disebut "pelajaran yang dipelajari" ) dan mengembangkan rencana perubahan untuk menyelesaikan masalah ini. Artinya, orang-orang menggeledah melalui pengalaman mereka satu sama lain, mendiskusikannya, mengembangkan strategi untuk mengatasi ketidaknyamanan dalam waktu dekat, dan memperbaiki suatu rencana perubahan (artifak manajemen pengetahuan) di suatu tempat. Biasanya hasil pertemuan tersebut disimpan di suatu tempat. Saya tidak yakin bahwa ada perintah yang efektif yang, setelah menyelesaikan iterasi, menghapus data tentang semua retro masa lalu.
Atau memasangkan pemrograman . Bahkan Wikipedia memberi tahu kami tentang alat ini sebagai berikut:
Keuntungan:
***
Pendampingan
Setiap orang, bahkan seorang programmer pemula, tahu sesuatu yang orang lain tidak tahu. Pemrograman pasangan adalah cara yang tidak menyakitkan untuk menyebarkan pengetahuan ini.
***
Pelatihan
Pemrogram terus bertukar pengetahuan.
Dua programmer berpengalaman saling memompa, menggunakan pengalaman mereka sendiri. Tuan memompa juna, bertindak sebagai mentor. Tim mentoring umumnya adalah salah satu inkarnasi paling populer dari manajemen pengetahuan dalam pengembangan perangkat lunak. Yandex yang sama bahkan mulai mengajarkan seni ini secara lahiriah.
Atau ambil situasi saat menggunakan kanban. Misalkan penguji menguji 10 fungsi per bulan, dan pengembang berhasil menerapkan 20. Hal ini menyebabkan akumulasi pekerjaan di QA, dan karenanya, berisiko terhadap kualitas pekerjaan mereka. Dalam hal ini, Anda dapat, misalnya, mendistribusikan kembali sumber daya dan menghubungkan pengembang ke pembuatan autotest. Sebagai hasil dari iterasi, tim menerima pengalaman perencanaan negatif dan, berdasarkan itu, dapat menyusun rencana baru sedemikian rupa untuk memastikan throughput maksimum pipa dengan sumber daya yang sama. Artinya, dalam proses pengembangan, pengetahuan diperoleh (= pengalaman), setelah menganalisis yang mana, tim sampai pada optimalisasi proses.
Nah, ada pertanyaan yang sangat permukaan: apakah tim tidak akan menggunakan pengalaman yang didapat saat mengerjakan proyek saat mengerjakan proyek lain? Artinya, secara eksperimental untuk proyek saat ini, mereka menemukan bahwa mereka dapat menerapkan dengan pengujian rata-rata 15 fungsi per bulan. Tidakkah mereka akan berada di proyek baru lagi awalnya pada 20?
Pengetahuan adalah semua yang terjadi di sekitar proyek. Proses pengembangan tidak terjadi dalam ruang hampa. Koordinasi, tautan yang bermanfaat, interaksi dengan tim lain, orientasi pemula, dll. Setiap tim melewati ini. Dengan serangkaian pengalaman, berbagai artefak muncul, seperti daftar periksa adaptasi untuk pemula atau database tautan yang berguna. Ini adalah pengetahuan tetap atau hasil dari memahami pengalaman yang diperoleh.
Kita semua berpartisipasi dalam proses berbagi pengetahuan setiap hari (yah, sungguh, kita terus berkomunikasi satu sama lain!), Dan bekerja pada metodologi Agile tidak mengecualikan kita dari proses ini. Selain itu, sudah termasuk alat manajemen pengetahuan yang sangat efektif. Tetap hanya mengatur pekerjaan tim sehingga alat-alat ini memberikan pembuangan maksimum.
Dalam sebuah postingan saya berikan beberapa contoh saja. Mari kita bahas dalam komentar apa alat Agile lain juga alat manajemen pengetahuan. Baiklah, atau diskusikan mengapa saya salah :)