Bagaimana Anda memberi nama sprint di proyek Anda? [Tutup]

Beberapa alat manajemen perangkat lunak Scrum memberi Anda opsi ini untuk secara eksplisit memberi nama sprint Anda.

Apakah Anda memiliki cara yang disukai untuk memberi nama sprint Anda atau Anda hanya menggunakan skema sederhana seperti 1, 2, 3, ...?

Tanya tim .

Jika menurut mereka menyenangkan atau berguna untuk menamai sprint, pilih satu bersama.

Karena setiap sprint harus memiliki tujuan , seharusnya tidak menjadi masalah untuk menemukan nama yang cocok.

Memberi nama sprint sebenarnya dapat membantu tim fokus pada tujuan utama.

Saya pribadi suka hal semacam itu.

Setelah beberapa saat memikirkan hal ini, saya datang dengan kebaktian berikut:

<year> CW <starting calendar week> - <ending calendar week>: <goal> (<version>)

Versi adalah opsional.

Jadi Anda berakhir dengan sesuatu seperti:

2013 CW 27-28: Improved reporting and dashboards (v1.5.1)
2013 CW 29-30: Redesigned gadgets (v1.5.2)
...

Sintaks ini menjawab pertanyaan:

• Kapan itu dilakukan?
• Mengapa itu dilakukan?
• Dalam versi apa dirilis?

Dan juga:

• Ini bisa disortir
• Bisa ditebak
• Memungkinkan fleksibilitas tanpa mengorbankan informasi

Di satu perusahaan tempat saya bekerja, kami memiliki sprint / rilis bulanan, dan kami menamainya menurut abjad berdasarkan meme internet. Rilis yang saya kerjakan baru-baru ini adalah:

• keyboardcat
• lolcat
• megashark
• numanuma

Itu menambahkan sedikit kesenangan untuk proses, terutama ketika tiba saatnya untuk menyebutkan iterasi yang akan datang.

Jika semuanya untuk tujuan tertentu ("tambahkan pelaporan", "bawa lokasi Eropa") maka ada nama Anda. Jika itu adalah kumpulan hal-hal dari backlog, maka tanggal yang tidak jelas ("rilis Juni") bekerja untuk kita. Ini memungkinkan kita mengatakan kepada pengguna "Saya tidak berpikir itu akan cocok dalam rilis Juni, apakah boleh memasukkannya ke yang berikutnya?" atau "jika Anda menginginkannya dalam rilis Juni, kami harus menyelesaikan [apa pun] pada 5 Juni". Mereka hanya label, tetapi mereka memiliki tujuan.

Bagi kami, kami menikmati menempatkan nama-nama lucu, secara internal, ke rilis bernomor kami dan proyek-proyek besar untuk sedikit memecah kebodohan. Kami selalu mencari nama yang lebih lucu / lebih kreatif untuk proyek dan rilis kami yang lebih besar, namun kami juga jelas menggunakan penomoran tradisional (1.0, 1.1) atau sistem berbasis tanggal untuk melacak dari perspektif kode yang terbaik sampai saat ini adalah rapper sekolah lama. Tidak ada yang mengatakan pengembangan scrum tidak bisa sedikit lucu

Ex. Beastie Boys, Coolio, DJ Jazzy Jeff, Eazy-E, Flavour Flav, Dll

Di tim saya, sprint cenderung dinamai sesuai versi rilis produksi yang kami persiapkan. Jika ada rilis produksi yang mencakup beberapa sprint, kami menambahkan nomor iterasi. Jadi, misalnya,

• 5.0.2 Iterasi 1
• 5.0.2 Iterasi 2
• 4.16.1

dll.

Tanggal!

Proses kami menggunakan cabang rilis untuk setiap sprint yang kami lakukan, sehingga sprint dan rilis nama cabang selaras. Kami menggunakan tanggal rilis yang direncanakan sebagai nama cabang dan sprint.

Ini membuat memahami sejarah sedikit lebih mudah pada saat yang bersamaan - mis. Jika Anda melihat email lama tentang bug yang Anda pikir telah diperbaiki, berdasarkan tanggal email, Anda dapat dengan mudah melompat ke nama cabang terdekat ( s) untuk mendapatkan ide perubahan yang lebih baik. (Tentu, semoga ini juga dilacak di pelacak bug Anda /, tetapi kita semua tahu itu tidak selalu demikian.)

Sangat menyenangkan juga bahwa seluruh tim kami selalu tahu persis apa namanya, jadi kami selalu berada di halaman yang sama ketika merujuk pada sprint atau cabang. (Tidak pernah ada kebingungan "Apakah 'badger' rilis minggu ini atau minggu lalu?".)

Menurut pendapat saya, menggunakan angka untuk nama tidak benar-benar memberikan nilai. Dalam hal ini, walaupun mungkin menyenangkan untuk dilakukan, juga tidak ada nama abstrak. Menggunakan nama yang berorientasi pada tujuan mungkin merupakan tambahan yang bagus (mis. "2012-04-03: Widget pelanggan yang diperbarui"), tetapi saya tidak akan kembali menggunakan nama abstrak saja.

Untuk setiap rilis kami memilih nama kota kode besar sesuai abjad (mis. A tlanta, B oston, C hicago, D allas ...)

Dan beberapa nama kampus di kota itu menjadi nama sprint kami (Morehouse, Spelman, ..., Harvard, Cambridge dll)

Saya tidak pernah benar-benar berpikir untuk memberi nama mereka. Kami biasanya melampirkan build ID di akhir sehingga kami dapat melacak masalah, tetapi penamaan sebenarnya bukan bagian dari proses. Dengan rilis setiap dua minggu, Anda akan membakar 26 nama setahun.

Saya kira ini akan membuatnya menjadi bagian yang menyenangkan dari perencanaan sprint. Saya mungkin harus mencobanya untuk sprint berikutnya.