Halo semuanya, nama saya Alexei Fedorov, saya pemimpin tim tim keuangan di Citimobil. Dalam artikel ini saya ingin berbagi bagaimana proses pengembangan tangkas dalam tim kami bekerja.
CityMobil adalah agregator taksi terbesar kedua di Rusia. Sepanjang tahun, kami telah tumbuh sekitar 10 kali dan tidak akan melambat. Pertumbuhan yang cepat seperti itu memberlakukan beberapa batasan: kita membutuhkan time-to-market (TTM) yang sangat singkat, waktu dari ide hingga penggunaannya oleh pelanggan nyata harus sekecil mungkin. Karena kami meminimalkan TTM, kami tidak mengumpulkan rilis, tetapi memutar setiap tugas / fitur secara terpisah. Juga, pendekatan ini memiliki nilai tambah yang penting - jika ada masalah dalam masalah ini, segera jelas mengapa mereka muncul. Ini memungkinkan Anda untuk memutar kembali tugas, bukan seluruh rilis.
Kenapa tidak Scrum
Selama beberapa tahun sekarang, metodologi Agile dan varietas Scrumnya (selanjutnya disebut Scrum) telah populer di industri TI. Scrum berusaha menerapkannya di setiap perusahaan. Dan masing-masing memiliki pengalaman implementasi sendiri, tetapi, sebagai aturan, jarang positif. Lebih sering muncul kekecewaan dan kemunduran untuk proses sebelumnya.
Menurut pendapat saya, masalah utama scrum adalah:
- Memperbaiki sprint.
Jarang sekali ternyata untuk menutup sprint tepat waktu sehingga semuanya dilakukan. Sebagai aturan, masih ada beberapa hal sepele yang tidak diperbaiki atau tidak diverifikasi. Perbaikan ditransfer ke sprint lain, dan agar tepat waktu, tim mengambil lebih sedikit tugas. Menyeimbangkan sprint untuk tugas sehingga setiap orang memiliki pekerjaan itu sulit. Tugas RnD umumnya tidak cocok dengan kerangka kerja tetap. Dan yang paling penting, sprint tetap jarang diminta oleh bisnis itu sendiri. - Berbagai aksi unjuk rasa.
Scrum memiliki banyak kegiatan: demonstrasi harian, perencanaan, dan retrospektif untuk setiap sprint. Seringkali pertemuan-pertemuan ini diadakan untuk pertunjukan dan lebih melelahkan daripada bermanfaat.
Secara umum, scrum mengingatkan saya pada kultus kargo tertentu, yang diperkenalkan sebagaimana adanya dengan harapan akan menjadi baik. Pendekatan kami adalah menggunakan teknik dan proses yang membantu mencapai hasil, dan mengabaikan apa yang mengganggu.
Tim
Peran kunci dalam pembentukan proses dimainkan oleh tim dan strukturnya. Tim kami mencakup pengembang dan pemimpin tim. PM, QA, analis, desainer opsional. Tim harus dianggap sebagai unit tempur tunggal. Ini adalah kotak abu-abu, di pintu masuk yang ada persyaratan, dan pada keluaran - produk. Organisasi internal sepenuhnya berada di tangan tim, dan di dalam dirinya sendiri, ia dapat bekerja pada proses apa pun yang cocok untuknya.
Seperti halnya kita
Tim kami memilih proses yang sangat mirip dengan Kanban. Kami memiliki banyak sumber tugas: ditemukan oleh layanan dukungan bug, fitur baru dari produk, utang teknis, fitur tim yang berdekatan, dll. Tidak masalah dari mana tugas itu berasal, itu harus dibingkai dalam pelacak tugas, lebih disukai oleh penulis sendiri. Setiap tugas masuk melewati beberapa status wajib: "Baru", "Untuk bekerja", "Sedang berlangsung", "Diuji", "Siap untuk ditempatkan".
Tugas bergerak dari kiri ke kanan di papan tulis, jarang kembali. Prioritas meluas dari atas ke bawah dan dari kanan ke kiri. Misalnya, menjalankan tugas dalam produksi lebih penting daripada pengujian, dan pengujian lebih penting daripada pengembangan baru. Kolom “Berfungsi” pada dasarnya membentuk simpanan tim - daftar tugas linear yang diprioritaskan selama beberapa minggu sebelumnya. Segera setelah pengembang memahami tugasnya saat ini, ia mengambil kolom berikutnya dari atas.
Tugas tidak diperbaiki sebelumnya untuk pengembang tertentu, pendekatan ini memungkinkan menyeimbangkan pelaksanaan tugas, meningkatkan pengetahuan umum tentang kode oleh semua pengembang, meningkatkan faktor bus. Kami mencoba menangani spesialisasi sempit di dalam tim. Setiap anggota tim harus dapat melakukan tugas apa pun dari simpanan. Jika pengembang mengambil tugas untuk dirinya sendiri, maka ia sepenuhnya mengontrol gerakannya di papan sampai muncul di prod. Dia juga memeriksa bagaimana tugasnya dalam kondisi nyata.
Dari pertemuan yang kami lakukan setiap hari, di rapat umum ini kami tidak hanya membahas rencana, masalah, dan tugas yang diselesaikan, tetapi juga pendekatan untuk menyelesaikan masalah, proposal, dan secara umum segala sesuatu yang membuat anggota tim khawatir. Pertemuan jarang memakan waktu lebih dari 30 menit untuk 4 orang. Setiap bulan kami melakukan retrospektif pada sampel scram: apa yang baik / buruk, apa yang dapat kami lakukan dengannya, rencana untuk meningkatkan efisiensi untuk bulan berikutnya. Kami tidak memiliki perencanaan khusus, kami mengatur perencanaan jika perlu, jika kami mulai mengembangkan tugas besar.
Kami mencoba mencatat waktu untuk setiap tugas, setidaknya 75% dari waktu kerja. Dengan ini kami mencapai dua tujuan:
- Kami mencari dan menghilangkan pembunuh waktu: tugas yang menghabiskan waktu, tetapi tidak membawa manfaat yang diharapkan.
- Kami mengevaluasi tugas berdasarkan yang sudah dilakukan, sehingga meningkatkan akurasi penilaian.
Kami juga memiliki shift mingguan: salah satu pengembang menjawab pertanyaan dari baris dukungan kedua, mencari masalah baru di log / pemantauan, menyelesaikan tugas-tugas mendesak dan melakukan sesuatu yang tidak sesuai dengan jaminan simpanan yang direncanakan. Hal ini memungkinkan pengembang lain untuk lebih berkonsentrasi pada tugas mereka tanpa terganggu oleh pengirim pesan, dll.
Ringkasan
Proses yang dijelaskan dengan sedikit variasi saya terapkan di beberapa tim dan perusahaan. Dia membuktikan dirinya sebagai yang paling fleksibel dan transparan untuk semua orang.
Kami tidak berpuas diri, dengan setiap retrospektif baru kami membuat proses kerja kami lebih baik dan lebih efisien. Setiap kali kami meninjau praktik yang digunakan. Kami tidak memiliki "sapi suci" - apa yang berhasil sebelumnya mungkin berhenti bekerja, dan banyak ide bagus secara teori tidak menunjukkan diri mereka dalam praktik dengan cara terbaik. Kami menjatuhkan mereka tanpa penyesalan.
Proses peningkatan berkelanjutan adalah fondasi tim kami.