Scrum untuk tim spesialis

Scrum terbaik untuk tim dengan anggota generalis, yaitu tim di mana 2 orang setidaknya dapat melakukan tugas yang sama. Perhatian utama saya adalah menemukan solusi yang baik untuk beradaptasi scrum (apa yang harus disimpan, apa yang harus dihapus, apa yang harus ditingkatkan) untuk tim yang terbuat dari spesialis?

Misalkan Anda memiliki tim 5 pengembang (tidak nyata, hanya sebagai contoh):

1. Seorang ahli matematika dengan keterampilan yang kuat dalam C;
2. Satu pengembang DB;
3. Satu Pengembang Web;
4. Satu pengembang UX / GUI;
5. Satu arsitek perangkat lunak;

Di sini, semua adalah spesialis dan tidak ada yang bisa menggantikan orang lain (saya tidak peduli dengan risiko membangun tim seperti itu, saya ingin fokus pada scrum). Jadi, dalam konteks scrum, berikut adalah pikiran saya:

1. Perencanaan musim semi yang tidak berguna: memang, ketika ahli matematika mengatakan bahwa tugas tertentu bernilai 2 poin, tidak ada yang dapat memberikan suara menentangnya;
2. Metrik kecepatan tim yang tidak berguna: karena setiap orang dapat mengalokasikan sejumlah poin untuk tugasnya sendiri, menghitung kecepatan tidak masuk akal;
3. Ganti rapat scrum harian dengan rapat scrum mingguan (lebih lama): karena setiap anggota tim mengerjakan tugasnya sendiri, rapat scrum harian harus benar-benar penting untuk menjaga "semangat tim". Namun, rapat scrum harian seharusnya berlangsung sekitar 15 menit. Ini jelas tidak cukup untuk memahami apa yang orang lain lakukan dan akan lakukan. Selain itu, ahli matematika sebagian besar waktu akan menjawab hal yang sama: "Saya masih melakukan % & Lo (+? $$ + &)" ... Rapat mingguan akan memberi lebih banyak waktu. Untuk menjaga waktu rapat yang sama antara rapat scrum "awal" dan rapat scrum "mingguan", setiap rapat scrum mingguan harus berlangsung (5 hari seminggu, dengan sprint 4 minggu, dengan rapat sprint yang berlangsung 4 jam dan pertemuan harian yang berlangsung 15 menit): (4 * 60 + 20 * 15) / 4 =>

Atau apakah scrum masih dapat digunakan? Mungkin teknik gesit lain harus digunakan?

Scrum bukan peluru perak. Tidak setiap proyek harus menggunakan Scrum untuk berhasil. Namun situasi yang Anda gambarkan sepertinya sangat cocok untuk Lean / Kanban. Anda mungkin ingin memeriksanya.

Kanban pada dasarnya meminta Anda untuk melakukan hanya beberapa hal, tidak ada yang bertentangan dengan jenis tim yang Anda gambarkan:

• Visualisasikan aliran nilai, yaitu papan Kanban. Papan Scrum adalah aplikasi spesifik papan Kanban; Dimungkinkan untuk menyesuaikannya untuk memungkinkan spesialisasi.
• Batasi Work In Progress (WIP), sehingga jumlah pekerjaan yang diberikan kepada tim cukup untuk membuat pekerjaan terus mengalir - yaitu tidak ada "penyumbatan" baik pada awal aliran (desain) atau akhir (penyebaran) .

Anda mungkin ingin memeriksa beberapa referensi tentang Kanban:

• Suatu hari di Tanah Kanban
• Priming Kanban (EBook gratis)

Anda terlalu fokus pada mekanisme scrum / agile tanpa melihat apa yang seharusnya agile berikan. Anda mengatakan bahwa jika orang matematika memperkirakan 2 poin tidak ada yang bisa mengatakan dia salah. Ini bukan tujuannya. Tujuannya adalah untuk menyetujui serangkaian tujuan yang dapat dicapai untuk sprint yang akan datang. Sebagai ahli dalam tugas itu, dia akan tahu berapa lama waktu yang dibutuhkan.

"Jadi bagaimana kalau dia berbohong atau salah?" kamu bilang. Dalam pengalaman saya, orang-orang di bawah perkiraan lebih banyak karena mereka takut akan ditembak karena memberikan tebakan yang akurat. Lainnya di bawah perkiraan kemudian menambahkan margin keamanan yang menyeimbangkan semuanya dan orang malas yang aneh akan lebih dari perkiraan sehingga mereka tidak perlu terburu-buru. Dari tiga yang pertama akan diambil pada pelacakan kecepatan, yang kedua saat terdengar salah, bekerja dan yang ketiga adalah sesuatu yang Anda harus berurusan dengan di luar scrum.

Pertemuan harian masih memberikan manfaat. Ada ketergantungan antara anggota tim bahkan jika mereka masing-masing spesialis. Orang UI mungkin sedang menunggu orang server untuk memperbaiki bug pemberitahuan. Pria server mungkin menunggu pria matematika untuk mencari tahu mengapa perhitungannya salah. Ini juga bukan hanya tentang bagaimana pekerjaan mereka memengaruhi Anda. Jika seorang anggota tim terus-menerus ditunda karena "Alasan X" tetapi mereka belum meluangkan waktu untuk mengurangi kejadian "Alasan X" di masa depan, itu dapat ditantang.

Jika Anda memiliki spesialis dengan kualifikasi seperti yang Anda jelaskan, asumsi Anda bahwa masing-masing bekerja pada tugasnya sendiri, dengan jarang perlu berkomunikasi dengan yang lain, adalah IMHO salah. Bahkan, untuk mewujudkan fitur baru ("kisah pengguna"), Anda seringkali harus melakukannya

• ubah database Anda
• menambah atau mengubah GUI atau antarmuka Web
• menggabungkan ini dengan logika bisnis yang benar (di mana, mungkin, Anda "ahli matematika" datang)
• pastikan bahwa semua perubahan itu bekerja sama dengan baik

Jadi saya kira mereka harus berkomunikasi lebih banyak seperti dalam tim generalis, di mana setiap orang dapat bekerja pada aplikasi / kisah pengguna yang berbeda, membuat semua perubahan yang diperlukan untuk semua lapisan aplikasi sendiri. Dengan demikian, semua aktivitas tim dari Scrum yang Anda sebutkan di atas sangat masuk akal untuk tim seperti itu.

Scrum tentu masih sesuai untuk situasi Anda, tetapi demikian juga kerangka kerja lainnya.

Untuk menghadirkan fitur-fitur baru, Anda mungkin memerlukan semua atau banyak keterampilan ini. Agar tim dapat membuat keputusan yang berdampak satu sama lain dan bekerja bersama mereka harus berkomunikasi. Semakin lama waktu di antara rapat Scrum, semakin lama rencana negatif dapat menyimpang dari tim. Dengan bertemu setiap hari, tim dapat mengatasi situasi ini dengan cepat dan membuat rencana baru.

Saya ingin membahas beberapa topik spesifik yang Anda kemukakan juga:

Tim Lintas Fungsional Suatu tim akan dianggap lintas fungsional jika tim memiliki semua keterampilan yang diperlukan untuk mencapai tujuan sprint dan / atau item jaminan produk. Ini tidak berarti bahwa ada 2 orang untuk setiap pekerjaan.

Ukuran Penting untuk diingat bahwa kita mengukur masalah atau kebutuhan bisnis, bukan solusi atau bagian dari solusi. Misalnya, Mengintegrasikan media sosial / Twitter ke situs e-commerce kami adalah masalah yang membutuhkan UX, Desain UI, Pemrograman, Basis Data, dan pengetahuan tentang API Twitter. Sebuah tim harus mengukur itu sebagai sebuah unit karena mereka, sebagai sebuah tim, akan memberikan fungsi ini. Ukuran ini tidak akan 100% akurat, tetapi kami menemukan bahwa, secara agregat, perkiraan berdasarkan ukuran relatif lebih akurat. Ini berarti bahwa beberapa akan tinggi, beberapa akan rendah dan secara bersama-sama ramalan yang dihitung lebih akurat daripada perkiraan durasi.

Perencanaan musim semi yang tidak berguna Perencanaan Sprint adalah waktu untuk berkolaborasi sebagai Tim Scrum (Tim Pengembangan + Pemilik Produk + Master Scrum) dalam menentukan apa yang harus diproduksi dan membuat rencana untuk memulai. Beberapa tim akan memecah Item Product Backlog ini dipilih menjadi tugas sementara yang lain akan datang dengan cara mereka sendiri untuk maju, seperti tes yang harus lulus (pikirkan XP).

Ini adalah kolaborasi dua arah. Menugaskan tim satu set PBI dan mengatakan "pergi" adalah peran seorang diktator. Tim sedang bernegosiasi dengan Pemilik Produk untuk memaksimalkan waktu dalam sprint.

Metrik Kecepatan Tim yang Tidak Berguna Dengan tim yang mengukur masalah dan kebutuhan bisnis yang menembus arsitektur / sistem dan pengalaman masa lalu yang memberi tahu kami berapa banyak dari tim yang telah dikirim dalam kotak waktu (sprint) yang konsisten, kami sekarang dapat memberikan perkiraan tim untuk sisa dari simpanan.

Sekali lagi, tidak ada dua sprint yang akan sama dan semakin kecil set sampel item Product Backlog yang Anda gunakan, semakin sedikit kesalahan penyebaran dalam estimasi. Anggap saja seperti pasar saham; itu selalu naik, tetapi itu tidak berarti kita tidak memiliki tahun. Secara agregat Anda dapat menghasilkan uang, tetapi pada bulan, kuartal, tahun apa saja Anda akan menebak salah.

Ganti rapat scrum harian dengan rapat scrum mingguan (lebih lama) The Scrum Harian hadir untuk menyediakan bagi tim siklus umpan balik 24 jam dan peluang untuk merencanakan 24 jam ke depan. Tidak lebih, tidak kurang. "Tiga Pertanyaan" dimaksudkan untuk membantu memfasilitasi upaya itu.

Jika Anda tidak memiliki umpan balik selama 5 hari, saya yakin tugas Anda tidak cukup baik. Ini hanya pendapat saya, tetapi didasarkan pada pengalaman saya sebagai pelatih dan anggota tim. Tim harus berbicara, merencanakan, dan mengintegrasikan upaya mereka JAUH lebih sering.

Kesimpulan Scrum dimaksudkan untuk memfasilitasi pembelajaran dan menyeimbangkan pembelajaran dengan penyampaian (di mana pembelajaran yang sebenarnya terjadi). Percobaan dengan proses dan alat Anda dari waktu ke waktu dan gunakan Scrum untuk memeriksa dampaknya. Coba pindah dari Scrum harian ke mingguan dan lihat apakah itu membantu atau melukai kemampuan tim untuk memberikan fungsionalitas yang tepat. Itu mungkin bekerja untuk Anda.