Berapa banyak detail tentang kisah pengguna yang bisa diharapkan pengembang?

Kelemahan terbesar dari pengembangan lincah yang saya alami adalah bahwa orang yang tidak terlibat dalam pengembangan fokus pada mantra bahwa cerita pengguna (3-10 hari orang ideal) tidak boleh mengandung lebih dari 1-3 kalimat seperti:

Sebagai pelanggan, saya dapat menggunakan pencarian teks bebas sehingga saya dapat menemukan produk yang saya cari.

Memberikan kalimat ini, manajer proyek mengharapkan saya sebagai pengembang untuk berkomitmen pada estimasi dan mengembangkan cerita. Mereka menganggap bahwa pengembangan tangkas berarti bahwa kalimat seperti ini adalah semua yang harus mereka berikan kepada pengembang.

Saya tidak akan menyalahkan mereka karena literatur terkenal tentang pengembangan lincah menciptakan kesan bahwa ini sebenarnya akan berhasil. Saya sudah membaca sekitar 2 halaman dalam bahasa alami per cerita di "Planning XP", tapi hanya itu. Karena "perangkat lunak yang berfungsi" lebih disukai daripada "dokumentasi komprehensif", topik ini tampaknya umumnya dihindari.

Kenyataannya adalah, tentu saja, bahwa jika pengembang diberi kesempatan untuk melakukannya, sebuah wawancara dengan pelanggan memunculkan daftar panjang persyaratan yang dimiliki pelanggan tentang cerita tersebut:

• Kami membutuhkan operator boolean seperti AND dan OR.
• Kami membutuhkan pencarian fuzzy dan semua istilah.
• Kita perlu mencari dengan kata-kata tunggal dan juga dengan frase.
• Kami tidak ingin menemukan produk yang memenuhi kriteria X, Y, dan Z.
• Kami ingin mengurutkan hasilnya. Oh, dan omong-omong, pengguna dapat memilih kriteria pengurutan dalam kotak kombo dengan opsi a, b, dan c.

Jadi Anda tahu bahwa saya tidak berbicara tentang detail teknis atau desain perangkat lunak atau bahkan detail implementasi. Ini persyaratan murni. Semakin lama kita berbicara, semakin banyak pelanggan menyadari bahwa sebenarnya ada cukup banyak untuk dikatakan tentang apa yang mereka inginkan.

Tetapi cukup sering saya menemukan diri saya dalam situasi bahwa informasi tersebut tidak disediakan atau dengan cara yang sangat buruk. Tidak mungkin saya melakukan wawancara, juga tidak ada orang yang akan berada dalam posisi untuk melakukan wawancara memberi saya hasilnya.

Kadang-kadang, manajer bahkan datang dengan rincian teknis seperti "kami ingin mencari Lucene" tetapi mereka tidak mau memikirkan apakah mereka hanya ingin menemukan nama produk atau deskripsi produk. Terkadang saya pikir mereka hanya malas;)

Bagi saya, ini adalah masalah utama dalam proyek tempat saya bekerja (aplikasi web e-bisnis, 500-2000 orang hari per proyek). Saya sudah cukup sering mengatasi masalah ini, dan manajer menyadari bahwa sebagian besar pengembang memiliki masalah dengan situasi tersebut. Tetapi mereka percaya bahwa pengembang terlalu "perfeksionis". Mereka tampak kesal bahwa pengembang "selalu ingin semuanya ditentukan".

Karena kurangnya angka yang diakui secara umum, sulit untuk diperdebatkan. Semua orang tahu berapa lama iterasi seharusnya. Tapi tidak ada yang bisa mengatakan berapa banyak persyaratan yang dibutuhkan untuk memperkirakan dan mengembangkan cerita.

Apakah Anda punya referensi?

Anda kehilangan titik lincah sedikit. Apa yang Anda panggil sebuah cerita pengguna, saya lihat sebagai setidaknya enam: satu telanjang-tulang mencari, dan satu untuk masing-masing poin-poin Anda. Dengan segala cara, buatlah rencana yang cukup untuk menghindari melukis diri sendiri ke sudut yang akan mahal untuk keluar dari, tetapi seluruh gagasan adalah bahwa Anda memberikan minimum yang diperlukan untuk memberikan nilai, dan melakukannya dengan cukup cepat untuk mendapatkan umpan balik yang cepat.

Ketika Anda membagi cerita seperti itu, itu tidak hanya membuatnya lebih mudah untuk ditaksir, tetapi juga memungkinkan pemilik produk untuk memprioritaskan dengan cara yang lebih baik. Tentu saja mereka menyukai kemampuan untuk mengurutkan hasil pencarian, tetapi mungkin itu tidak sepenting item lain di backlog yang sama sekali tidak terkait dengan pencarian.

Juga, pada gagasan programmer membutuhkan segala sesuatu yang ditentukan, cobalah untuk melihatnya dari sudut pandang pelanggan. Sering kali, ini seperti Anda akan membeli mobil, dan si penjual bertanya warna apa yang Anda inginkan untuk kenop penghapus kaca depan mobil. Banyak detail yang kami anggap penting sama sekali tidak relevan dari sudut pandang pelanggan. Saya telah bekerja di mana persyaratannya sangat spesifik, dan percayalah, itu tidak terlalu menyenangkan. Jenis garis lintang yang Anda keluhkan, banyak programmer akan senang memilikinya.

Kedengarannya seperti masalah pertama adalah bahwa Anda tidak seharusnya menerapkan perkiraan waktu untuk cerita pengguna. Anda seharusnya mengambil cerita dan menerapkan "poin cerita", yang merupakan perkiraan umum kompleksitas dari 1 hingga INFINITY. Poin cerita sering menjalankan sesuatu seperti 1,2,3,5,8,13,20 ... (Setiap organisasi memiliki aturannya sendiri.) Mereka umumnya menerapkan sesuatu seperti:

1 - Anda dapat melakukannya dalam tidur Anda dan itu hampir tidak layak diterapkan. 2 - Anda memahami hal ini, dan dapat menyelesaikannya dengan cepat dengan sedikit risiko dibanjiri. 3 - Anda mengerti ini, tetapi mungkin ada satu atau dua kejutan. 5 - Ini akan sedikit riset, dan memiliki sejumlah kecil risiko. 8 - Ini adalah tugas besar, perlu banyak penelitian, dan mungkin tidak cocok dalam sprint. 13 - Ini sangat besar, dan pasti tidak akan cocok dalam sprint. Ada risiko besar. dll.

Secara umum, setiap cerita pengguna yang berusia 8 atau lebih perlu dipecah menjadi cerita yang lebih kecil.

Jika Anda tidak memiliki informasi untuk melakukan ini, Anda pasti harus mengembalikannya kepada manajer proyek dan mengatakan bahwa Anda memerlukan informasi lebih lanjut.

Anda benar-benar hanya dapat memperkirakan waktu setelah Anda menerima cerita dalam sprint, tetapi meskipun begitu, ada sedikit penekanan pada ini. Idenya adalah bahwa begitu tim Anda terbiasa dengan proses penunjukan, Anda dapat mengukur output kasarnya per sprint dalam poin cerita, dan rencanakan seperti itu. Anda tidak ingin merencanakan skala waktu yang lebih pendek daripada sprint. Idenya di sini adalah bahwa jika Anda menjabarkan tugas dengan benar sehingga banyak cerita cocok dalam sprint, dan berada dalam rentang poin 1-5 cerita, itu berarti bahwa mereka cukup didefinisikan dengan baik.

Juga, sepertinya para PM di perusahaan Anda tidak mengerti apa "cerita" itu. Bagian penting dari "cerita pengguna" adalah kriteria keluar. Kriteria keluar adalah satu atau dua kalimat pendek yang menjelaskan dengan jelas bagaimana dapat ditunjukkan bahwa penyimpanan ini selesai. Idealnya, ini harus menjadi sesuatu yang orang-orang QA Anda katakan "ya, kita bisa menguji untuk itu". Yang penting adalah bahwa para PM harus memahami bahwa cerita pengguna selesai ketika perangkat lunak memenuhi "kriteria keluar". "Tapi kami tidak mau itu" tidak memotongnya. Jika mereka tidak ingin apa yang disampaikan, tetapi itu sesuai dengan kriteria keluar, mereka harus memasukkan cerita baru.

Tentu ada unsur "melatih para PM" di sini. Mereka harus belajar bahwa cerita yang tidak jelas menghasilkan poin cerita yang besar, dan bahwa jika mereka mendefinisikan cerita tersebut dengan ambigu untuk mendapatkan apa yang mereka inginkan, mereka harus melakukannya lagi.

Jelas jika para pemangku kepentingan tidak mengumpulkan informasi yang cukup, maka Anda harus, dan jika Anda harus, maka itu lebih banyak pekerjaan, bukan? Jauh sebelum hari-hari lincah saya, saya berhasil dengan memberikan perkiraan yang sangat besar, dan secara eksplisit mengatakan bahwa perkiraan itu sangat besar untuk memungkinkan risiko yang disebabkan oleh kurangnya informasi. Saya harus mengasumsikan kasus terburuk untuk semua pertanyaan, dan diperkirakan berdasarkan pada kasus terburuk ini. Saya menemukan bahwa manajer lebih bersedia untuk memberikan lebih banyak detail ketika mereka melihatnya mengakibatkan estimasi turun.

Ini bukan game sistem ... ini sangat valid. Jika Anda tidak tahu apakah itu "A" atau "B", Anda memperkirakan berdasarkan yang memberikan perkiraan terbesar untuk menutupi pantat Anda.

Dalam pengalaman saya, banyak perubahan atau proyek yang saya kerjakan menangani hal ini. Custom X menginginkan sesuatu dan mereka memiliki gagasan tentang apa yang mereka inginkan, tetapi mereka hanya memberi Anda sejumlah kecil persyaratan email. Itu terutama karena klien tidak 'tahu persis' apa yang mereka inginkan. Itulah sebabnya sebagian besar pekerjaan departemen layanan klien kami adalah memenuhi tuntutan pelanggan tersebut dan menyaring informasi yang dibutuhkan sambil juga memprediksi apa yang benar-benar diinginkan oleh klien, atau apa yang sebenarnya mereka butuhkan.

Katakanlah klien (untuk saya) menginginkan bagian dari aplikasi web kami untuk mengembalikan mereka daftar semua nomor telepon. Mereka tidak pernah menentukan apakah maksudnya yang fisik, logis, yang ditugaskan untuk seseorang atau lokasi, dll. Mereka hanya menginginkan semua nomor telepon. Sebagai seorang pengembang, saya dapat duduk di sana dan memikirkan selusin atau lebih pertanyaan yang perlu saya tanyakan kepada klien, seperti yang Anda miliki. Tetapi, seperti yang Anda katakan, itu tidak mungkin. Itu sebabnya memiliki departemen layanan klien yang baik yang mengetahui produk dan klien sangat berharga.

Ketika panggilan semacam itu masuk ke perwakilan klien kami, mereka dapat menguraikannya dengan klien, mengetahui apa yang mereka butuhkan untuk meminta mereka menjawab pertanyaan yang tepat. Mereka juga memiliki pemikiran ke depan untuk mengetahui apa yang diminta klien di masa lalu dan mereka cukup tahu tentang sistem yang kami kembangkan sehingga mereka bisa mengatakan ya atau tidak pada sesuatu tanpa bahkan meminta klien.

Tentu, Anda akan memiliki banyak kasus di mana klien masih akan membutuhkan sesuatu yang terlewat oleh Anda dan layanan klien, tetapi itu akan selalu terjadi. Tujuan Anda, dan tujuan layanan klien, harus meminimalkan jeda waktu antara Anda mengembangkan sesuatu dan Anda mendapatkannya kembali dari klien dengan perubahan yang perlu dilakukan. Dan ini hanya berkaitan dengan komunikasi dan pelatihan dengan layanan klien Anda.

Mungkin itu tidak layak bagi Anda seperti di tempat saya sekarang, tetapi memiliki jalur komunikasi dan kepercayaan yang baik dengan perwakilan klien Anda hampir selalu akan membantu Anda sedikit demi sedikit, dan itu akan mengurangi frustrasi Anda dan meningkatkan kepuasan klien. Selain itu, Anda dapat lebih mudah memberikan kerangka waktu untuk proyek Anda daripada mengangkat bahu Anda dan berkata "Saya tidak tahu ruang lingkup penuh proyek, jadi saya tidak tahu berapa lama waktu yang dibutuhkan". Kami mengalami masalah yang sama di sini, dan komunikasi dan pelatihan yang lebih baik adalah yang membantu kami menciptakan tenggat waktu yang wajar dan mencapai mereka secara konsisten.

Pelanggan

Saya ingin mencari produk

Manajer produk Saya telah menganalisis kisah pelanggan dan menghasilkan persyaratan berikut. Setiap persyaratan telah dicatat sebagai kisah pengguna yang terpisah.

• Cari produk
• Sortir hasil
• Saring hasil pencarian

Pengembang Saya telah menerima cerita pengguna dari manajer produk. Saya telah menganalisis setiap kisah pengguna dan menghasilkan daftar tugas untuk setiap kisah pengguna.

• Cari produk
  1. Tugas 1: Perubahan basis data
  2. Tugas 2: Perubahan sisi server
  3. Tugas 3: Perubahan ujung depan

Pelanggan, manajer produk, dan pengembang semuanya adalah pemegang saham dalam proses ini. Mereka semua perlu berkontribusi pada proses analisis sebelum pekerjaan dapat dimulai. Harap dicatat, bahwa ini adalah contoh yang sangat sederhana.

Kisah-kisah pengguna kami dianalisis dan disempurnakan dalam urutan berikut (dengan beberapa variasi tentu saja):

Help Desk -> Pemilik Produk -> Manajer Produk -> Lead Departemen (pengembang senior, qa lead, dll) -> Pengembang

Setelah semua pemangku kepentingan yang relevan berkontribusi pada proses analisis, kita dapat memperkirakan berapa lama waktu yang dibutuhkan untuk menyampaikan cerita. Proses estimasi yang kami ikuti didasarkan pada kecepatan dan keahlian masing-masing pengembang.

Saya tidak mengatakan bahwa ini adalah cara yang benar dalam melakukan sesuatu, tetapi ini bekerja dengan sangat baik dalam organisasi kami.