Saya PM di
layanan pengiriman surat
UniSender . 6 tahun yang lalu saya datang sebagai programmer, dan sekarang saya bertanggung jawab atas interaksi antara tim produk. Sebelumnya, pengembangan kami terdiri dari satu tim yang didistribusikan dan kami memiliki 2 masalah. Tapi bukan orang bodoh dan jalan, tapi penundaan sprint dan standup membosankan selama setengah jam.
Saya akan memberi tahu Anda bagaimana kami menyelesaikannya.
Seperti yang saya katakan, kami memiliki 2 masalah:
- Sprint bisa bertahan karena kesalahan satu tugas . QA dan Dev mengerjakan sprint yang sama, lingkup tugas diperbaiki pada awal pekerjaan, dan seluruh tim dengan gagah berani mengimplementasikannya. Kadang-kadang bug mendesak tiba yang pergi ke perbaikan terbaru "master". Tugas sprint bisa sangat produktif. Ketika beberapa tugas siap untuk dirilis, yang lain masih dalam pengembangan. Akibatnya, tim bisa menunda sprint karena satu tugas.
- Standup memakan waktu dan utilitas meragukan . Tim tumbuh, stand-up dilakukan di Skype, dan pada awalnya tidak ada masalah. Kami mulai curiga ada yang salah ketika stand-up mulai meregang selama 20-30 menit. Mereka yang hadir tidak selalu mengerti apa yang dilakukan anggota tim lainnya.
Selama beberapa waktu kami hidup dengan masalah-masalah ini, kemudian mencoba untuk berjuang.
- Mereka mengurangi stand-up melalui pengenalan peraturan tentang manusia.
- Mereka mengurangi jumlah yang hadir - hanya pemimpin tim yang pergi ke stand-up.
- Mencoba sprint mingguan.
- Mengurangi jumlah tugas dalam sprint.
Upaya ini tidak memberikan hasil yang diharapkan. Pemahaman telah datang bahwa perubahan radikal tidak bisa ditiadakan.
Di sini perlu untuk mengatakan beberapa kata tentang produk.
Kami adalah solusi SaaS yang tersedia 24/7. Selain bagian yang terlihat oleh pengguna - GUI - kami juga memiliki lapisan besar logika sistem yang berfungsi terlepas dari waktu hari atau situasi politik di negara tersebut. Artinya, pengembangan dan pembaruan layanan sedang berlangsung, tanpa henti.
Pergi ke Kanban
Revolusi skala besar pertama terjadi ketika kami menyadari: "Scrum tidak cocok untuk kita."
Kami memutuskan untuk beralih ke Kanban. Tentu saja, kami bukan Toyota dan tidak mulai menerapkan implementasi penuh. Karenanya, "kanban kami" akan berbeda dari "kanban Anda."
Sprint dan kerja tim
Singkatnya tentang versi kami:
- Kami menganggap sprint (bagian fungsional yang lengkap) sebagai unit kerja.
- Sebuah tim untuk tugas dikumpulkan tergantung pada beban dan keterampilan yang diperlukan. Satu tim biasanya memiliki hingga 3 pengembang dan 1 QA. Tidak ada tim permanen.
- Jumlah sprint simultan telah menjadi lebih dari satu.
- Tidak ada papan fisik dan atribut lain dari Kanban, tugas dilakukan melalui penambahan Jira.
Dalam hal ini, tim harus melakukan sprint dari awal hingga akhir. Ini juga diterapkan pada fase pengujian: orang yang sama yang bekerja pada sprint mengoreksi kesalahan.
Hasil.- Dengan keterlambatan tugas-tugas besar, yang lain tidak menderita, yang pengembangannya selesai.
- Jumlah masalah selama penerapan telah menurun - dalam satu sprint ada lebih sedikit tugas beraneka ragam.
Standup
Stand-up diubah - mereka dikunjungi oleh satu perwakilan dari masing-masing tim yang bekerja pada sprint terpisah.
Hasil.- Standup menjadi seperti standup dan kami kembali masuk ke standar 10-15 menit.
Dengan demikian, kami dapat memecahkan masalah kritis.
Tapi ... seluruh gunung es mulai muncul dari belakang pulau!
Setelah beralih ke Kanban, kami mendapat tim frontend khusus, dan ada lebih banyak karyawan di tim backend dan produk. Interaksi antara departemen menjadi lebih rumit - beberapa tim dapat bekerja pada satu proyek.
Kami memecahkan beberapa masalah, tetapi yang baru muncul:
- Tidak semua orang berpartisipasi dalam stand-up - seringkali tim harus menceritakan kembali informasi.
- Satu QA dapat memiliki 2-3 sprint paralel dengan tim yang berbeda. Saya harus beralih: ingat fitur sprint dan terus-menerus menyebarkan kembali kode pada lingkungan pengujian.
- QA tidak sepenuhnya terlibat dalam proses pengerjaan sprint. Seringkali tugas mencapai mereka di akhir sprint dan persyaratan dipelajari setelah pengembangan selesai.
- Tim berkumpul untuk proyek dan komposisi mereka sering berubah. Sebuah tim yang terdiri dari dua pengembang dapat mengerjakan 3 sprint secara bersamaan: 2 sprint pada tes plus 1 sprint saat ini.
- Sulit memperkirakan waktu pengembangan. Tidak jelas berapa lama sprint yang belum selesai akan memakannya.
Untuk beberapa waktu kami hidup dengan aturan baru dan berjuang dengan tantangan baru. Kami mencoba berbagai pendekatan dan mengisi banyak kerucut.
Pada akhirnya, kami mulai curiga bahwa ada sesuatu yang salah. Sebuah revolusi baru.
Pembagian dalam tim, stand-up baru, pengenalan Fireteam
Kami menganalisis proses dari awal ide untuk penyebaran implementasi selesai di prod. Kami melihat bagaimana metodologi tangkas bekerja di perusahaan lain. Kami menyadari bahwa pendekatan kami terhadap proses pembangunan tidak terlalu buruk.
Tidak perlu merusak sistem kerja, Anda harus memperbaiki momen yang menyebabkan rasa sakit.
Inilah yang kami ubah selama proses pengembangan.
Sprint
Kami masih beroperasi pada konsep "sprint." Sprint adalah lingkup pekerjaan “hampir dua minggu” untuk tim.
Apa itu plus. Kode tidak "memburuk" dan sampai ke prod tanpa penundaan yang signifikan. Jika tim akan melakukan sprint dalam 2 minggu - Anda perlu mencoba mengencangkannya menjadi sebulan.
Apa yang bisa diperbaiki. Seringkali kita melewatkan tanda dan sprint sedikit tertunda. Waktu untuk mengerjakan beberapa sprint pada awalnya sulit untuk dievaluasi (misalnya, banyak refactoring). Kita harus menyelesaikan masalah ini.
Pembagian menjadi beberapa tim
Kami membagi satu tim besar menjadi beberapa tim kecil. Masing-masing dari mereka termasuk 2-3 pengembang dan satu QA khusus. Sekarang tim sudah stabil dan tidak berubah dari proyek ke proyek. Kadang-kadang orang beralih di antara tim untuk mengoptimalkan daftar nama atau menambahkan keahlian yang diperlukan ke tim. BA berpartisipasi dalam tim, tetapi pada saat yang sama dapat memimpin 2-3 proyek.
Meskipun sisanya masih satu tim)Pada saat yang sama, seluruh tim mengerjakan satu proyek dari awal hingga selesai. Satu proyek dapat terdiri dari beberapa sprint.
Apa itu plus.- Tim berada di ruangan yang sama. Sebelum itu, semua orang duduk di departemen.
- Tim ini termasuk dalam pekerjaan pada proyek dari awal hingga akhir, yang mengurangi faktor bus.
- Anggota tim hadir di semua acara: retro, stand-up, plenings. Semua karyawan mutakhir dengan tugas saat ini.
- Tim tidak lagi bekerja pada sprint orang lain. Sekarang semuanya asli.
Apa yang bisa diperbaiki. Saya ingin memperkenalkan BA sepenuhnya dalam tim. Ini bermasalah karena VA biasanya mulai bekerja lebih awal daripada anggota tim lainnya.
Kerja tim
Sebuah tim dalam pekerjaan dapat memiliki tidak lebih dari dua sprint: "yang masih dalam tes" dan "yang baru yang akan kita lihat". Sebagai aturan, setelah akhir pengembangan, semua orang, ketika mereka dibebaskan, mulai bekerja pada sprint baru.
Apa itu plus. Kerja tim menjadi lebih mudah diprediksi, semua orang akrab dengan kode dan dapat mendukung sprint selama pengujian. Peserta cenderung beralih di antara tugas-tugas, dan proses beralih sekarang lebih cepat.
Apa yang bisa diperbaiki. Idealnya, sebuah tim harus hanya memiliki satu sprint dalam pekerjaan. Tetapi untuk saat ini, dunia yang ideal bukanlah dunia kita.
Fireteam
Setiap tim dipilih selama satu minggu. Perintah ini menanggapi semua gangguan eksternal: panggilan dari departemen lain, perilaku abnormal layanan, perbaikan terbaru. Kami menyebut tim ini "Fireteam".
Apa itu plus. Minggu fireteam tidak diperhitungkan tim dalam waktu sprint. Di antara pemadam kebakaran, karyawan dapat fokus pada tugas-tugas mereka:
- Refactor.
- Selesaikan tugas sprint.
- Tulis dokumentasi.
- Melakukan transfer pengetahuan dengan tim lain.
Kerugian. Pada minggu fireteam, kehidupan tim sangat penting. Semua departemen mencintai dan mengenal orang-orang ini secara langsung, terutama dukungan teknis. Anda harus terus-menerus beralih di antara tugas yang berbeda: mendebit, membaca log, menggergaji tugas mendesak dan memadamkan semua kebakaran. Semua ini harus dilakukan secara bersamaan.
Standup
Kami memperkenalkan 2 jenis stand-up:
- Tim Mereka melibatkan tim yang bekerja pada proyek tersebut.
- Jenderal Mereka diadakan seminggu sekali, pemimpin dari setiap tim berpartisipasi di dalamnya.
Apa itu plus.- Tim diberitahu tentang kondisi sprint.
- Karyawan menyadari apa yang dilakukan tim lain.
- Stand-up tidak berubah menjadi "kegiatan membosankan untuk membaca dari selembar kertas beberapa set angka." Semua yang hadir mengerti apa yang dipertaruhkan. Menjadi lebih mudah untuk mendeteksi area masalah di tempat kerja.
- Standup memakan waktu 5-10 menit.
Kerugian. Tim masih membawa informasi ke tim.
Ringkasan
Jadi, secara bertahap mengubah proses, kami memecahkan sebagian besar masalah mendesak:
- Kami telah mengumpulkan tim stabil dari 2-3 pengembang dan QA. Setiap tim sekarang memiliki tidak lebih dari 2 sprint, para peserta tidak mengerjakan proyek orang lain.
- Ada tim yang memproses pesan dari departemen lain, merespons perilaku abnormal layanan dan perbaikan terbaru. Tim lain tidak terganggu oleh tugas-tugas ini.
- Sekarang perusahaan memiliki 2 jenis stand-up: tim dan umum. Semua karyawan diberitahukan tentang keadaan sprint, dan stand-up membutuhkan standar 5-10 menit.
Ya, kami sedang mengerjakannya.
