Halo, Habr! Nama saya Maxim Lutzau, di Promsvyazbank saya bekerja sebagai pemilik produk. Selama hampir satu tahun, pengembangan bank Internet Bisnis Saya yang baru telah berjalan dengan kerangka kerja Scrum, dan dalam hal ini, saya sudah berhasil mengisi benjolan. Dalam posting ini, saya ingin berbicara tentang yang paling menyakitkan dari mereka, serta tentang alat apa yang akhirnya membantu kami. Sehingga Anda bisa terhindar dari masalah seperti itu.
Beberapa karyawan pada dasarnya menentang perubahan
Kerangka kerja scrum diadopsi di bank kami untuk mempercepat pengembangan dan mengurangi TTM. Ketika implementasi dimulai, ternyata beberapa karyawan tidak siap untuk ini. Mereka tidak mengerti mengapa ini perlu dan apa yang akan diberikannya.
"Kami dulu bekerja dengan baik, mengapa kita membutuhkan ini?", "Mengapa kita tidak melakukannya secara berbeda?", "Siapa yang datang untuk mengajari saya ini, bagaimana dia tahu bahwa ini lebih baik?" - Pertanyaan serupa terus-menerus menghujani mereka. Dan bahkan ketika karyawan ini menerima jawaban, setelah beberapa saat semuanya terulang lagi.
Solusi paling masuk akal dalam hal ini adalah memindahkan orang ke proyek lain. Ini harus dilakukan tentu saja, karena seseorang yang memancarkan negatif dapat mempengaruhi semua orang. Dalam sejarah kita, inilah tepatnya yang telah disembuhkan oleh kolektif kita - ketegangan umum telah lenyap, dan setiap orang mengikuti persepsi informasi baru.
Reaksi negatif terhadap perubahan tidak tergantung pada usia. Pengembang yang kami bicarakan di atas berusia sedikit di atas 30 tahun. Pada saat yang sama, seseorang yang sudah berusia lebih dari 50 bekerja dengan sempurna di tim kami - ia tidak memiliki masalah dengan Scrum.
Sulit berinteraksi dengan orang-orang yang tidak hidup oleh Scrum.
Setiap organisasi harus berkolaborasi dengan orang-orang yang tidak bekerja di Scrum. Dalam kasus kami, ini adalah tim dari proyek dan departemen lain. Mereka biasanya memiliki tahapan implementasi proyek yang jauh lebih lama. Jujur, hanya pengembang RBS yang bekerja untuk kami di Scrum sejauh ini.
Kami memutuskan untuk tidak melakukan apa-apa dengan masalah ini - untuk tidak masuk ke pekerjaan orang lain dengan scrum kami. Kami hanya meminta mereka untuk melakukan apa yang kami butuhkan. Ketika mereka kembali dengan solusi, kami mulai menghubungkan tugas-tugas mereka. Jangan menyulitkan interaksi jika budaya perusahaan belum matang dengan sendirinya. Tentu saja, setelah pelatihan scrum ada keinginan untuk mengubah segalanya, tetapi lebih baik berhenti tepat waktu.
Meskipun kami tidak terburu-buru unit lain, bekerja sama dengan kami mereka mulai bekerja lebih cepat. Kami mengundang penjaga keamanan ke pertemuan dan demo kami, dan sekarang menyetujui pembebasan yang sudah selesai hanya perlu satu hari. Sebelum itu, perlu dari satu minggu ke dua.
"Kami tidak akan tepat waktu untuk sprint!"
Setelah mengimplementasikan Scrum, kami beralih dari periode pelaporan bulanan ke sprint dua minggu. Pada awalnya, karena skala tugas, mereka tidak ingin mengompresi tenggat waktu. Tetapi menyesuaikan ukuran sprint dengan apa yang perlu dilakukan adalah kesalahan besar. Sebaliknya, Anda perlu menyesuaikan rencana untuk durasi sprint. Untuk melakukan ini cukup sederhana - hanya menguraikan tugas. Ketika ukurannya berkurang, mereka lebih mudah diatur sesuai rencana, untuk memberi mereka prioritas. Kumpulan kode yang lebih kecil lebih cepat untuk menguji, memverifikasi, bernegosiasi dengan penjaga keamanan. Secara umum, saya bahkan akan merekomendasikan mengurangi durasi sprint, jika mungkin, dari dua minggu menjadi satu.
Ketika seseorang dari tim tidak punya waktu untuk melakukan semua yang direncanakan pada akhir sprint, ada keinginan alami untuk menunda demo - untuk datang ke sana dengan senjata lengkap. Tetapi dalam hal ini, Anda masih harus mematuhi jadwal. Dalam kasus apa pun, ada baiknya berbicara tentang hasil pekerjaan: apa yang mereka lakukan, apa dan mengapa mereka tidak, apa yang mereka lakukan agar tepat waktu. Jadi kita tidak lari dari masalah, tetapi bertatap muka dengan mereka dan kemudian kita bisa menemukan solusi bersama.
Pendekatan ini meningkatkan motivasi, setelah demo yang direncanakan tidak berhasil, tanggung jawab untuk pekerjaan tumbuh. Jika sebelum pengembang menyiapkan dudukan untuk demo dalam lima menit, sekarang mereka melakukannya sehari sebelum demo, dan kemudian mereka memoles gundukan yang tersisa untuk membuat semuanya super.
"Mengapa kita perlu stand-up harian?"
Pada awalnya, rekan-rekan merasa skeptis tentang teralihkan dari pekerjaan biasa mereka di pertemuan stand-up setiap hari. Bahkan jika mereka diadakan online dan hanya membutuhkan 10 menit.
Dalam memecahkan masalah ini, dorongan simbolis dari seseorang yang menemukan bahasa yang sama dengan tim membantu. Suatu kali, demi kesenangan, saya mengatakan bahwa saya akan menandai di kalender orang-orang yang datang untuk berdiri, dan mulai memberi tanda plus. Hasilnya tidak terduga, dan efeknya terlihat setelah satu sprint. Tidak ingin dibombardir, para pengembang sendiri datang untuk berdiri. Itu bahkan tumbuh menjadi lelucon umum kami: sekarang mereka mengancam untuk memberi nilai minus kepada saya ketika saya tidak dapat menghadiri pertemuan apa pun.
Banyak orang berpikir bahwa rapat scrum membutuhkan banyak waktu. Cukup untuk menghitung di sini apakah benar demikian. Kami mendapat dua jam seminggu dari 40. Ini tidak begitu banyak untuk mengatur pekerjaan dan tetap up to date dengan semua hal.
Jika seluruh tim tidak ingin pergi ke pertemuan stand-up, dan pertemuan itu sendiri tidak terlalu aktif, ini merupakan sinyal bahwa pekerjaannya salah. Seolah pertemuan tertunda lebih dari 15-20 menit. Sebuah cerita tentang aktivitas dan rencananya dalam diri seseorang tidak boleh lebih dari satu atau dua menit.
Satu aturan lagi terhubung dengan manajemen waktu. Jika pembahasan tugas memakan waktu lebih dari 30 menit, kami menghentikannya. Ini berarti bahwa kami tidak punya waktu untuk mengembangkan tugas, bahwa tugasnya tidak terurai dan masih membutuhkan waktu. Ini layak untuk diperhatikan. Kami menetapkan batas waktu 30 menit untuk diri kami sendiri - setiap perusahaan perlu membuat penghalang sendiri.
Tunggakan yang tak bisa dipahami
Keberhasilan Scrum terutama tergantung pada perencanaan yang jelas. Penting untuk menentukan berapa banyak tugas yang harus dievaluasi dan dijelaskan, dan mana yang dapat ditunda untuk saat ini. Jangan mencoba untuk menutup semuanya sekaligus. Pengembang perlu memahami apa yang akan ia lakukan dalam dua sprint berikutnya. Untuk periode yang lebih lama, ide kasar sudah cukup - nanti, semakin sedikit detailnya.
Manajemen mikro yang tidak pantas
Apa yang dilakukan pengembang hari ini? Apa yang akan terjadi besok? Kebetulan manajer mengajukan pertanyaan seperti itu secara teratur. Kami dapat menjelaskan kepada manajemen kami bahwa semua poin yang menarik dapat ditemukan di papan scrum kami atau dengan datang ke stand-up harian. Tidak ada laporan khusus dengan tabel dan pemantauan tugas di Jira. Kami berhasil memeras manajemen mikro ini ke pertemuan mingguan dengan manajemen, tempat saya melaporkan tugas-tugas khusus yang dilakukan oleh tim.
Sesuatu yang hampir tidak pernah ditulis
Akhirnya - ada masalah yang jelas, yang hampir tidak pernah saya temukan. Tidak perlu mencoba menggabungkan master scrum dan pemilik produk. Yang terakhir adalah membangun unit bisnis, mengerjakan backlog, dan melakukan KPI. Dia tertarik pada kesuksesan produk dan mencoba menyelidiki segalanya - karena itu, dia mulai membuat janji, mendiskusikan beberapa detail. Secara umum, ia memuat dirinya sendiri dengan banyak fungsi, karena hanya ada waktu tersisa untuk backlog.
Ini terjadi pada saya. Saya mengatur pertemuan, stand-up, memecahkan masalah anggota tim. Karena hal ini, jaminan simpanan tidak berhasil, yaitu tidak ada waktu untuk kegiatan utama. Sekarang kami telah menemukan manajer pengembangan yang memiliki wewenang atas tim dan juga mulai melakukan fungsi master scrum, karena ia memiliki lebih banyak pengalaman bekerja pada kerangka kerja ini. Sekarang saya dapat pindah dari Scrum dan berkonsentrasi penuh pada tugas-tugas pemilik produk, yang, pada gilirannya, harus memikirkan persyaratan. Tanpa persyaratan yang baik, tidak akan ada produk yang baik. Akibatnya, jaminan simpanan mulai membaik, para kolega mulai memahami bagaimana kami akan melanjutkan.
Sekilas, Scrum tampaknya sangat sederhana, tetapi masih memiliki banyak jebakan. Kami telah mengerjakan kerangka kerja ini selama hampir satu tahun, tetapi baru sekarang kami mulai menilai kemampuan kami dengan lebih kurang jelas, mulai meningkatkan kecepatan pembangunan.