Kami saat ini menggunakan JIRA untuk melacak pekerjaan pengembangan kami. Manajemen saya ingin memformat dan mengkategorikan semuanya sebagai "Cerita Pengguna," termasuk tugas-tugas terkait pengembangan non-perangkat lunak. Sebagai contoh:

"Sebagai manajer pengujian, dapatkah saya melakukan pengujian aplikasi hanya menggunakan tes otomatis dan tidak ada pengujian manual sehingga saya dapat menguji aplikasi seefisien mungkin?

Kriteria Penerimaan: 1. Konversi 50 tes manual yang ada ke tes otomatis sepenuhnya 2. Tes harus dilaksanakan dalam waktu kurang dari 1 jam "

Saya ingin mendapatkan pengertian dari komunitas jika masuk akal untuk menggunakan "cerita pengguna" untuk pekerjaan yang mendukung proses pengembangan perangkat lunak, tidak dilakukan oleh programmer, dan tidak secara langsung menghasilkan kode yang dapat dikirim. Atau haruskah ini ditangani / diklasifikasikan secara berbeda (misalnya, dalam JIRA)?

Diperbarui 6/7/2011 - Pertanyaan berulang untuk fokus pada istilah "cerita pengguna".

Iya

setiap pemangku kepentingan, fitur apa pun yang meningkatkan sistem

[biarkan purist downvotes dimulai!]

"Manajemen saya ingin menggunakan Agile untuk semuanya, termasuk tugas terkait pengembangan non-perangkat lunak."

Ini tidak berarti menulis cerita pengguna untuk setiap fitur.

Jika Anda ingin menulis cerita pengguna untuk setiap fitur, Anda belum tentu Agile. Anda hanya menulis cerita pengguna untuk setiap fitur.

Cerita Pengguna! = Agile.

Cerita Pengguna adalah cara untuk mengumpulkan dan memahami persyaratan. Mereka dapat digunakan dengan cara air terjun yang sempurna, jika Anda mau. Beberapa orang melakukan ini.

Agile adalah cara untuk mengelola proyek. Anda dapat menggunakan Cerita Pengguna, atau tidak, dalam proyek Agile.

Kisah Pengguna untuk mengelola utang teknis dan tugas internal - sekali lagi - tidak ada hubungannya dengan menjadi Agile.

Banyak orang yang dengan senang hati menambahkan fitur "teknis" atau "dukungan" ke dalam sprint tanpa membuang waktu untuk menulis "kisah pengguna" palsu untuk pengguna yang murni internal, dengan nilai tambah terbatas, dan bukan pemegang saham.

Jika QA tidak mendapatkan cerita mereka, berapa banyak kerugian bisnis nyata yang ada?

Jika para pemangku kepentingan sejati tidak mendapatkan cerita mereka, bisnis ini benar-benar menderita.

Ini tidak masuk akal bagi saya. 'Kisah Pengguna' pada intinya adalah hanya itu, kisah pengguna, bukan kisah Manajer Proyek, bukan Kisah Pengembang, bukan kisah Insinyur Jaminan Kualitas.

Pada catatan itu, perangkat lunak adalah:

1. Pasti
2. Bisa diuji

Perbaikan proses bersifat terbuka, dan biasanya subjektif.

Kriteria Penerimaan: 1. Peningkatan pengujian 1 (x / y)

Bagaimana Anda mengukur Peningkatan untuk pengujian? Tidak ada kontrak yang pasti untuk itu.

Dan pada catatan yang tidak terkait, SAYA SANGAT HARAPAN contoh yang Anda berikan di atas,

Sebagai manajer pengujian, dapatkah saya melakukan pengujian aplikasi hanya menggunakan tes otomatis dan tidak ada pengujian manual sehingga saya dapat menguji aplikasi seefisien mungkin?

... hanya itu contoh, karena ada begitu banyak yang salah dengan hal ini yang bahkan tidak bisa saya gambarkan.

Utang Teknis bisa ditangani dengan cara yang mirip dengan cerita pengguna, tetapi ini bisa agak jelek di kali. Misalnya, untuk memiliki cerita seperti, "Sebagai pengembang, saya ingin memiliki tes unit kerja sehingga saya dapat memiliki kepercayaan pada tes untuk memvalidasi jika perubahan lain merusak sesuatu," tidak memiliki banyak nilai bagi pemilik produk tetapi mungkin merupakan ide yang baik bagi tim untuk melakukan sebagai bagian dari refactoring sendiri yang merupakan bagian dari pekerjaan dalam sprint.

Saya menyukai gagasan memiliki tugas yang terpisah dari cerita pengguna karena tugas tersebut tidak akan menjadi sesuatu yang akan Anda perlihatkan kepada pengguna akhir suatu sistem tetapi bisa menjadi sesuatu untuk membantu meningkatkan pemeliharaan dan waktu yang diperlukan untuk mengembangkan beberapa fitur baru. Tergantung pada berapa banyak tugas, dalam hal total poin keseluruhan karena beberapa tugas bisa 2 menit dan yang lain mungkin 2 minggu, telah dibangun ini mungkin yang menentukan apakah tim mengambil sprint dan tidak memasukkan fitur baru tetapi bekerja pada tugas untuk membersihkan hal-hal yang telah saya lihat beberapa kali di tempat saya bekerja.

Menurut pendapat saya yang sederhana, ya Anda dapat menggunakan cerita pengguna untuk proyek pengembangan non-perangkat lunak, tidak hanya memproses tugas perbaikan. Ambil contoh, 3 tahun yang lalu saya adalah pria terbaik di pernikahan teman saya dan saya menggunakan metodologi Agile dan cerita pengguna untuk merencanakan pernikahan. Semua tugas yang harus kami selesaikan ditulis sebagai kisah pengguna dengan persona, niat, justifikasi, dan kriteria keberhasilan untuk setiap kisah pengguna. Semua pihak yang terlibat mengambil bagian dalam scrum harian kami untuk membahas apa yang kami lakukan hari sebelumnya dan apa yang akan kami lakukan hari itu. Setiap orang tersebar secara geografis sehingga kami mengadakan panggilan konferensi untuk rapat scrum harian kami, perencanaan sprint, retrospektif, penulisan cerita dan sesi estimasi .... sebut saja, kami berhasil. Kami memiliki total 6 sprint (3 bulan) dan pernikahan itu sukses luar biasa tanpa ada batu yang terlewat.

Anda memiliki masalah besar ketika Anda memasukkan "cerita pengguna" internal ke dalam campuran dengan cerita pengguna yang sebenarnya.

Baca ulang sebanyak mungkin definisi "pemangku kepentingan" yang dapat Anda temukan.

http://en.wikipedia.org/wiki/Scrum_(development )

http://wiki.openbravo.com/wiki/Scrum/Pigs_and_Chicken

http://www.testertroubles.com/2009/04/scrum-pigs-and-chickens.html

Bacalah mereka dengan sangat hati-hati agar Anda dapat melihat perbedaan antara Ayam dan Babi.

"Kisah pengguna" internal ditulis oleh ayam.

Kisah pengguna yang sebenarnya ditulis oleh babi.

Kisah pengguna "berorientasi ayam" Anda tidak terlalu penting. Tidak peduli seberapa banyak manajemen ingin melacak mereka seolah-olah itu adalah cerita pengguna nyata dengan nilai nyata, mereka bukan cerita pengguna nyata dan mereka tidak menciptakan nilai dengan cara yang sama.

Argumen yang kabur adalah masalah QA. QA itu penting dan tanpa itu, tidak ada yang berhasil.

Itu tidak secara ajaib membuat QA tiba-tiba menjadi babi. Itu membuat mereka masih non-stakeholder. Mereka menyediakan dukungan, infrastruktur, dan fondasi penting untuk pekerjaan selanjutnya. Tapi itu "cerita pengguna" pada dasarnya berbeda dari kisah pengguna nyata pengguna sebenarnya.

Jika QA tidak menunjukkan pengujian peningkatan dalam pengujian, tidak ada yang keluar dari bisnis. Uang tidak hilang.

Jika pengguna tidak dapat melakukan bisnis di tempat pertama, Anda keluar dari bisnis. Uang hilang. Seluruh operasi adalah kegagalan total.

Jangan campur aduk pemangku kepentingan internal ("ayam") dan nyata ("babi").

Komentar "ayam dan babi" tidak tepat. Pemangku kepentingan internal adalah ayam ketika datang ke produk yang dikembangkan (kecuali jika sedang dikembangkan untuk mereka), tetapi mereka babi ketika datang ke proses pengembangan.

Pertanyaan yang Anda tanyakan adalah apakah rumus kalimat "Sebagai , Saya ingin bisa _ , sehingga saya bisa __ "akan berguna untuk mendefinisikan dan meningkatkan proses bisnis di mana perbaikan tidak memerlukan penulisan kode perangkat lunak baru. Saya menemukan utas ini karena saya berpikir untuk melakukan hal yang sama dan saya sedang mencari praktik terbaik, tetapi intuisi saya yang kuat adalah bahwa jawaban untuk pertanyaan Anda adalah "ya." Tujuan dari struktur kalimat ini adalah untuk memaksa penulis untuk mengabstraksi solusi yang mungkin sudah ada dalam benaknya dan fokus pada apa yang pengguna - dalam hal ini kasus, pengguna proses - ingin dapat melakukan. Saya tidak melihat alasan mengapa cerita pengguna tidak akan berguna ketika diterapkan pada proses.

Poin tentang kriteria penerimaan adalah hal yang baik, tetapi tidak perlu dogmatis tentang hal itu (yang toh Agile). Merupakan latihan yang baik ketika merancang proses bisnis untuk bertanya, "Bagaimana saya tahu jika perubahan dalam proses mencapai tujuan saya?" Memang benar bahwa Anda tidak selalu dapat menjalankan tes otomatis untuk menjawab pertanyaan itu, tetapi itu bukan alasan untuk mendiskualifikasi kisah pengguna sebagai alat.