Scrum: Is ok untuk desain / UX cerita pengguna terjadi dalam sprint yang sama dengan implementasi

9

Saat ini saya dalam sprint (dua minggu) di mana desainer ditugaskan untuk mendefinisikan persyaratan dan UX dari cerita pengguna tertentu.

Dalam sprint yang sama, saya akan mengimplementasikan desain ini. Selama perencanaan sprint, saya harus menebak berapa lama kisah pengguna yang tidak terdefinisi ini akan berlangsung.

Hari ini saya akhirnya menerima desainnya. Sayangnya, desain tidak lengkap / tidak jelas dan lebih mirip dengan kebutuhan klien daripada desain. Namun, dari sini, saya masih bisa melihat bahwa saya belum cukup memperkirakan.

Lebih buruk lagi, ini bukan pertama kalinya. Dalam sprint terakhir, hal yang persis sama terjadi. Saya menandainya dalam retrospektif kami dan scrum master tidak memiliki jawaban tentang bagaimana menyelesaikan ini, alih-alih mengatakan "itu hanya pengembangan untuk Anda". Ironisnya dia merasa terganggu jika pembakarannya tidak tepat sasaran ...

Sekarang saya harus bertanya / bekerja dengan desainer untuk menyelesaikan pekerjaannya. Ini akan menahan saya karena saya telah menyelesaikan semua tugas saya yang lain.

Jadi pertanyaan saya adalah

A) ~~bagaimana Anda menangani dependensi dalam perencanaan sprint?~~ EDIT: Apakah ok untuk desain / UX cerita pengguna terjadi dalam sprint yang sama dengan implementasi

B) bagaimana seharusnya saya sekarang mendekati sprint? Taksir ulang kisah pengguna saat ini dan saksikan burndown berubah menjadi burn up dan dianggap tidak kompeten / tidak produktif? Atau tambahkan tugas baru ke sprint saat ini di sepanjang baris "bantu desainer membuat desain yang cocok"

agile scrum planning

— Allan
sumber

Layak disebutkan bahwa pertanyaan Anda di baris subjek sangat berbeda dari pertanyaan di bagian bawah teks Anda. Akan sangat membantu jika Anda mengeditnya untuk memilih satu atau yang lain.

— pdr

14

bagaimana Anda menangani dependensi dalam perencanaan sprint?

Idealnya, dependensi non-pengembangan ditangani sebelum perencanaan sprint, sehingga Anda memiliki definisi yang baik dari item jaminan untuk memperkirakan upaya melawan.

Tapi, jika itu "hanya pengembangan untuk Anda" sprint terakhir, maka itu mungkin akan menjadi hanya pengembangan untuk Anda sprint ini, jadi Anda harus benar-benar meningkatkan perkiraan Anda di sana dan kemudian pada tugas yang akan datang yang berada dalam keadaan yang sama. Ini bukan dendam, dan akan menjadi kesalahan untuk membiarkannya datang begitu saja.

Apa yang dilakukannya adalah menunjukkan ketidakpastian estimasi tanpa desain yang relatif solid untuk diestimasi. Mungkin, ini akan mendorong manajer Anda untuk memastikan bahwa item simpanan produk didefinisikan dengan benar; tapi paling buruk itu akan menutupi punggungmu. Tidak ada yang mengeluh ketika pekerjaan datang di bawah anggaran.

Namun, Anda tidak melakukan itu, dan sekarang pertanyaan Anda adalah ...

bagaimana seharusnya saya sekarang mendekati sprint?

Seluruh tujuan Scrum sebagai alat manajemen proyek adalah untuk mengidentifikasi masalah sejak dini, yang telah Anda lakukan. Tambahkan ke manajemen Anda, biarkan mereka memutuskan apa yang harus dilakukan dengan sprint. Jika mereka mencoba menyalahkan Anda, bersikap rendah hati dan tanyakan bagaimana mereka menyarankan Anda mendekati situasi yang sama di masa depan, untuk menghindari masalah yang sama, bahkan jika Anda tidak benar-benar percaya bahwa itu adil.

Pada akhirnya, ini adalah masalah manajemen proyek, dan jika Anda mencoba menyelesaikannya dalam gelembung Anda sendiri, Anda membuat diri Anda gagal. Dan, ketika Anda melakukannya, Anda akan marah karena itu akan jatuh pada Anda, bukan pada manajer yang gagal menyelesaikan masalah ketika Anda memberi tanda kepada mereka.

— pdr
sumber

Terima kasih atas jawabannya. Untuk memperluas, master scrum saya ingin kami benar-benar gesit sehingga kami dapat mengubah / beralih pada cerita pengguna segera setelah itu telah dikodekan. Oleh karena itu ia tidak suka terlalu banyak dokumentasi / desain dimuka dan sebaliknya kita harus kode / rencana saat kita pergi. Tentu saja ini menuntun saya ke situasi di mana saya berada. Manifesto yang tangkas tampaknya mendukung pendiriannya. Jadi, apakah kita terlalu gesit untuk kebaikan kita sendiri?

— Allan

Sebagai contoh, salah satu cerita pengguna kami mungkin "Pengguna ingin dapat bermain melawan pemain manusia lain". Dalam perencanaan sprint kami, saya mungkin akan memecah ini menjadi beberapa tugas seperti: menunjukkan server, memilih server untuk terhubung, terhubung ke server. Perancang idealnya akan memberi tahu saya bagaimana server ditampilkan, filter daftar apa yang tersedia, apa yang terjadi jika tidak ada server, dll. Tentu saja daftar hal ini hanya tersedia bagi saya setelah ia mendesainnya dan dalam hal ini terjadi dalam sprint yang sama. Daftar ini juga dapat berubah / iterasi selama sprint.

— Allan

1

@ Allan: Apa yang tidak dipahami oleh master scrum Anda adalah bahwa, jika desainer harus menyelesaikan pekerjaan mereka sebelum pengembang dapat memulai pekerjaan mereka, itu adalah desain muka. Mewujudkannya dalam sprint tidak menghilangkan biaya desain di muka tetapi itu membuatnya kurang terlihat DAN membuatnya lebih sulit untuk memperkirakan pengembangan Anda. Jika Anda dapat menemukan cara untuk beralih dengan desainer Anda, itu hebat, menjadikannya bagian dari sprint dan membuat upaya yang sesuai untuk tugas kolaboratif. Tapi di muka tidak apa-apa, selama itu jujur dan, lebih disukai, dilakukan sebelum sprint.

— pdr

Jika itu tipikal cerita pengguna Anda, saya berpendapat bahwa cerita Anda terlalu besar. Dengan contoh Anda, saya berharap melihat "pengguna dapat melihat daftar server", "pengguna dapat terhubung ke server dan melihat daftar lawan yang tersedia" sebagai cerita.

— Jules

6

Pertama, ada perbedaan besar antara ketergantungan antara cerita / tugas dan ketidakpastian dalam lingkup / upaya cerita / tugas.

Dependensi ditangani dengan memberikan tugas / cerita dependen prioritas yang lebih rendah daripada tugas / cerita yang bergantung padanya dan mungkin anotasi yang tidak dapat dimulai sebelum tugas / cerita lain dilakukan.

Ketidakpastian harus diatasi dalam pertemuan perencanaan dengan mengklarifikasi pekerjaan yang perlu dilakukan pada cerita. Jika tidak mungkin untuk menghapus cukup ketidakpastian, cerita yang paling mungkin tidak memenuhi "Definisi Siap" Anda dan tidak boleh diterima dalam sprint.
Jika, karena alasan tertentu, cerita benar-benar perlu masuk ke sprint, satu-satunya pilihan Anda adalah menambahkan buffer risiko ke dalam estimasi.

Untuk sprint saat ini, jika Anda tidak dapat mengerjakan sebuah cerita, cukup laporkan bahwa dalam rapat harian berikutnya dan lakukan pekerjaan apa pun yang mungkin untuk mencapai tujuan sprint keseluruhan tim. Anda juga dapat membuat anotasi cerita sebagai diblokir dan oleh apa.
Setelah sprint dimulai, pada prinsipnya tidak mungkin untuk menambahkan tugas baru ke sprint.
Juga, jika suatu tugas ternyata lebih banyak bekerja daripada yang diperkirakan, maka Anda tidak mengubah estimasi tersebut, tetapi Anda melaporkan dengan setia apa kemajuan dan upaya yang tersisa dari tugas tersebut.

Pada akhirnya, di Scrum, timlah yang berjanji untuk memberikan sesuatu. Jika janji itu tidak dapat dibuat, maka itu adalah kegagalan seluruh tim, tidak pernah seorang individu dalam tim.

— Bart van Ingen Schenau
sumber

Ini juga jawaban yang bagus. Jika saya dapat menandai dua jawaban sebagai benar saya akan.

— Allan

3

Selama perencanaan sprint saya harus mengambil tebakan liar tentang berapa lama kisah pengguna yang tidak ditentukan ini akan berlangsung.

Itu kesalahan yang kau lakukan. Tidak ada yang bisa memaksa tim untuk menerima tugas dalam sprint dan itu tugas Anda untuk menyatakan bahwa tugas itu tidak dapat diperkirakan dan diterima dalam sprint kecuali ada setidaknya wireframe (misalnya). Tampaknya master scrum Anda sebenarnya adalah manajer proyek, yang hanya memperburuk keadaan.

Bagaimana mendekati tugas tersebut jika perlu untuk menyelesaikannya dalam sprint (untuk alasan bisnis yang valid)? Yah, pertama-tama Anda harus menetapkan batas waktu untuk desain, setelah itu Anda tidak akan dapat mengimplementasikannya. Misalnya: cerita diterima, tetapi desain harus disampaikan dalam minggu pertama dan diimplementasikan dalam minggu kedua. Selanjutnya, Anda harus bekerja sangat erat dengan perancang untuk memastikan akan mungkin untuk diterapkan dalam sprint. Scrum mengasumsikan tim lintas fungsi dan terserah Anda untuk mengatur pekerjaan Anda dengan perancang. Karena itu, jika Anda menerima tugas dalam sprint - yang tergantung pada tim untuk memutuskan - terserah tim untuk mengelola pekerjaan dengan cara yang diselesaikan dalam sprint, dan untuk mengelola risiko yang terkait. Anda tidak harus menunggu yang lain untuk menyelesaikan pekerjaannya untuk menyelesaikan pekerjaan Anda. Mungkin saja Anda akan mengungkapkan disfungsi yang lebih besar di organisasi Anda.

— Maxim Krizhanovsky
sumber

Terima kasih, Darhazer. Ya master scrum juga manajer proyek. Scrum master telah menyatakan bahwa harus ada perencanaan dan dokumentasi minimal. Alih-alih, kami akan membangun fitur saat berjalan, dengan ulasan terus-menerus selama sprint untuk mengulangi / mengubah apa yang dibangun sebagaimana ditentukan oleh palungan proyek (maka desain dan implementasi terjadi dalam sprint yang sama). Berasal dari peran di mana desainnya cukup solid di muka, saya mengalami kesulitan menyesuaikan diri dengan budaya kode-by-the-wire ini.

— Allan

3

"... master scrum juga manajer proyek." - tidak baik. "... perencanaan minimal dan dokumentasi ..." - apa sebenarnya IS dalam Definisi Anda tentang Siap dan / atau Dilakukan? "... ulasan selama sprint untuk mengulangi / mengubah apa yang dibangun sebagaimana ditentukan oleh palungan proyek ..." - itu harus menjadi keputusan Tim, bukan scrum master, tentu bukan manajer proyek dan (jika HARUS ada siapa pun ) itu harus menjadi pemilik produk!

— Phill W.

@PhillW. Kami tidak memiliki definisi siap. Kami hanya memiliki jaminan simpanan dengan berbagai kondisi detail untuk fitur. Detailnya semakin bertambah saat kita melangkah. Selesai secara resmi ketika para pemangku kepentingan menandatangani tetapi sebenarnya itu untuk tonggak sejarah dan manajer / scrum master / produser (orang yang sama) yang mengatakan kapan hal itu dilakukan. Saya sekarang telah melakukan "scrum" selama satu tahun, tidak lama setelah mulai saya melakukan beberapa belajar mandiri tentang scrum karena saya merasa cara kami melakukannya adalah aneh. Semakin banyak saya membaca, semakin saya merasa seperti kita melakukan scrum "Kargo". Tetapi politik mempersulit saya untuk melakukan sesuatu tentang hal itu ...

— Allan

1

Apakah tugas tentang desain dinyatakan sebagai cerita dan apa definisi tim Anda

sebuah cerita sudah siap
sebuah cerita selesai

Setiap cerita harus memiliki persyaratan dan ketentuan penerimaannya sendiri, tetapi saya pikir itu adalah praktik yang baik untuk memiliki seperangkat aturan yang berlaku untuk semua cerita. Misalnya, sebuah cerita siap jika (dan hanya jika!): Studi arsitektur ujung ke ujung selesai, desain tersedia, cerita telah diperkirakan oleh tim. Persyaratan penerimaan yang minimal dapat berupa: pengujian otomatis dilakukan, OK dan telah diintegrasikan ke dalam setelan tes, pengkajian kode dilakukan.

Jika sebuah cerita belum siap, jangan tanamkan di sprint Anda. Jika kondisi penerimaan tidak terpenuhi, maka itu belum selesai.

Dalam kasus Anda, tim dapat memutuskan bahwa untuk siap, sebuah cerita pengembangan perlu memiliki desain yang lengkap (setidaknya kerangka gambar, sesuaikan ini dengan realitas Anda sendiri). Jika demikian, Anda tidak dapat menangani desain dan pengembangan dalam sprint yang sama. Tim juga dapat memutuskan bahwa cerita UX / desain setidaknya harus menghasilkan desain gambar rangka. Jika bukan itu masalahnya, maka ceritanya tidak diterima dan dengan demikian ceritanya tergantung padanya.

Anda harus dengan mudah meyakinkan manajer Anda bahwa memiliki aturan yang kuat untuk siap adalah hal yang baik: mengevaluasi kembali kompleksitas selama sprint adalah praktik yang buruk. Ini berarti kecepatan tim tidak pasti dan kemudian mereka, sebagai manajer, memiliki visi yang buruk tentang pekerjaan tim dan masa depan.

— Keufran
sumber

0

Sprint biasanya dimulai ketika ceritanya jelas - pada tahap ini Product Backlog dibuat dan diprioritaskan. Jika Anda mulai tanpa memiliki desain dari yang seharusnya sudah jelas apa yang bisa dilakukan tanpa desain dan apa yang tidak ...

Jika Anda harus berimprovisasi saat desainnya 'menabrak' antara klien dan PO daripada PO Anda harus memberi tahu tim tentang setiap fitur baru segera setelah mereka muncul: ini adalah arti dari 'fleksibilitas' dalam Scrum - beradaptasi dengan yang sedang berlangsung situasi. Tim Pengembangan, Master Scrum, dan Pemilik Produk perlu berkomunikasi secara permanen, jika tidak, tidak ada reaksi waktu nyata untuk berubah.

Beberapa pelatihan lagi tidak dapat membahayakan ... Mungkin bekerja dengan desainer akan menjadi kesempatan bagi Anda untuk memperoleh beberapa keterampilan UX baru? ... itu mengamati gelas menjadi setengah penuh bukannya setengah kosong :))

— ScrumMasterChangeFacilitator
sumber