Cerita pengguna terlalu tinggi dan konseptual, manajemen mengharapkan pengembang untuk mengisi kekosongan

Saya bekerja di perusahaan yang sangat brilian dengan niat melakukan XP. Komunikasi yang baik dan manajemen terbuka untuk diskusi yang konstruktif tetapi karena kendala waktu yang mendesak, beberapa hal tertentu dianggap terlalu RUP untuk didiskusikan.

Saat ini saya sedikit bermasalah dengan volume perubahan yang menjadi kebutuhan saat mengimplementasikan cerita. Saya percaya banyak dari penemuan ini (yang tentu saja membutuhkan waktu dan usaha) adalah tanggung jawab penulis cerita (pelanggan, pengguna akhir dan pemilik produk) dan bukan pengembang. Singkatnya, cerita pengguna terlalu konseptual dan hanya menyampaikan maksud yang mendasarinya tetapi kurang detail (khususnya pra-kondisi dan pasca-kondisi, relevansi dengan cerita lain, dependensi, dan yang serupa). Pengembang diharapkan untuk mengisi kekosongan atas kebijakannya sendiri berdasarkan kebajikan pengembang XP menjadi desainer dan analis pada saat yang sama. Masalahnya adalah banyak dari kekosongan ini ditemukan setelah beberapa asumsi yang salah masuk ke dalam waktu dan kode evaluasi karena melihat kerumitan tambahan muncul daripada yang diperkirakan sebelumnya. Bahkan kemudian menemukan hal yang benar untuk mengisi membutuhkan waktu yang - untuk berbagai tingkatan - dianggap sebagai penyimpangan dari estimasi awal.

Saya mencari cara yang konstruktif untuk menyampaikan implikasi ini kepada manajemen dengan cara yang tidak akan menjadikan saya sebagai seseorang yang mencoba mempersulit hal-hal yang tidak perlu. Saya baru dan sampai sekarang saya belum membangun banyak kredibilitas.

Wawasan Anda dipersilahkan.

Terkait erat dan entah bagaimana memberikan jawaban: Seberapa banyak detail tentang kisah pengguna yang bisa diharapkan pengembang?

Triknya adalah jangan sampai ada yang kosong. Caranya adalah dengan mengisi kekosongan tersebut sedini mungkin dalam proses pembangunan.

Anda benar bahwa, jika pengembang membuat asumsi, mereka akan selalu salah dan akan memakan waktu untuk mengembangkan kembali perangkat lunak nanti. Tapi, sama-sama, jika pebisnis diharapkan untuk melakukan desain penuh di muka ketika mereka tidak benar-benar tahu apa yang mereka inginkan, hal yang sama akan terjadi.

Ini adalah bagian besar dari pekerjaan pengembang untuk mencari tahu apa yang diinginkan pelanggan, ketika mereka sering tidak benar-benar tahu.

Pertama, ajukan pertanyaan. Jika jawaban yang Anda dapatkan tampak tidak memuaskan, buatlah prototipe. Tunjukkan pada pelanggan apa yang mereka minta, dan biarkan mereka memberi tahu Anda apa yang sebenarnya tidak mereka inginkan. Mulailah dengan prototipe kertas, kemudian pindah ke yang berbasis HTML, tanpa kode di belakangnya. Kemudian lakukan pengembangan terkecil yang Anda butuhkan untuk menghasilkan produk yang hampir berfungsi dan tunjukkan pada mereka. Biarkan bit yang rumit selambat-lambatnya dalam proses yang Anda bisa.

Ini mungkin terdengar memakan waktu, tetapi jika dibandingkan dengan membangun kembali produk yang seharusnya sudah jadi, itu tidak.

Juga, simpan cerita sekecil mungkin. Selalu, apa yang diinginkan bisnis adalah sebuah epik, sesuatu yang dapat dipecah menjadi banyak hasil. Ini lebih baik karena Anda tidak akan berkembang terlalu banyak ketika mereka melihat kandidat rilis final dan berteriak "Oh tidak, itu benar-benar bukan yang kami cari."

Bahkan kemudian menemukan hal yang benar untuk mengisi membutuhkan waktu yang - untuk berbagai tingkatan - dianggap sebagai penyimpangan dari estimasi awal.

Itu tidak terdengar sangat "XP" ish bagi saya.

Saya sama sekali bukan ahli XP, tetapi AFAIK ide XP adalah untuk menyesuaikan spesifikasi dan estimasi Anda secara terus menerus setiap kali Anda mendapat umpan balik dari proses. Dan prosesnya adalah "menganalisis sedikit - mendesain sedikit - kode sedikit - menguji sedikit - dan kemudian mendapatkan umpan balik pengguna untuk memperbaiki asumsi yang salah Anda sedini mungkin. Anda juga dapat mencoba untuk mendapatkan umpan balik pengguna lebih awal , misalnya , setelah merancang beberapa bagian dari perangkat lunak Anda (seperti UI), pada selembar kertas atau papan tulis dan mendiskusikannya dengan pengguna atau pelanggan . Saya tidak berpikir "cara XP" melarang pendekatan semacam itu hanya karena memiliki " cerita pengguna ".

Berikut ini adalah artikel yang bagus tentang cara mendapatkan umpan balik lebih awal dengan menggunakan spesifikasi. Saya pikir pemikiran seperti ini adalah "metodologi" yang independen, dan argumen yang disajikan di sana akan membantu Anda dengan debat Anda dengan manajemen.

Untuk meringkas Anda berada dalam situasi berikut:

1. Kamu adalah baru.
2. Proyek (saya anggap Anda berbicara tentang proyek yang sedang berjalan) memiliki kendala waktu yang mendesak.
3. Pengembang diharapkan mengisi kekosongan atas kebijakannya sendiri.
4. Perusahaan tempat Anda bekerja bermaksud untuk berlatih XP. Namun, kisah pengguna tampaknya tidak diterapkan dengan cara yang sesuai dengan metodologi XP. Di sisi lain " Pengembang diharapkan untuk mengisi kekosongan atas kebijakannya sendiri ".

Pikirkan poin 4: Pendapat saya adalah bahwa praktik gesit harus disesuaikan dengan kebutuhan dan budaya perusahaan / tim (bukan sebaliknya). Identifikasi di mana perusahaan berpegang pada metodologi XP dan di mana ia menyimpang. Ini adalah dasar untuk pendekatan konstruktif untuk masalah Anda.

Karena 1 dan 2 Anda saat ini tidak dalam posisi yang baik untuk mempertanyakan apakah perusahaan menerapkan XP dengan cara yang masuk akal. Memulai diskusi dengan manajemen kemungkinan besar akan menjadikan Anda sebagai seseorang yang " menyulitkan ". Namun Anda dapat mulai mendiskusikan kekhawatiran Anda dengan sesama pengembang. Mungkin Anda akan menemukan beberapa pengembang yang memikirkan cara Anda melakukannya. Mungkin ada pengembang senior yang kemudian akan menyampaikan kekhawatiran Anda kepada manajemen. Tetapi jangan berharap bahwa hal-hal akan berubah dengan cepat, terutama tidak dalam proyek saat ini. Namun proyek ini akan memberi Anda peluang bagus untuk mengumpulkan lebih banyak data yang menambah substansi pada pendekatan konstruktif.

Sekarang ke poin 3: Saya pikir cerita pengguna yang baik ditulis secara kolaboratif oleh pelanggan / pengguna akhir / pemilik produk dan pengembang. Tunjukkan beberapa inisiatif: Carilah beberapa kesempatan untuk secara langsung bertanya kepada penulis cerita pengguna. Jika ini tidak memungkinkan, tanyakan beberapa pengembang senior atau manajemen bagaimana menangani pertanyaan terbuka yang harus dijawab oleh penulis cerita pengguna. Mungkin Anda setidaknya dapat memiliki korespondensi tertulis. Karena Anda perlu mengisi kekosongan atas kebijakan Anda sendiri, maka pilihan Anda haruslah untuk secara aktif melibatkan pelanggan / pengguna akhir / pemilik produk.

Pada titik tertentu Anda telah membuat cukup pemikiran dan pengamatan tentang bagaimana perusahaan Anda menerapkan XP (atau praktik tangkas pada umumnya). Mungkin beberapa waktu telah berlalu dan Anda tidak lagi dianggap sebagai pendeta. Mungkin keterlibatan aktif Anda dengan pelanggan telah menunjukkan beberapa efek positif. Mungkin proyek selanjutnya sudah dimulai. Mungkin Anda juga sudah memiliki cadangan dari develeopers lain. Mungkin Anda mengetahui bahwa cara kerjanya tidak buruk sama sekali. Intinya adalah bahwa kemudian Anda akan memiliki ide-ide yang cukup untuk menyampaikan kekhawatiran Anda kepada manajemen, berdasarkan pengalaman nyata dan data dalam perusahaan Anda.

Terus terang, kisah pengguna seharusnya tidak memiliki banyak detail. "Saya ingin perangkat lunak melakukan X, untuk memenuhi kebutuhan bisnis Y" harus cukup. Lagipula, Anda tidak ingin para pebisnis mendikte cara melakukan itu - Anda adalah pakar perangkat lunak dan praktik terbaik di dalamnya.

Yang mengatakan, para pengembang juga perlu bertanya : "bagaimana Anda mengharapkan ini berfungsi?", "Apa yang terjadi ketika itu berinteraksi dengan fitur Z?". Pengembang tidak membuat persyaratan, mereka membuat implementasi.

Ini juga terdengar seolah-olah ada terlalu banyak kesenjangan antara implementasi dan evaluasi. Stakeholder harus melihat prototipe, kode setengah jadi setiap beberapa hari. Itu memungkinkan Anda mendapatkan umpan balik sebelum terlalu jauh ke dalam gulma.

Jika Anda diminta untuk memperkirakan cerita yang tampaknya tidak lengkap untuk Anda, buatlah diketahui bahwa Anda memiliki pertanyaan tentang cerita tersebut dan bahwa Anda tidak dapat memberikan estimasi yang tepat sebelum pertanyaan-pertanyaan itu dijawab.

Kemudian, ajukan pertanyaan Anda dan pastikan jawabannya menjadi bagian dari cerita.

Jika Anda dipaksa untuk memberikan estimasi bahkan ketika pertanyaan Anda tidak (semua) dijawab, Anda dapat memilih untuk menolak memberikan estimasi atau dengan jelas menunjukkan bahwa Anda mengasumsikan hasil terburuk yang mungkin terjadi untuk sisa kosong dalam estimasi Anda (yang mungkin akan membuat estimasi Anda lebih tinggi).

Apa yang Anda lakukan bukanlah cara pengembangan yang gesit. Sebaliknya, Anda bekerja dengan persyaratan kualitas rendah. Adalah salah bahwa cara pengembangan yang gesit bukan untuk menentukan persyaratan.

Sebagai gantinya, mereka perlu menentukan sebanyak mungkin pada awalnya, dan jika perlu diubah nanti. Kemudian Anda membagi pekerjaan Anda menjadi beberapa bagian dan menerapkannya dalam iterasi. Setelah setiap iterasi, Anda memiliki sesuatu yang selesai.

Perbedaan pengembangan air terjun, dalam pengembangan air terjun, semuanya diimplementasikan dengan persyaratan awal, dan diubah pada akhirnya.

Sepertinya pengembang sepenuhnya dihapus dari pembuatan cerita pengguna. Apakah Anda berharap hanya dapat membacanya seperti spesifikasi terperinci dan membuatnya dengan benar saat pertama kali? Jika Anda bisa melakukan itu, Anda tidak perlu XP atau metodologi tangkas lainnya.

Seseorang harus bertanya jika ceritanya terlalu kabur. Di mana Pengujian Penerimaan terjadi?

Cerita pengguna dimaksudkan untuk berubah. Anda harus menghadapinya.

Meskipun seorang pengembang bisa menulis cerita / persyaratan rinci saya belum melihat banyak yang pandai. kami pandai menunjukkan masalah, menyarankan aliran yang lebih baik tetapi sebagai masukan untuk kasus yang sudah ditulis dengan baik.

Telah bekerja pada produk baru dan yang sudah ada dan dengan keduanya memiliki kasus di mana persyaratan di mana hanya 5-baris dan kami diharapkan untuk mengisi kekosongan dan membuat 'pemahaman' atau dokumen yang lebih rumit.

Proyek bergerak jauh lebih baik daripada kami memiliki orang layanan profesional kami sendiri yang membantu dengan ini (atau dalam satu kasus seorang VP yang melompat karena tidak ada orang lain yang tersedia). Apa pun itu buang-buang waktu untuk berkembang (kecuali jika tidak ada umpan balik yang kembali dan tenggat waktu tidak berubah). jadi saran saya: minta rincian lebih lanjut, berikan lebih banyak, minta umpan balik terikat waktu untuk asumsi dan dokumentasi Anda dan nyatakan bahwa itu risiko bahwa akan ada pengerjaan ulang dan keterlambatan jika Anda tidak mendapatkan informasi ini berdasarkan x tanggal.

Terlepas dari metodologi pengembangan, jika apa pun yang Anda gunakan untuk menentukan persyaratan membuat pengembang membuat asumsi, itu perlu ditendang kembali ke sisi bisnis. Saya sering memiliki ide yang bagus tentang jawaban apa yang saya inginkan sehingga saya membalasnya seperti ini:

XYZ tidak jelas bagi saya. Apakah ini berarti ABC? Atau apakah saya melewatkan sesuatu? (Anggap XYZ adalah persyaratannya, anggap ABC adalah asumsi yang ingin saya buat sebagai pengembang)

Butuh jauh lebih sedikit waktu untuk menyelesaikan masalah sebelum Anda membuat asumsi buruk daripada mengulang. Pengembang yang membuat tebakan tentang persyaratan tanpa mendapatkan konfirmasi bahwa tebakan mereka benar cenderung menjadi pengembang yang buruk dan mereka menghabiskan banyak uang untuk perusahaan mereka. Jika manajer yang buruk tidak akan membiarkan Anda menendang balik, maka jelaskan kepadanya betapa jauh lebih mahal dalam hal waktu dan uang untuk melakukan kesalahan. Jika dia masih bersikeras, maka lakukan apa yang dia katakan dan ketika itu gagal UAT, waktu berikutnya Anda ingin menendang sesuatu kembali, ingatkan dia betapa mahal itu saat dia tidak akan membiarkan Anda. Jika dia masih tidak mau mendengarkan, cari bos yang lebih baik.

Nilai lain dari menendang balik adalah bahwa, secara bertahap, bisnis akan mempelajari apa yang Anda butuhkan dan memberi Anda persyaratan yang lebih baik.

Sebagai pengembang,

Saya perlu sepenuhnya memahami secara spesifik kisah pengguna,

sehingga saya dapat dengan yakin memperkirakan dan mengimplementasikannya.

Dengan kata lain, Anda harus mengajukan pertanyaan sampai Anda memahami secara spesifik cerita tersebut. Ini dilakukan dalam perencanaan iterasi dan bertindak sebagai titik keputusan: jika Anda tidak dapat memperkirakannya, Anda tidak dapat membangunnya.