Apakah dokumentasi kisah pengguna? [Tutup]

Kami perlu melakukan beberapa dokumentasi pengguna untuk produk yang telah kami kerjakan selama beberapa sprint terakhir. Kami sekarang memulai proyek baru dalam sprint berikutnya dan PO membuat dokumentasi untuk produk yang sebelumnya diproduksi sebagai cerita Pengguna untuk sprint ini.

Saya hanya ingin tahu pendapat Anda tentang pendekatan ini. Secara pribadi, saya tidak setuju bahwa dokumentasi adalah Kisah Pengguna dalam Scrum karena tidak menghasilkan kode apa pun.

EDIT: Terima kasih atas pendapat Anda semua. Saya memilikinya di belakang kepala saya bahwa sprint adalah untuk mengimplementasikan peningkatan perangkat lunak yang berfungsi, tetapi pandangan Anda telah mengubah pandangan saya. Terima kasih atas semua jawaban Anda.

"Sebagai pengguna X, saya perlu tahu cara kerja X" sepertinya kisah pengguna yang sah bagi saya. Ini dapat menghasilkan dokumentasi tertulis atau bantuan online.

Intinya bukan hanya kode - itu memenuhi persyaratan pengguna.

Idealnya, dokumentasi adalah bagian dari setiap cerita pengguna dan tidak pernah menumpuk. Tapi, di dunia nyata, itu sering tidak terjadi. Dalam hal ini, Anda harus membuat cerita pengguna untuk mengejar bagian dokumentasi yang hilang.

Anda benar, itu tidak menghasilkan kode apa pun. Tetapi memenuhi kebutuhan pengguna dan harus diprioritaskan terhadap persyaratan pengguna lainnya.

Jika ini berarti tidak pernah selesai, karena fungsi ini dan itu sedang dikerjakan maka Anda mungkin tidak memerlukan dokumentasi yang buruk.

Saya setuju dengan penilaian dokumentasi pdr jika tentang persyaratan, dokumentasi teknis atau proyek. Idealnya itu harus dimasukkan ke dalam pekerjaan sprint.

Dokumentasi produk yang saya rasa sangat berbeda karena merupakan permintaan pengguna yang sebenarnya yang dapat dikirim dan secara langsung memberikan nilai kepada pengguna. Ini harus dipahami tentu saja bahwa Dokumentasi Produk pada dasarnya bukan Tugas Teknis tetapi Tugas Fungsional, dan mungkin atau mungkin bukan kegiatan yang sesuai untuk sumber daya teknis pada proyek.

Saya pikir itu harus menjadi cerita pengguna, namun saya merasa bahwa sumber daya proyek yang memiliki pemahaman yang kuat tentang persyaratan bisnis, perspektif pengguna dan keterampilan menulis teknis yang baik harus ditugaskan tugas-tugas ini. Idealnya, ini akan menjadi analis bisnis jika tersedia, atau mungkin tester QA tingkat tinggi dengan pemahaman yang kuat tentang persyaratan, cerita pengguna, dan keterampilan menulis teknis yang baik. Ini juga bisa menjadi pengembang, namun dokumentasi produk yang ditulis oleh pengembang cenderung tidak berkualitas tinggi atau berguna karena pengembang biasanya terlalu dekat dengan detail teknis.

Di organisasi kami, tim perkakas, yang bertanggung jawab atas pemeliharaan dan peningkatan sistem integrasi berkelanjutan kami menggunakan Scrum untuk membantu mereka mengelola pekerjaan mereka. Mereka tidak menulis kode tetapi mereka tetap berlatih Scrum.

Untuk menjawab pertanyaan Anda secara khusus, saya akan bertanya apakah tim menganggap bahwa dokumentasi adalah bagian dari "Definisi Selesai" atau tidak.

Jika tim menganggap bahwa dokumentasi adalah bagian dari "definisi selesai" maka, tidak perlu untuk cerita tambahan dan cerita tidak dapat diterima kecuali dokumentasi tersebut ditulis dan divalidasi.

Jika tim menganggap bahwa dokumentasi tersebut bukan bagian dari "definisi selesai", saya akan membuat cerita terpisah sehingga Pemilik Produk dapat mengelola pekerjaan mereka.