Agile versi kami tidak berfungsi. Kiat?

Saya bekerja di tim kecil yang terdiri dari 4 pengembang. Kami menerapkan versi Agile yang tampaknya terus-menerus memberi kami kesulitan yang sama, minggu demi minggu, dan saya mencari saran yang dapat membantu kami meningkatkan proses kami.

Latar belakang:

Kami biasanya melakukan sprint 2 minggu, dan setiap sprint kami cenderung meremehkan pekerjaan kami, dan kami mendapat masalah dengan manajer kami karena kami terlambat.

Kami memulai setiap sprint dengan menugasi cerita yang diciptakan manajer kami untuk kami. Terkadang dia melempar tugas juga dan kami memperkirakannya. Kami tidak menggunakan poin cerita. Kami menggunakan perangkat lunak Urban Turtle untuk "mengelola sprint kami", yang pada dasarnya hanya cerita dan tugas, dan yang terkait hangus. Kami tidak berencana untuk rilis di akhir sprint.

Masalah paling umum yang terjadi adalah bahwa kami merencanakan tugas di awal sprint hanya untuk menemukan itu jauh lebih besar dalam cakupan, tetapi prioritasnya masih tinggi, jadi kami perlu bekerja berjam-jam tambahan untuk itu. Masalah kedua yang paling umum adalah salah satu dari kita mengalami masalah teknis yang memperlambat jam yang terbakar, menyebabkan penghalang jalan.

Satu-satunya saran yang diberikan kepada kami adalah untuk lebih proaktif dalam menyesuaikan perkiraan kami dan memberikan pembaruan selama standup di pagi hari sehingga kami dapat menyesuaikan waktu tambahan yang dibutuhkan.

Namun, tampaknya ada sesuatu yang secara fundamental salah dengan cara kita melakukan sesuatu. Mungkin ada keterputusan antara harapan manajer pada tingkat proyek dan harapan pada tingkat sprint. Karena kami membuat iterasi sprint ini sesuai dengan rencana proyek, dan karenanya memperpanjang sprint atau menunda item mengacaukan rencana proyek. Jadi sebagai pengembang, kami didorong untuk melakukan Agile dengan memperluas taksiran bila perlu tetapi juga menyelesaikan sprint tepat waktu, yang membingungkan.

Ini tidak bisa menjadi masalah yang tidak biasa, jadi saya berharap mereka yang lebih bijak daripada saya di luar sana memiliki satu atau dua saran tentang bagaimana kita bisa berhenti mengalami masalah yang sama ini setiap sprint. Ini membuat frustrasi.

karena kita terlambat

Jenis pemikiran ini adalah masalah Anda. Anda tidak ketinggalan jadwal, jadwalnya terlalu ketat. Anda harus mulai memperkirakan cerita dalam poin abstrak sebagai lawan dari jam dan kemudian selama 2-3 iterasi mengetahui kecepatan Anda. Kecepatan Anda adalah berapa banyak poin yang biasanya Anda lakukan setiap iterasi, bukan berapa banyak poin yang ingin diterima manajer Anda.

Setelah ini, tidak masalah jika Anda secara konsisten meremehkan tugas - kecepatan Anda sudah memperhitungkan itu.

Jelas, ini tidak mungkin jika Anda menggunakan jam, bukan poin.

Sepertinya masalahnya adalah ketidakmampuan tim Anda untuk membuat estimasi yang akurat, dan ketidakmampuan untuk melihat masalah yang timbul keniscayaan.

Tugas-tugas kecil jauh lebih mudah untuk diperkirakan secara akurat daripada tugas-tugas besar, jadi cobalah dan pisahkan tugas-tugas Anda menjadi potongan yang jauh lebih kecil.

Jangan izinkan siapa pun membuat perkiraan untuk tugas apa pun, kecuali mereka tahu PERSIS bagaimana mereka akan melakukannya. Untuk setiap tugas yang pengembang tidak tahu harus menyelesaikan apa, luangkan waktu dalam jadwal sprint INI untuk pengembang untuk melakukan beberapa penyelidikan dan desain, dan menghasilkan perkiraan yang akurat. Tidak pernah kurang dari setengah hari. Tapi pindahkan tugas ke sprint BERIKUTNYA. Kemudian, ketika Anda datang ke perencanaan untuk sprint berikutnya, Anda akan memiliki perkiraan yang bagus. Perhatikan bahwa waktu tambahan ini tidak sia-sia, karena sudah saatnya pengembang akhirnya akan menghabiskan dalam hal apa pun.

Dan jangan takut untuk kembali ke manajer proyek dan mengatakan kepadanya bahwa Anda akan membutuhkan lebih banyak sprint untuk melewati daftar tugas. Lebih baik melakukannya daripada berkomitmen pada target yang tidak mungkin.

Apakah Anda mencoba mengalokasikan 100% dari waktu Anda? Jika demikian, berhentilah melakukannya. Mulailah dengan menjumlahkan semua jam yang harus disumbangkan tim Anda selama sprint. Lakukan ini dengan mengasumsikan bahwa setiap pekerja paling tidak akan menempatkan 6 jam sehari ke arah proyek. Ini dianggap sebagai "hari yang ideal". Dua jam lainnya? Terisap oleh rapat, istirahat, tugas administrasi, waktu itu di pagi hari ketika Anda membaca email dan merencanakan hari Anda, dll. Ini bukan "hedging taruhan Anda" atau "karung pasir", itu realistis.

Kedua, kalikan 6 jam / hari dengan 80% . Mengapa? Karena sebagai manusia kita payah dalam memprediksi berapa banyak waktu yang dibutuhkan untuk suatu tugas. Ini menyumbang kesalahan dalam penilaian kami. Sekali lagi, bukan sandbagging, itu realistis.

Sekarang Anda memiliki angka yang mewakili jumlah jam realistis yang Anda harapkan untuk diterapkan langsung pada tugas Anda. Saat Anda memperkirakan, berhentilah menambahkan cerita ketika cerita selanjutnya akan membuat Anda bosan.

Akhirnya, jangan biarkan pemilik produk menambahkan tugas. Perencanaan scrum adalah untuk tim , PO bukan bagian dari tim yang melakukan pekerjaan. Tentu saja, di dunia nyata jika PO lebih berpengetahuan daripada siapa pun di tim, masukannya bisa sangat berguna. Namun, jika tim mengambil panas untuk berada di belakang, tim perlu mengambil kepemilikan tugas apa yang akan mereka lakukan. Tujuan Anda adalah untuk dapat memenuhi kriteria penerimaan; jika suatu tugas tidak mengarah langsung ke sana, jangan lakukan itu.

Ingat, Scrum bukan tentang menjadi lebih produktif. Ini tentang menjadi lebih terbuka dan komunikatif. Pekerjaan akan mengambil apa pun untuk menyelesaikannya. Scrum ada untuk memudahkan memperkirakan, lebih mudah untuk berkomunikasi dengan pemangku kepentingan, dan memudahkan tim Anda untuk membuat komitmen.

Kriteria penerimaan didefinisikan dengan buruk pada awal sprint?

Perkiraan awal seringkali terlalu rendah karena kartu cerita memiliki kriteria penerimaan yang buruk (jika ada) ketika diperkirakan. Bagaimana dengan beralih ke Pengembangan Penerimaan-Didorong-Didorong (ATDD) alias storytesting untuk membantu tim menjadi sangat jelas tentang apa kartu itu?

Cerita terlalu besar?

Alasan lain Anda mengetahui sprint tengah bahwa cerita Anda memakan waktu lebih lama dari yang diharapkan mungkin terlalu besar. Pernahkah Anda melihat Agile di dek kartu flash? Mereka memiliki kartu flash yang disebut "Kecilkan XL cerita agar Sesuai". Ini memberikan strategi untuk membagi cerita seperti menunda kasus tepi, efek samping, aspek nonfungsional, atau penanganan kesalahan untuk cerita selanjutnya.

Tidak dapat memperkirakan karena Anda tidak memiliki informasi yang cukup?

@sleske membuat saran yang bagus tentang paku . Coba dan kenali tidak diketahui teknis pada waktu perkiraan. Jika ada, lihat apakah Anda bisa menundukkan cerita ke dalam sprint kemudian dan bukannya melakukan investigasi kotak waktu (spike) sprint ini untuk mencoba dan mempelajari apa yang diperlukan untuk dapat memperkirakan. Jangan terbawa suasana dan selesaikan kisah aslinya - lonjakan dilakukan ketika Anda cukup tahu untuk memperkirakan cerita.

Gagal lebih cepat

Dan saya setuju dengan @ Patrick Hughes - pertimbangkan untuk pindah ke sprint 1 minggu sehingga Anda dapat melihat masalah lebih cepat.

Selain saran bagus dari @Kevin dan @Patrick ...

Pendekatan tangkas bukan "satu ukuran cocok untuk semua" tetapi komentar ini menarik perhatian saya:

Kami menerapkan versi Agile yang tampaknya terus memberi kami kesulitan yang sama

Anda lebih baik memulai dengan metodologi "menurut buku" (Scrum tampaknya dominan akhir-akhir ini) - dan lakukan persis seperti yang dilakukan oleh beberapa tim sukses lainnya ... Lakukan itu untuk beberapa sprint ... Dan baru mulai pertimbangkan diperlukan perubahan untuk mengoptimalkan kondisi lokal.

Menyewa pelatih Scrum yang berpengalaman (untuk beberapa iterasi) mungkin merupakan pembuat perbedaan yang nyata. Ada kehalusan dalam mendapatkan tangkas yang benar.

Pertama-tama saya merekomendasikan buku scrum-xp-from-the-parit berikut . Lihat halaman 26 poin tentang perhitungan Velocity. Idenya adalah untuk mendefinisikan faktor fokus, dan mengatakan itu untuk Sprint berikutnya:

man-days yang tersedia * faktor fokus = perkiraan kecepatan

Perkiraan kecepatan adalah jumlah perkiraan cerita yang Anda rencanakan untuk implementasikan selama Sprint berikutnya.

Dan setelah satu Sprint Anda menghitung faktor fokus Sprint yang terakhir sebagai:

faktor fokus = kecepatan aktual / hari kerja yang tersedia

di mana kecepatan aktual adalah jumlah perkiraan cerita yang telah Anda implementasikan selama sprint.

Kemudian Anda menggunakan kembali faktor fokus aktual ini untuk Sprint berikutnya, dan setelah beberapa Sprint Anda akan dapat lebih tepat dengan seberapa banyak yang dapat Anda capai selama Sprint ...

Sampai Anda mendapatkan estimasi untuk mempersingkat sprint Anda menjadi satu minggu, dengan cara ini Anda akan mengenali kelebihan penggunaan lebih cepat dan dapat bereaksi dengan kenaikan yang lebih kecil.

Luangkan lebih banyak waktu di depan saat merancang tugas untuk mendapatkan ruang bernafas untuk mengenali efek samping yang mungkin menjadi penyebab pendarahan di seluruh area. Bisa juga bahwa tugas itu sendiri terlalu lama untuk estimasi tangkas yang tepat, lihat apakah tugas dapat dipecah menjadi langkah-langkah yang lebih pendek yang akan lebih mudah untuk ditelan.

Buat semua orang merasa nyaman dengan mengirimkan bendera merah segera setelah mereka mengenai hambatan daripada terjebak pada masalah selama beberapa jam. Coba dan lepaskan ego dan kesalahan dari proses ini, itu lebih mudah untuk beberapa orang daripada yang lain =)

Dan seperti @Kevin yang dibesarkan, Anda tidak pernah benar-benar menjadwalkan 100% langsung ke tugas karena selalu ada overhead seperti rapat dan seterusnya sehingga Anda mungkin tidak dikenal sebagai pemakan waktu.

Ketika semuanya keren di bagian penjadwalan lalu kembali ke dua minggu, secara ajaib Anda akan mengambil sedikit waktu dari lebih sedikit rapat lagi.