Bagaimana kami memberikan perkiraan waktu yang valid selama Perencanaan Sprint tanpa melakukan desain "terlalu banyak"?

9

Tim saya semakin cepat dengan Scrum, tetapi kebanyakan dari kita lebih akrab dengan metodologi tangkas "pseudo-". Bagian yang merupakan rintangan terbesar bagi kami adalah menjalankan rapat Perencanaan Sprint yang efisien di mana kami memecah barang-barang jaminan kami menjadi tugas, dan memperkirakan jam. (Saya menggunakan terminologi dari Template Scrum VS2010; permintaan maaf jika saya menggunakan kata yang salah di suatu tempat.)

Ketika kita mencoba untuk mencari tahu berapa lama tugas akan diambil, kita sering jatuh ke dalam perangkap merancang fitur di tingkat kode - tata letak tabel, antarmuka, dll - untuk mencari tahu berapa lama itu akan mengambil .

Saya cukup yakin ini bukan tempat yang tepat untuk melakukan desain semacam itu. Kita harus menjadwalkan tugas untuk rapat desain ini selama sprint. Namun, kami mengalami kesulitan mencari tahu bagaimana cara menghasilkan estimasi yang berarti untuk tugas-tugas tersebut.

Apakah ada kebiasaan / teknik / dll. untuk membuat panggilan penilaian tentang berapa lama fitur akan berlangsung, tanpa mengetahui bagaimana Anda berencana untuk mengimplementasikannya? Jika perkiraan waktu kami akan berubah secara signifikan setelah desain selesai, bagaimana kami dapat menganggarkan dengan benar backlog Sprint kami sebelumnya?

EDIT:

Hanya untuk memperjelas, karena beberapa komentar / jawaban sangat valid tapi saya pikir menjawab pertanyaan yang salah.

Kita tahu bahwa apa yang kita lakukan tidak benar, dan kita harus membangun waktu dalam sprint untuk desain ini. Secara konseptual semua pengembang memahami hal itu. Kami juga membawa anggota tim dengan pengalaman Scrum untuk menjaga kami tetap di jalur jika kami mulai memasuki rumput liar.

Masalahnya adalah bahwa, tanpa melalui proses desain ini, kami merasa sulit untuk memberikan perkiraan waktu yang konkret untuk apa pun. Kami terus-menerus mengatakan hal-hal seperti "baik jika kami mendesainnya dengan cara ini mungkin butuh 8 jam, tetapi jika kami akhirnya harus melakukan ini dengan cara lain, itu akan memakan waktu sekitar 32 tetapi mungkin tidak seburuk setelah kami mulai mencoba menulisnya ... "

Saya juga berasumsi bahwa proses ini akan menjadi lebih baik setelah kita memiliki kecepatan historis untuk bekerja, tetapi banyak teknologi dan pola arsitektur yang kita gunakan adalah hal baru bagi kita. Tetapi jika perkiraan yang berpotensi sangat liar hanyalah bagian alami dari mengadaptasi proses ini maka kita hanya perlu merekondisi diri kita sendiri untuk menerimanya :)

KutuluMike
sumber
Apa yang Anda maksud dengan "pantas?"
Robert Harvey
Maksud saya, saya tidak berpikir tim seharusnya menghabiskan 25-30 menit pada desain teknis fitur selama perencanaan sprint, tapi itu hanya perasaan saya (bahwa itu membuat rapat perencanaan kami berjalan jauh.)
KutuluMike
Kamu benar Michael. Saya baru saja memikirkan sesuatu yang lain yang akan saya tambahkan ke jawaban saya di bawah ini. Pada dasarnya, jika Anda merencanakan sprint tanpa sponsor bisnis di sana, maka Anda tidak tahu apa yang harus diprioritaskan. Lebih jauh di bawah.
Ian
1
Anda punya dua pilihan. Anda dapat memperpanjang panjang fase desain sehingga Anda bisa mendapatkan perkiraan yang memadai, atau Anda dapat hidup dalam batasan waktu yang ditentukan sendiri dan menerima tebakan liar. Anda juga dapat menambahkan sprint untuk desain (yang harus Anda lakukan juga), dan mengubah estimasi pekerjaan Anda ketika fase desain selesai.
Robert Harvey
Saya kira bagian "ubah perkiraan pekerjaan Anda" adalah apa yang merupakan perjuangan bagi kami; beberapa anggota tim lebih ngotot daripada yang lain sehingga kami tidak memberikan perkiraan jam jika kami tidak tahu itu benar. Saya juga berharap dan berharap kita akan menjadi lebih baik dari waktu ke waktu tetapi yang jelas, "semua orang" berhasil melakukan ini dengan baik jadi saya merasa ada sesuatu yang jelas bahwa saya hilang.
KutuluMike

Jawaban:

14
  1. Jadwalkan pertemuan "perawatan" berulang di mana Anda memiliki diskusi desain ini. Tim yang saya ikuti memiliki mereka sekali per sprint, pada hari sebelum perencanaan. Tujuannya adalah untuk memiliki desain yang cukup jauh sehingga tim dapat menyepakati perkiraan waktu untuk keseluruhan cerita. Anda dapat mempertimbangkan untuk melakukan pemecahan tugas dalam rapat ini, sehingga perencanaan menjadi murni latihan dalam memutuskan berapa banyak yang akan diambil. Dengan kata lain Anda harus melakukan desain dalam sprint SEBELUM Anda mulai melakukan pekerjaan yang sebenarnya.

  2. Pertimbangkan untuk menggunakan poker perencanaan , yaitu poin / unit "upaya" daripada hari kerja untuk memperkirakan tugas. Coba juga untuk memecah cerita sebanyak yang Anda bisa. Semakin lama / semakin kompleks suatu cerita, semakin kecil kemungkinan perkiraan Anda akan akurat.

  3. Dalam perencanaan, scrum master harus menjaga perencanaan tetap pada jalurnya dengan menghentikan semua diskusi yang terlalu jauh ke "penyelesaian". Pada saat itu anggota tim diharuskan untuk segera mencapai kesepakatan mengenai estimasi, biasanya memberikan angka batas atas / kasus terburuk. Jauh lebih mudah untuk mengambil lebih banyak pekerjaan jika tugas-tugas berakhir lebih mudah daripada yang Anda rencanakan, daripada berurusan dengan jadwal yang tergelincir karena tugas-tugas yang lebih lama dari yang direncanakan dan cerita-cerita bergulir menjadi beberapa sprint.

  4. Bicara tentang bagaimana perkiraan tersebut muncul dalam retrospektif di akhir sprint. Terutama jika ada yang sangat jauh. Apakah tim belajar sesuatu dari bagaimana cerita berjalan versus bagaimana mereka mengharapkannya? Scrum master harus tetap fokus pada perubahan yang dapat ditindaklanjuti yang dapat dilakukan untuk proses desain / estimasi Anda.

mongiesama
sumber
Saya menandai ini sebagai jawaban karena sepertinya itu sampai ke akar masalah kita: kita perlu melakukan lebih banyak pekerjaan di muka sebelum rapat perencanaan sehingga kita memahami barang-barang jaminan dan tugas-tugas yang terlibat lebih baik begitu kita sampai di sana.
KutuluMike
10

Saya pikir masalahnya adalah Anda mencoba memperkirakan waktu. Jangan.

Perkirakan kerumitan. Lihatlah persyaratan, (semoga cerita pengguna) dan nilai seberapa rumit tim berpikir akan mencari cara membangun dan mengujinya, relatif terhadap seberapa rumit persyaratan lain atau cerita pengguna. Terkadang Anda salah, tetapi sering kali Anda akan mendapatkan gagasan yang bagus tentang seberapa sulit sesuatu akan terjadi. Anda juga akan menemukan bahwa item dengan kompleksitas yang hampir sama cenderung membutuhkan upaya yang sama untuk menyelesaikannya.

Jadi, peringkat kompleksitas menjadi "poin cerita" yang terkait dengan cerita pengguna di jaminan produk Anda. Setelah Anda mengerjakan beberapa sprint, Anda akan mendapatkan gagasan tentang berapa banyak poin cerita yang bisa Anda lewati dalam sprint, dan itu adalah kecepatan Anda. Pada saat itu, Anda akan memiliki gagasan yang lebih baik tentang berapa lama setiap item akan memakan waktu.

Saya sangat merekomendasikan Cerita Pengguna Mike Cohn Diterapkan .

Matthew Flynn
sumber
Itu masuk akal, tetapi kami mencoba mengikuti VS2010 Scrum Template, berdasarkan teori bahwa banyak orang pintar yang tahu apa yang mereka lakukan. Jika kami tidak memperkirakan jam, bagaimana kami melacak hal-hal seperti tetap mengerjakan tugas atau menghasilkan grafik burndown?
KutuluMike
Anda tidak melacak sisa pekerjaan pada tugas. Entah itu dilakukan atau tidak. Pada awal sprint, tim berkomitmen untuk menyelesaikan sejumlah cerita, berdasarkan prioritas mereka, seberapa kompleksnya mereka, dan tebakan terbaik tim tentang seberapa banyak kerumitan yang bisa mereka tangani. Dalam pertemuan Perencanaan Sprint, mereka harus memutuskan tugas apa yang diperlukan untuk menyelesaikan cerita. Tugas-tugas ini membentuk backlog sprint - Anda bisa mengatakan mereka masing-masing 1 poin untuk sprint. Ketika masing-masing selesai, mereka dapat diperiksa setelah selesai.
Matthew Flynn
Tidak perlu ada hubungan apa pun antara poin kompleksitas dalam jaminan Produk dan poin tugas dalam jaminan Sprint. Anda memperbarui sprint backlog setiap hari, memeriksa tugas. Anda memperbarui jaminan produk di akhir sprint, ketika Anda telah menunjukkan bahwa cerita lengkap telah selesai.
Matthew Flynn
Hrm, maka kita benar-benar melakukan kesalahan. Saya tahu ada lebih dari satu cara untuk melakukan Scrum tetapi ini adalah panduan yang kami gunakan, yang mengatakan untuk melacak sisa pekerjaan pada tugas: msdn.microsoft.com/en-us/library/ff731574.aspx . Apakah itu tidak benar?
KutuluMike
3
Ahhhhh. Saya melihat. Tidak salah seperti itu, tetapi jelas itu tidak terlalu membantu Anda. Panduan Scrum mengatakan "Saat pekerjaan dilakukan atau diselesaikan, perkiraan sisa pekerjaan diperbarui," sehingga Templat MS masuk akal. Seperti yang saya katakan, itu sebenarnya bukan metrik yang berguna - tidak ada yang pernah melakukan pekerjaan yang baik untuk memperkirakan sisa pekerjaan untuk suatu tugas, dan Anda membuang waktu untuk melakukannya. Jadikan tugas Anda kecil dan biner (0 = selesai atau 1 = tidak), dan Anda memiliki ukuran dari apa yang sudah dilakukan dan apa yang tersisa, dan Anda tidak perlu memikirkannya.
Matthew Flynn
6

Saya tahu pertanyaan Anda secara khusus tentang menghindari desain dalam perencanaan. Tapi ini semacam Masalah XY .

Aku sudah berada di tempatmu sekarang. Daripada memberi Anda sesuatu yang dapat memberikan peningkatan tambahan, saya ingin membantu Anda melompati beberapa negara perantara tersebut.

Berikut adalah tiga hal yang dilakukan tim kami secara khusus terkait dengan perencanaan dan pelaksanaan pekerjaan. Ini telah membantu kami menghindari meronta-ronta desain dan melarikan diri dari perkiraan waktu yang tidak akurat.

Kriteria Penerimaan Automatable

Kisah-kisah kami ditunjukkan oleh sejumlah Kriteria Penerimaan Automatabel . Ini berarti, jika kita harus menulis tes otomatis untuk mengonfirmasi bahwa cerita telah selesai, apa yang akan terjadi?

Misalnya, "Ketika pengguna mengklik 'main' di iPad yang menjalankan iOS 6+, video mulai diputar." Mungkin sulit untuk mengotomatisasi tes ini, tetapi ini merupakan kriteria penerimaan (AC) dari cerita dan menyumbang satu poin.

Kami menggunakan skala Fibonacci, dan kami selalu mengumpulkan. Jadi, jika sebuah cerita memiliki empat kriteria penerimaan otomatis, itu adalah cerita lima poin.

Ukuran poin cerita maksimum kami adalah delapan poin, tetapi kami jarang memilikinya. Jika sebuah cerita memiliki lebih dari lima kriteria penerimaan otomatis, kami menemukan cara untuk membaginya.

Pra-Perawatan

Kami memiliki pertemuan awal pada hari Senin, tetapi pertemuan perawatan kami adalah tempat perencanaan tim terjadi. Sebelum perawatan, anggota tim akan pra-laki-laki cerita dengan menggambarkan hasil dan mengambil bacokan di kriteria penerimaan automatable.

Grooming menghadirkan keahlian tim untuk memahami kisah-kisah yang sudah disiapkan sebelumnya, menemukan persyaratan yang tidak ditentukan, membagi cerita, dll.

Kami kadang-kadang membuat daftar tugas di samping kriteria penerimaan, tetapi ini bukan perkiraan waktu. Kami tidak pernah memperkirakan waktu. Tugas hanyalah pernyataan kerja yang perlu dilakukan untuk mendukung kriteria.

Membatasi Work-in-Progress

Scrum tradisional berupaya membatasi waktu kerja hingga durasi sprint. Kami menemukan bahwa ini secara buatan menyebabkan kami bergegas memenuhi tenggat waktu sprint, membunuh akhir pekan kami karena sprint berakhir pada hari Jumat.

Pendekatan lain adalah membatasi pekerjaan yang sedang berjalan pada waktu tertentu. Kami telah bermigrasi ke yang terakhir dan secara signifikan lebih bahagia karenanya.

Setelah sebuah cerita berpindah dari jaminan yang sedang berjalan, kami mencirikannya sebagai salah satu dari beberapa keadaan:

  • Sedang Ditunda - kerja tim tidak dapat terjadi karena kami menunggu beberapa aktivitas tim ekstra
  • Dalam Pembangunan - bekerja untuk mencapai kriteria penerimaan
  • Tes Kebutuhan - kami yakin kami telah bertemu AC, menunggu orang lain untuk memverifikasi
  • Dalam Uji - cerita sedang dievaluasi terhadap AC, bug sedang diatasi
  • Siap untuk Menyebarkan - pada kesempatan yang tersedia berikutnya, itu akan ditayangkan

Kami kemudian menggunakan jumlah cerita di setiap negara bagian untuk mengarahkan fokus tim. Misalnya, pengembang mungkin bersedia mengambil cerita baru, tetapi jika kami memiliki banyak cerita Dalam Tes, lebih baik bagi mereka untuk membantu dalam cerita yang ada.

jimbo
sumber
3

Pertama, ketahuilah bahwa perkiraan akurat tidak mungkin dilakukan dalam keadaan tersebut. Jangan stres jika Anda salah. Namun, Anda masih memerlukan ide kasar untuk merencanakan, dan satu-satunya cara untuk menjelaskan ketidakpastian sepenuhnya adalah dengan menambahkan lebih banyak poin cerita ke perkiraan Anda. Jika Anda tidak tahu apakah itu 5 atau 13, gunakan 13.

Juga bermanfaat untuk memecah cerita sekecil mungkin. Kita sering memiliki cerita penelitian / desain dengan tujuan melakukan pekerjaan yang cukup untuk memiliki ide yang lebih baik tentang bagaimana melakukan fitur tersebut, kemudian fitur cerita itu sendiri masuk ke sprint berikutnya. Pikirkan mengapa ini berhasil. Bahkan jika Anda tidak tahu seberapa sulit sesuatu akan terjadi, Anda biasanya tahu cukup akurat dari pengalaman masa lalu berapa lama untuk mengetahuinya.

Karl Bielefeldt
sumber
2

Ada dua hal yang bisa Anda lakukan di sini.

Pertama, miliki semacam scrum master yang perannya adalah memantau diskusi dan mengatakan "Hei, kau mendesain lagi" saat itu. Ini lebih sulit daripada yang terlihat, putar orang ke dalamnya hari demi hari dan mulailah membuat semua orang menjadi ahli scrum sehingga siapa pun dapat memanfaatkannya.

Kedua, jika Anda merancang selama perencanaan sprint Anda harus dapat membedakan antara tidak cukup tahu untuk membuat panggilan pada durasi tugas, atau apakah Anda hanya merancang karena itu lebih menyenangkan.

Sekali lagi, master scrum harus menendang di sini dan memberi tahu Anda untuk menahan barang sampai Anda cukup tahu untuk menjadwalkannya, atau membuat Anda berhenti mendesain dan menjawab pertanyaan awal (Berapa lama waktu yang diperlukan).

Jadi, jika Anda melakukan perencanaan sprint, masuk akal untuk memiliki sponsor bisnis di sana untuk memeriksa simpanan Anda dan memprioritaskan hal-hal yang ingin mereka lihat dilakukan terlebih dahulu. Jika Anda melakukannya, Anda akan merasa lebih sulit untuk mendesain selama sesi karena mereka akan gelisah dan akhirnya tidak mau datang.

Ian
sumber
Kami sebenarnya menambahkan master scrum (seseorang dengan pengalaman Scrum, disewa untuk mengisi peran ini untuk kami) sehingga mudah-mudahan itu akan membantu; tetapi kita semua menyadari bahwa ini adalah masalah, yang saya perjuangkan adalah bagaimana melakukannya dengan lebih baik .
KutuluMike
Nah, Anda sudah mengidentifikasi masalahnya. Anda mendesain dalam rapat. Pertemuan berikutnya yang Anda miliki, jika Anda mendapati diri Anda mendesain, berhentilah, katakan "Kami tidak cukup tahu" atau "Kami cukup tahu". Jika Anda tidak cukup tahu, tunda hingga Anda memiliki lebih banyak info (Sesi desain di luar rapat perencanaan). Jika Anda memiliki cukup info, jadwalkan (atau tidak), dan lanjutkan.
Ian
Satu komentar lain yang harus saya tambahkan. Berhati-hatilah saat Anda menyewa ahli scrum. Dengan semua metode yang gesit, kuncinya adalah fleksibel. Adopsi apa yang berhasil, ubah apa yang tidak. Itu adalah perubahan besar bagi perusahaan yang suka mendokumentasikan prosedur dan rencana yang direncanakan.
Ian
0

Kami telah beroperasi berdasarkan perkiraan cerita 'dingin' selama perencanaan sprint dengan hanya beberapa diskusi terbatas. Perkiraan ini benar-benar sangat tidak akurat meskipun pembentukan tim dengan fokus yang cukup sempit ... terutama karena adanya banyak kode warisan yang tidak terdokumentasi dan tidak diomentari tanpa ada gagasan nyata tentang apa yang seharusnya terjadi dan staf yang sebagian besar telah berubah sejak aslinya ditulis.

Apa yang kami coba sekarang adalah meluangkan waktu sebelum merencanakan penyelidikan setiap cerita - dan di sini hanya satu dev akan menyelidiki satu cerita ... Kami berharap bahwa ini berarti bahwa dev yang menyelidiki akan dapat memberikan beberapa klarifikasi dan wawasan kepada membantu estimasi. Sejauh ini telah membantu pada kesempatan yang telah dicoba.

Saya belum yakin bahwa penyelidikan tambahan benar-benar membuat perkiraan cukup akurat untuk membenarkan biaya tetapi kami akan mencobanya untuk melihat beberapa sprint.

dave
sumber