Scrum untuk tim spesialis


11

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?


Suka atau tidak, Jika Anda menghapus semua scrum, Anda tidak lagi melakukan scrum. Dan BTW - scrum harian harus lebih dari 5 m dari 15m.
Jamiec

Ya, SO punya tag scrum, jadi saya pikir saya bisa mengajukan pertanyaan terkait scrum ^^. Juga, semua referensi yang saya gunakan menggunakan scrum harian 15 menit, bukan 5.
Korchkidu

Ya saya curiga scrum, tag agile pre-date programer.se - tapi tentu saja sekarang ini tempat yang lebih baik untuk mengajukan pertanyaan seperti itu.
Jamiec

Ok terima kasih. Bisakah Anda memigrasi pertanyaan ini ke programmer.se atau haruskah saya menghapus yang ini dan memulai yang baru di sana?
Korchkidu

'Takut aku tidak punya kekuatan untuk memindahkan ini. Maaf.
Jamiec

Jawaban:


7

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:


Sangat membantu! Saya akan memeriksa Lean dan Kanban! Bagaimana kita +2 di SE? ..;)
Korchkidu

2

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.


Saya sangat setuju bahwa komunikasi harus tetap terjadi. Namun, rapat perencanaan sprint hanyalah tentang mengevaluasi poin cerita. Jika satu orang per cerita dapat memperkirakan nilainya, maka pertemuan ini tidak berguna ... Dan saya percaya bahwa mekanisme di Scrum (tidak gesit pada umumnya) memang penting.
Korchkidu

1

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.


"Jadi saya kira mereka harus berkomunikasi lebih banyak seperti dalam tim generalis": inilah sebenarnya poin saya. Itu sebabnya saya percaya bahwa rapat scrum harian tidak cukup dan harus diganti dengan pertemuan mingguan. Atau, rapat scrum harian berlangsung selama 30 menit.
Korchkidu

@ Korchkidu: Tidak - rapat scrum harian bukan pertemuan teknis, tetapi laporan kemajuan. Anda menghabiskan 15 detik dalam rapat untuk menjadwalkan rapat 15 menit di kemudian hari. Sebagai master scrum, Anda bertanggung jawab untuk menjaga agar standup tetap fokus.
MSalters

Ya memang. Jadi 15 'standup + 15' rapat teknis opsional bisa memungkinkan. Terima kasih!
Korchkidu

1

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.


1
Meskipun jawaban Anda terperinci dan menjelaskan alasan antara blok bangunan Scrum dengan baik, saya tidak melihat di mana Anda membalas inti dari pertanyaan, menggambarkan situasi spesialis, dan ketakutan (mungkin tanpa sebab) dari OP yang Scrum menangkan bisa bekerja dengan baik untuk tim seperti itu.
Doc Brown

Adil. Upaya saya adalah menangani setiap item yang menjadi perhatian secara langsung. Kesimpulan saya tentu saja buruk. Hargai responsnya.
Ryan Cromwell
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.