Tugas Pengembangan Bersama untuk Cerita Pengguna Agile


8

Tim saya akan menggunakan Layanan Tim Visual Studio untuk proyek yang akan datang. Alat Agile biarkan saya mengatur Kisah dan Tugas Pengguna secara hierarkis seperti ini:

Epik> Fitur> Kisah Pengguna> Tugas / Bug

Katakanlah saya sedang merancang sistem manajemen Student Org (club) untuk siswa dan penasihat sekolah menengah. Siswa dan Penasihat dapat bergabung dengan klub, menjadi petugas, mengatur acara, mengirim pengumuman, dll.

Mari kita ambil fitur Pengumuman sebagai contoh:

Kisah Pengguna:

  • Sebagai Pelajar, saya ingin membaca Pengumuman untuk klub saya bagian dari sehingga saya menyadari perubahan jadwal.
  • Sebagai Penasihat, saya ingin membaca Pengumuman untuk klub saya bagian dari sehingga saya menyadari perubahan jadwal.
  • Sebagai Penasihat, saya ingin mengirim Pengumuman untuk klub saya bagian dari sehingga Siswa saya akan mengetahui perubahan jadwal
  • Sebagai Administrator, saya ingin mengirim Pengumuman ke SEMUA klub sekolah sehingga saya dapat membuat mereka sadar akan konflik penjadwalan.
  • dll

Jika kita menganggap ini adalah Cerita Pengguna yang ditulis dengan baik (yang mungkin bukan), saya menjadi bingung ketika tim pengembangan saya dan saya duduk untuk membagi item-item ini menjadi Tugas pengembangan. Kami dapat membahas beberapa Cerita Pengguna dengan Tugas pengembangan tunggal. Misalnya, kami memiliki alat yang menghasilkan tindakan CRUD untuk semua lapisan dari UI ke DB hanya dengan mendefinisikan properti Pengumuman. Jadi, bagian dari beberapa "Kirim" dan "baca" Cerita Pengguna diselesaikan dalam satu langkah pengembangan tunggal.

Dari apa yang saya baca, setiap Kisah Pengguna harus independen dari yang lain dan itu masuk akal. Tetapi masing-masing dari User Stories kami membagikan tugas "Generate UI and DB" karena ini adalah bagaimana kami membuat UI tingkat dasar kami (sebelum kami menyesuaikannya). Saya seharusnya tidak menulis Tugas "Hasilkan UI dan DB" untuk setiap Kisah Pengguna. Itu terlalu banyak redundansi. Tapi saya tidak tahu bagaimana menulis tugas "Hasilkan UI dan DB" yang harus diselesaikan sebelum Cerita Pengguna dapat dimulai.

Saya memiliki kebingungan serupa dengan sistem izin kami. Kami memiliki berbagai jenis akun seperti Mahasiswa, Penasihat, dan Admin yang semuanya memiliki akses ke halaman Pengumuman, tetapi memiliki fungsi yang berbeda di dalam halaman (Saya menangkap ide ini dengan Cerita Pengguna di atas). Kita dapat menulis sistem izin menjadi modular sehingga dapat digunakan untuk Fitur lainnya, tetapi saya tidak tahu di mana harus menulis Tugas untuk membuat "sistem izin modular".

Saya kira seluruh kisah Pengguna ini membuat saya bingung. Ya, ini bagus untuk menangkap fungsionalitas suatu sistem, tetapi ketika harus memikirkan tugas-tugas pengembangan, saya sepertinya tidak bisa membungkus kepala saya dengan hal itu. Nasihat apa pun akan bagus.


TL; DR: Beberapa pemrograman yang saya lakukan untuk satu Kisah Pengguna dapat digunakan di tempat lain dalam proyek kami untuk Kisah Pengguna lainnya (sistem izin, dll). Bagaimana cara saya menulis / mengatur Tugas untuk Cerita Pengguna untuk menggambarkan kemungkinan ini?

Jawaban:


11

Saya seharusnya tidak menulis Tugas "Hasilkan UI dan DB" untuk setiap Kisah Pengguna. Itu terlalu banyak redundansi. Tapi saya tidak tahu bagaimana menulis tugas "Hasilkan UI dan DB" yang harus diselesaikan sebelum Cerita Pengguna dapat dimulai.

Kamu tidak .

Anda menulis cerita pengguna sebagai kebutuhan pengguna tingkat tinggi - Anda sudah sejauh itu.

Kemudian Anda memilih kisah pengguna (fitur) yang akan Anda tangani pertama kali. Pada titik ini - mengingat kondisi produk saat ini - Anda memutuskan cara terbaik untuk mengimplementasikan fitur ini. Kemudian Anda melakukan pekerjaan teknis minimum yang diperlukan untuk mengimplementasikan fitur. Kemudian Anda beralih ke kisah pengguna berikutnya.

Ini mungkin berhasil sebagai berikut:

  • Kami duduk untuk melakukan kisah pengguna 1 dan mengidentifikasi bahwa itu membutuhkan database. Jadi kami mengimplementasikan basis data dan kemudian fitur.
  • Kami duduk untuk melakukan kisah pengguna 2 dan mengidentifikasi bahwa - hei - kami sudah memiliki database jadi sekarang kita hanya perlu memperluas UI.

Atau dalam contoh Anda, ini mungkin berhasil sebagai berikut:

  • Kami duduk untuk mengimplementasikan pengiriman pengumuman. Kami membangun UI dengan kotak teks dan tombol kirim yang membuat posting bentuk. Back-end, tidak ada yang terjadi. Keren. Kisah pengguna selesai.
  • Sekarang kita duduk untuk mengimplementasikan pengumuman penerimaan ... kira sudah waktunya untuk mulai melakukan sesuatu dengan mereka ketika mereka dikirim.

Seluruh tujuan dari proses ini adalah untuk menghentikan Anda dari mencoba mendesain semuanya di muka dan memungkinkan Anda untuk membuat keputusan berdasarkan informasi tentang bagaimana menerapkan hal berikutnya mengingat keadaan saat ini dari perangkat lunak. Itu secara langsung tidak sesuai dengan mencoba memecah semua cerita menjadi tugas teknis sebelum memulai salah satunya.

Jadi, Anda hanya merancang solusinya setelah Anda mengambil cerita dan Anda mengembangkan fitur desain Anda pada suatu waktu. Bagaimana (dan bahkan apakah) Anda mendokumentasikan desain teknis Anda setelah Anda mulai mengerjakan sebuah cerita, itu terserah Anda.

Jika dua pengembang mengambil dua cerita pada saat yang sama dan mereka berdua berbagi persyaratan teknis, itu memberitahu Anda bahwa Anda tidak dapat melakukan pekerjaan-pekerjaan itu secara paralel, jadi pilih satu dan minta pengembang lainnya melakukan sesuatu yang lain.

Tujuannya di sini adalah untuk mengimplementasikan solusi sederhana dan merevisi desain Anda ketika persyaratan baru muncul.

Dan, yang paling penting, ingat: ini bukan ilmu .


+1 untuk "hal-hal basis data ada, mari perpanjang UI." Tim kami melakukan hal yang tepat pagi ini, sebenarnya. Itu hanya berarti cerita dengan hal-hal umum adalah cerita yang lebih besar. Kemungkinan besar itu akan lebih banyak poin cerita daripada cerita berikutnya, kecuali upaya pengujian lebih besar. Kami memiliki 1 cerita "hal-hal umum" yang akhirnya menjadi 13 poin. Kisah selanjutnya pada dasarnya adalah melakukan smidgeon dari hal-hal basis data, dan memperluas UI. Itu juga 13 poin. Kurang pengembangan, tetapi kami mengidentifikasi lebih banyak kasus uji. Kisah terakhir jauh lebih sedikit daripada 3 lainnya, karena lebih sedikit kasus uji.
Greg Burghardt

Saya memperlakukan Cerita / Tugas Pengguna seperti metodologi Air Terjun yang lebih "formal". Saya mencoba untuk memikirkan dan menulis semua Tugas yang diperlukan untuk menyelesaikan setiap Kisah Pengguna sebelum pengembangan bahkan dimulai. Saya tidak mengerti konsep dasar Agile sebagai "memilih sebuah cerita, menentukan tugas, mengimplementasikan, mengulangi". Agile lebih masuk akal sekarang, terima kasih!
Schmidty15

1
@ Schmidty15: Saya juga pernah melakukan hal yang sama. Dan mengalami masalah yang sama. Memperlakukan lincah seperti air terjun berarti Anda menghadapi masalah yang sama dengan perkembangan air terjun, kecuali lebih sering.
Greg Burghardt

1
@ Schmidty15 tim saya (lama) menggunakan VSTS sama seperti Anda. Kami bahkan tidak akan menggunakan tugas jika kami tidak membutuhkan kepatuhan ISO-9001. Kami membuat tugas dengan cepat sesaat sebelum melaksanakan tugas semata-mata sehingga kami memiliki cara untuk melacak setiap komit kembali ke “persyaratan”. Itu adalah cara yang nyaman bagi kami untuk menghindari jebakan "Saya tidak memiliki item pekerjaan untuk refactoring ini". Hanya makanan untuk dipikirkan. Anda bahkan mungkin tidak perlu melacak tugas di toko Anda. Anda mungkin ingin melakukannya tepat pada waktunya untuk tujuan penelusuran.
RubberDuck

1
@Frayt: Anda menulis "Kisah pengguna harus ditulis dari perspektif pengguna tanpa informasi teknis." . Sebenarnya itu mungkin benar, tetapi cerita pengguna tidak selalu merupakan satu-satunya jenis item pada jaminan produk. Anda dapat memiliki jenis cerita lain.
Bryan Oakley

2

Mengingat bahwa Anda memasuki setiap sprint dengan daftar cerita yang diprioritaskan, dan setiap cerita dipecah menjadi tugas teknis yang terpisah, semua pengembang harus mengerjakan tugas untuk cerita prioritas tertinggi sebelum mulai bekerja pada cerita prioritas tertinggi kedua. Karena itu, saat Anda mulai mengerjakan cerita prioritas kedua, tugas 'Hasilkan UI dan DB' seharusnya sudah selesai sebagai bagian dari cerita pertama. Jadi, jika selama perencanaan sprint Anda menemukan bahwa satu tugas teknis digandakan di beberapa cerita, kaitkan tugas itu dengan cerita prioritas tertinggi sehingga akan diselesaikan terlebih dahulu.

Jika tim Anda memiliki kebiasaan mengatur prioritas cerita setelah sprint dimulai, Anda dapat melihat manfaatnya dengan memasukkan tugas teknis duplikat pada setiap cerita, dan membuat catatan tentang tugas yang digunakan oleh cerita lain untuk menggunakannya.

Mungkin membantu untuk masuk ke dalam pola pikir bekerja dari daftar tugas teknis alih-alih daftar cerita.

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.