Subtugas awal di awal setiap sprint

Saya telah bergabung dengan tim baru yang menggunakan Agile / Scrum, dan proses pengembangan mereka adalah sebagai berikut:

1) pengembang meninjau setiap cerita sebelum setiap sprint untuk memastikan tidak ketinggalan sesuatu yang kritis. Ada keadaan formal untuk itu dalam alur kerja.

2) selama kickoff Sprint, seluruh tim melakukan estimasi (perencanaan poker) tentang berapa banyak poin cerita yang akan dikenakan biaya setiap cerita.

3) akhirnya, segera setelah setiap sprint dimulai, masing-masing pengembang diharuskan untuk membagi semua cerita yang ditugaskan ke dalam subtugas dengan perkiraan waktu (sebagai lawan subtugas sebelum memulai setiap cerita).

Argumen utama untuk langkah terakhir adalah membantu untuk mengetahui apakah menerapkan cerita akan memakan waktu lebih lama dari yang diperkirakan dan memperingatkan scrum master tentang risiko potensial dari tenggat waktu sprint yang hilang.

Namun saya menemukan ini kontra-produktif, terutama karena alasan berikut:

• jika tujuannya adalah untuk memberikan perkiraan kasar, poin cerita (langkah # 2) adalah pekerjaannya. Kalau tidak, mengapa repot-repot dengan poin cerita sama sekali? - Cukup lakukan subtugas sejak dini.
• jika tujuannya adalah untuk memberikan perkiraan yang akurat, maka ini adalah contoh yang jelas dari apa yang dijelaskan dalam Human Task Switches Dianggap Berbahaya . Ini, saya pikir, terutama untuk pengembang baru yang bergabung dengan tim yang ada dalam proyek besar di mana memahami apa yang perlu dilakukan dapat memakan waktu hingga 50% dari waktu. Anda diharuskan untuk masuk ke detail cerita # 1, lalu cerita # 2, # 3, dll. Yang menghasilkan banyak informasi churn.

Saya juga diberi tahu bahwa praktik seperti itu "sesuai dengan buku" dan saya bahkan tidak bermaksud membahas hal ini. Adakah yang bisa memberikan referensi untuk praktik seperti itu - apakah ini didefinisikan dengan jelas dalam Alkitab Scrum, dan / atau mungkin memberikan wawasan tambahan?

Ini tidak berbeda dengan cara kami menjalankan beberapa proses scrum kami. Kita

1. Perkirakan cerita di dekat bagian atas tumpukan di "poin cerita"
2. Pilih / jelaskan cerita berdasarkan poin cerita yang menurut kami akan "mengimbangi" sprint
3. Bagi cerita menjadi tugas teknis yang lebih rinci
4. Perkirakan tugas-tugas teknis dan bandingkan dengan perkiraan poin cerita asli (kami tahu kira-kira berapa banyak waktu pengembangan yang biasanya disamakan dengan poin cerita)

Tapi yang ingin Anda ketahui adalah mengapa kami memperkirakan dua kali!

• Kami melakukan perkiraan kasar (berdasarkan cerita) karena kami ingin dapat membuat prediksi tentang apa yang mungkin ada di sprint berikutnya , dan mungkin bahkan setelahnya. Pada akhirnya manajemen harus dapat berkomunikasi dengan pelanggan tentang kemungkinan skala waktu, jadi jika kita tidak memiliki estimasi skala kasar ini maka perencanaan jangka panjang hampir mustahil.
• Jelas, ini berarti kami melakukan perkiraan kasar untuk lebih dari sekedar sprint saat ini. Karena tidak ada jaminan pesanan jaminan simpanan tidak akan berubah untuk sprint berikutnya, kami tidak ingin menginvestasikan waktu dalam melakukan rincian tugas dan perkiraan skala halus hingga diperlukan.
• Kami memecah tugas untuk memastikan bahwa semua tugas telah disebutkan dan bahwa cerita dapat dikerjakan secara paralel dengan lebih mudah.
• Kami melakukan estimasi skala halus (berdasarkan tugas) karena ini memberi kami grafik burn-down yang jauh lebih halus (terutama di mana tidak ada cara mudah untuk memecah cerita besar menjadi "fitur" yang layak).
• Karena kami melakukan keduanya, mereka bertindak sebagai pemeriksaan kewarasan satu sama lain - perbedaan liar menunjukkan kita perlu kesalahan di suatu tempat yang perlu kita identifikasi. Ini adalah produk sampingan yang bermanfaat, tetapi bukan alasan mengapa kami memperkirakan "dua kali".

Membaca ulang pertanyaan dan komentar Anda, saya melihat ada beberapa perbedaan antara alur kerja kami dan Anda.

• Kami melakukan breakdown sebagai sebuah tim , kami menemukan meskipun overhead lebih besar dari diskusi teknis yang kami dapatkan dari ini sering sangat berharga dan dapat mendeteksi kekurangan dalam cerita kami. Ketika kita memiliki perbedaan pengalaman, pengetahuan atau kemampuan diskusi ini juga di mana mereka yang lebih banyak dapat membantu mereka yang kurang (sangat berguna dengan karyawan baru).
• Kami memperkirakan di tingkat tugas sebagai tim , salah satu alasan mengapa "perencanaan poker" bekerja adalah karena fenomena "kearifan orang banyak" - seperti yang saya sebutkan dalam komentar, pada titik ini memperkirakan tugas harus memakan waktu kurang dari 30 detik , sehingga biaya overhead dapat diabaikan.

Kedengarannya seperti alasan tim Anda melakukan perincian tugas dan perkiraan tugas adalah untuk penghancuran yang mulus - yang baik-baik saja, itu semua adalah bagian dari pemantauan kemajuan sprint dan memungkinkan scrum-master Anda untuk mendeteksi dan menyelesaikan masalah lebih awal. Jika Anda menginginkan informasi ini, Anda harus melakukan uraian dan perkiraan dan Anda harus melakukannya terlebih dahulu.

Menurut pendapat saya pengalihan tugas sepertinya tidak menjadi masalah bagi Anda di sini, saya tidak berpikir bahwa memecah tugas yang berbeda adalah benar-benar pengalihan tugas dalam arti yang sama yang beralih dari pengembangan satu fitur ke bagian lain yang dilalui adalah pengalihan tugas . Saya pikir mendapatkan pemahaman tentang "arsitektur" keseluruhan sprint mungkin adalah hal yang cukup berguna.

Namun, saya pikir mungkin ada beberapa masalah lain yang bisa Anda pertimbangkan. Seperti biasa dengan gesit Anda harus mengidentifikasi masalah yang Anda miliki dan mengusulkan solusi , kemudian memutuskan apakah solusi Anda berhasil dalam retrospektif . Ini adalah inti dari membangun solusi gesit yang bekerja untuk perusahaan Anda dan tim Anda. Jadi, beberapa masalah yang mungkin Anda miliki:

• Anda melakukan gangguan secara terpisah - jadi bagaimana pembelajaran tim junior / tidak berpengalaman Anda dari anggota tim senior Anda? Tentu, mereka mungkin dapat mempelajari semuanya sendiri - tetapi mereka akan belajar lebih cepat jika mereka dibimbing. Apakah anggota tim yunior membutuhkan waktu lama untuk memecahkan masalah? Apakah mereka membuat kesalahan atau kehilangan hal-hal yang menghabiskan waktu tim dalam jangka panjang? Terobosan sebagai tim dapat membantu di sini.
• Anda melakukan taksiran satu per satu - hal yang sama berlaku sebagai poin pertama, tetapi selain itu, apakah perkiraan ini kurang akurat daripada yang seharusnya?
• Kedengarannya seperti tugas yang diberikan pada awal sprint, tetapi jika ini masalahnya, seberapa mahal Anda menemukannya ketika Anda harus mengubah tugas? Jika seseorang jatuh atau sakit, seberapa mudah orang lain mengambil tugasnya? Apakah mereka harus melalui pemecahan tugas dan mencoba memahaminya tanpa mengganggu penerima tugas yang asli? Jika Anda menguraikan dan memperkirakan sebagai tim, maka setiap orang harus dapat mengerjakan semuanya!
• Apakah ceritamu terlalu besar? Jika mogok membutuhkan 50% dari waktu, cerita-cerita terdengar seperti mereka sangat terlibat - mungkin mereka dapat dibuat lebih kecil? Kami menyimpan cerita kami dalam 1 minggu kerja.
• Apakah tugas Anda terlalu kecil? Jika Anda menghabiskan banyak waktu untuk membuat daftar tugas, mungkin Anda terlalu detail? Kita cenderung memiliki tugas antara 1 hingga 8 jam kerja sehingga setiap hari setiap orang membuat kemajuan untuk melaporkan pada standup harian berikutnya.

Jika seperti itulah perusahaan Anda ingin menjalankan pengembangan mereka dan menutup diskusi, pilihan Anda terbatas, atau setidaknya Anda berisiko membuat orang marah.

Mengingat bahwa tujuan akhir agile adalah bekerja dengan perangkat lunak yang bernilai, Anda dapat mencoba menawarkan untuk membantu dengan mengukur kemampuan tim Anda untuk memberikan (poin disampaikan / diperkirakan, bug dalam sprint, tidak ada tes, cakupan kode, waktu aktif, penjualan yang dihasilkan - Masa bodo). Bersiaplah untuk semua hasil - mungkin cara kerja ini bekerja untuk mereka bahkan jika itu tidak masuk akal bagi Anda. Jika Anda benar, pemborosan akan menjadi bukti nyata.

Berhati-hatilah dengan mengikuti proses demi proses - ini menghabiskan waktu dan masih menghasilkan produk yang buruk. Eksperimen tim yang gesit, langkah-langkah dan pembelajaran. Cara terbaik untuk mengubah perilaku tanpa turun ke opini adalah dengan keputusan berdasarkan bukti.

Ini juga pendapat saya. Saya sarankan Anda mencoba sendiri dan mengukur hasilnya - lihat apa yang saya lakukan di sana :)

Saya akan berasumsi bahwa Kickoff Sprint Anda berarti pertemuan Perencanaan Sprint. Saya pikir Scrum Master Anda salah menafsirkan bagaimana pertemuan ini seharusnya berjalan. Anda tidak hanya memutuskan cerita apa yang akan dikembangkan, Anda juga mengujinya untuk tim Anda definisi siap untuk memastikan mereka tidak melewatkan apa pun (biasanya menggunakan INVEST ), dan Anda juga membagi cerita-cerita itu ke dalam tugas. Mengutip Mike Cohn (salah satu pendiri Scrum Alliance);

Sprint backlog adalah output lain dari perencanaan sprint. Sprint backlog adalah daftar item backlog produk yang dilakukan oleh tim dan daftar tugas yang diperlukan untuk mengirimkan item backlog produk tersebut. Setiap tugas pada sprint backlog juga biasanya diperkirakan.

Jadi pemecahan cerita dan memperkirakannya adalah bagian dari sesi Perencanaan Sprint; tidak setelah sesi perencanaan selesai dan tidak secara individual.

Untuk memberikan wawasan lebih lanjut, alur kerja kami selama pertemuan Perencanaan Sprint adalah sebagai berikut:

1. kami mengambil cerita dari bagian atas tumpukan produk, dan membaginya menjadi tugas. Sebagai aturan praktis, satu tugas umumnya harus lebih kecil dari satu hari.

2. Kami memperkirakan cerita berdasarkan tugas yang kami deduksi. Jika ceritanya ternyata besar, kami mencoba dan membagi cerita menjadi cerita yang lebih kecil.

3. Bilas dan ulangi sampai kita mencapai total poin yang diperkirakan

Bertentangan dengan apa yang dikatakan Cohn, saya menemukan bahwa tidak ada kebutuhan nyata untuk memperkirakan masing-masing tugas secara terpisah, karena tugas-tugas yang ditetapkan lebih kecil dari satu hari. Mengingat bahwa tugas lebih kecil dari satu hari kerja, Anda dapat dengan mudah melihat selama Standup Harian ketika tugas lebih lama dari yang diharapkan, karena orang yang mengerjakan tugas tertentu akan mengatakan bahwa ia masih mengerjakannya.

Selama sprint tim bekerja melalui cerita-cerita, dan pada akhirnya tim harus merenungkan berapa banyak yang sebenarnya dilakukan. Ini adalah tujuan rapat retrospektif scrum. Jika masih ada cerita di atas meja, Anda dapat menyimpulkan bahwa estimasi Anda terlalu optimis dan menindaklanjutinya untuk sprint berikutnya. Atau mungkin ada insiden tertentu yang terjadi yang mempengaruhi seberapa banyak Anda selesai, dll. Anda akan menemukan bahwa estimasi menjadi lebih baik dari waktu ke waktu ketika Anda merenungkannya.

"oleh buku" - itulah masalah Anda. Anda tenggelam dalam lebih banyak proses daripada yang seharusnya Anda miliki jika Anda bekerja di air terjun.

Tidak ada 'buku' untuk Agile, hanya ada manifesto tangkas yang mengatakan "selesaikan semuanya tanpa semua biaya overhead". Jadi, jika Anda memperkirakan ukuran dan kemudian membagi cerita menjadi tugas untuk memperkirakannya kembali, maka itu adalah proses overhead tanpa tujuan yang perlu dibuat lebih efisien - ini adalah tentang lincah. Scrum dan yang lainnya benar-benar merupakan pedoman titik awal untuk bagaimana Anda mulai gesit. Ketika Anda melakukannya, Anda harus mengidentifikasi poin-poin ini yang tidak masuk akal, atau tidak membantu tim Anda bekerja lebih efektif, dan Anda harus mengubahnya.

Namun, beberapa orang berpikir bahwa cara kerja terlarang harus ditulis dalam batu dan tidak pernah menyimpang, betapapun bodohnya mereka. Saya akan mencoba untuk membagi cerita menjadi tugas-tugas sebelum rapat scrum - Anda mengatakan pengembang diminta untuk meninjau setiap cerita, inilah kesempatan untuk melakukan pemisahan pada saat yang sama sebagai bagian dari tinjauan. Kemudian Anda dapat mendeklarasikan tugas-tugas yang menyusun cerita dalam rapat scrum (jangan mengalokasikan waktu untuk mereka!) Dan biarkan orang-orang kemudian memutuskan seberapa besar paket pekerjaan cerita tersebut, berdasarkan informasi tambahan yang terkandung ini (yang tidak pernah merupakan hal yang buruk, pengambilan keputusan berdasarkan informasi jauh lebih baik daripada menebak, dan hanya dapat dilakukan ketika Anda memiliki informasi untuk dimasukkan ke dalam pengambilan keputusan).

Setelah pertemuan, Anda masih dapat menetapkan waktu untuk tugas-tugas (meskipun saya gagal melihat titik ini, sprint tidak didasarkan pada waktu, mereka didasarkan pada "berapa banyak hal yang Anda harapkan untuk dilakukan" yang diukur dalam poin cerita , bukan waktu. Ini adalah masalah umum dengan scrum, poin tidak berarti waktu tetapi Anda harus menyelesaikan, katakanlah, 20 poin per dua minggu oleh karena itu 2 poin = pekerjaan 1 hari. Ini seharusnya merupakan perkiraan cepat tentang berapa banyak tugas yang harus dilakukan dalam sprint sehingga Anda tidak kelebihan beban atau underworked, bukan berapa banyak yang benar-benar akan dilakukan. Sprint terbaik adalah mereka yang memiliki beberapa tugas tersisa, yang menunjukkan Anda diperkirakan dengan sempurna. Melengkapi setiap tugas menunjukkan orang baik bergegas yang terakhir atau tertunda menyelesaikannya pada akhirnya - tidak ada yang produktif).

Jadi, singkatnya - cetak salinan Agile Manifesto out, dan versi anti-agile . Saya yakin Anda melakukan lebih banyak anti daripada gesit. Scrum cenderung seperti itu. Satu-satunya cara untuk memperbaikinya adalah dengan terlibat dengan tim Anda dan menerima dukungan untuk perubahan. Jangan biarkan manajemen memberi tahu Anda bagaimana tim Anda bekerja, itu juga tidak gesit, dan itu akan ditulis dalam Buku.

Di beberapa titik selama setiap Sprint, Anda harus mengadakan Rapat Penyempurnaan Backlog Produk . Pada pertemuan ini, Anda memastikan bahwa bagian atas dari Product Backlog dirinci cukup untuk item dalam porsi itu akan ditambahkan ke Sprint Backlog berikutnya.

Jika Penyempurnaan Product Backlog dikelola dengan baik, maka Rapat Perencanaan Sprint bisa lebih efisien. Idealnya, ini akan meniadakan perlunya pengembang untuk "dengan bersemangat memecah" cerita setelah Sprint dimulai.

Jika Product Backlog Item ditambahkan ke Sprint Backlog sebelum cukup dipecah untuk memperkirakan secara realistis, itu akan membuat sulit untuk membuat keputusan yang baik tentang apa yang akan ditambahkan ke Sprint.