Bagaimana Anda mengembangkan perangkat lunak tanpa kriteria penerimaan?

Bagaimana Anda secara kolaboratif mengembangkan perangkat lunak dalam tim yang terdiri dari 4-5 pengembang tanpa kriteria penerimaan, tanpa mengetahui apa yang akan diuji oleh penguji dan dengan beberapa (2-3) orang yang bertindak sebagai pemilik produk.

Yang kami miliki hanyalah 'spek' samar dengan beberapa tangkapan layar dan beberapa poin.

Kami telah diberitahu bahwa itu akan mudah sehingga hal-hal ini tidak diperlukan.

Saya bingung bagaimana melanjutkan.

Informasi tambahan

Kami telah diberi tenggat waktu yang sulit.

Pelanggan adalah internal, kami memiliki pemilik produk dalam teori tetapi setidaknya 3 orang menguji perangkat lunak dapat gagal item pekerjaan hanya karena tidak bekerja bagaimana mereka pikir itu harus bekerja dan ada sedikit atau tidak ada transparansi dari apa yang mereka harapkan atau apa yang sebenarnya mereka uji sampai gagal.

pemilik produk tidak tersedia untuk menjawab pertanyaan atau memberikan umpan balik. Tidak ada pertemuan atau panggilan terjadwal yang teratur dengan mereka dan umpan balik bisa memakan waktu berhari-hari.

Saya dapat memahami bahwa kami tidak dapat memiliki spek yang sempurna tetapi saya pikir akan 'normal' untuk memiliki kriteria penerimaan untuk hal-hal yang sebenarnya kami kerjakan di setiap sprint.

Proses berulang akan mencapai ini dengan baik, tanpa spesifikasi rinci.

Cukup buat prototipe samar, minta umpan balik dari pelanggan, buat perubahan berdasarkan umpan balik, dan ulangi proses ini sampai aplikasi selesai.

Apakah pelanggan cukup sabar untuk melakukannya dengan cara ini adalah pertanyaan yang berbeda. Beberapa klien dan pengembang sebenarnya lebih menyukai proses ini; karena pelanggan selalu siap, dia (akhirnya) akan mendapatkan apa yang dia inginkan.

Seharusnya tanpa mengatakan bahwa Anda tidak akan bekerja dengan biaya tetap atau kontrak waktu tetap dengan cara ini.

Jika apa yang Anda katakan itu benar dan speknya tidak cukup baik untuk Anda mulai (dan Anda jujur ​​dalam penilaian ini), saya merekomendasikan pendekatan ini:

1. Baca sketsa dan spek "sketsa" yang telah Anda berikan.
2. Tulis spec Anda sendiri ke level yang cukup untuk Anda dapat kode. Anda mungkin harus membuat banyak tebakan.
3. Tunjukkan spesifikasi Anda kepada pelanggan untuk ditinjau. Catat bagian-bagian yang mereka sukai, dan dapatkan informasi lebih lanjut tentang bagian-bagian yang menurut mereka Anda salah.
4. Ulangi langkah 2 dan 3 sampai Anda dan pelanggan sinkron.
5. Anda sekarang memiliki spesifikasi yang memadai.

Jika pelanggan Anda benar ketika mereka mengatakan "itu akan mudah," maka latihan ini harus menjadi sepotong kue.

Jika pelanggan Anda salah dan sebenarnya ada segala macam gotcha dan kesenjangan dalam persyaratan, spesifikasi rancangan Anda akan dengan cepat menggambarkan masalah dan mengomunikasikan kepada mereka bahwa mereka salah (tanpa Anda perlu mengacungkan jari atau berdebat) karena itu akan tepat di depan mereka dan jelas. Selain itu, spek Anda akan berfungsi sebagai alat diskusi yang hebat untuk menyelesaikan ambiguitas tersebut, dan akan berfungsi sebagai catatan keputusan kunci saat Anda merevisinya dengan umpan balik mereka.

Pemilik produk memberi Anda prototipe; serahkan dia yang lebih baik (sampai Anda selesai)

Sepertinya Anda telah diberikan prototipe kertas untuk memulai proyek. Itu bukan awal yang buruk. Saya sarankan Anda berkomunikasi kembali ke pemilik bisnis dalam bahasa yang sama , dengan memberikan prototipe yang semakin mampu.

Prototipe Anda harus dimulai dengan kertas, beralih ke maket digital, dan kemudian dibangun dengan teknologi "nyata".

Treehouse memiliki panduan yang sangat baik untuk ini, yang menyimpulkan:

Hal yang luar biasa tentang pembuatan prototipe dengan suatu kerangka adalah bahwa prototipe seringkali hanya menjadi situs nyata karena struktur dan gaya sudah ada di tempatnya. Tidak perlu membuat ulang situs dari awal jika akan menggunakan kerangka kerja yang sama.

Anda mungkin ingin memberikan spesifikasi formal juga, terutama jika Anda tetap khawatir akan disalahkan untuk hasil yang buruk. Tetapi Anda mungkin akan mendapatkan lebih banyak umpan balik dari prototipe.

Memenuhi tenggat waktu Anda

Perhatikan bahwa upaya Anda nanti tidak akan menjadi "prototipe" klasik, karena semuanya tidak akan dapat dibuang (atau sebagian tidak akan). Iterasi terakhir, paling mampu, yang Anda selesaikan sebelum batas waktu menjadi hasil pengiriman Anda.

Batas waktu Anda adalah persyaratan yang ditentukan terbaik yang Anda miliki. Miliki sesuatu yang lengkap dan koheren yang dapat Anda berikan tepat waktu.

Berkolaborasi dengan penguji Anda

Jika proses longgar ini adalah hal baru bagi perusahaan Anda, penguji Anda mungkin lebih rugi daripada Anda, dan mungkin mencari bimbingan untuk Anda . Anda harus mendapatkan waktu mereka di awal proses. Biarkan bos mereka tahu Anda mencoba membantu mereka memberikan tes yang berarti tanpa menerima kriteria penerimaan formal.

Cari tahu apakah para penguji memiliki perusahaan yang mereka butuhkan, seperti dokumentasi bukti-pengujian, yang dapat Anda “kembalikan”.

Coba Uji Desain Pertama

Karena Anda tidak memiliki persyaratan formal, membuat kasus uji untuk dikembangkan akan memberikan beberapa struktur.

Buat diri Anda terbiasa dengan Test First Design dan / atau pengembangan yang didorong oleh tes dan berikan panduan kepada penguji Anda tentang proses yang diperlukan. Untuk proyek cepat seperti ini, Anda tidak perlu menjadi ahli dalam prosesnya. Tetapi menggunakan metodologi yang telah terbukti akan mencerminkan baik pada Anda dan penguji Anda.

Tetap berpegang pada standar, terutama untuk UI

Anda tidak memiliki persyaratan tentang tampilan dan nuansa, tetapi Anda memiliki tenggat waktu. Gunakan karya desain orang lain untuk meminimalkan pekerjaan yang perlu Anda lakukan untuk membuat artefak yang terlihat profesional.

Pilih UI standar untuk situs Anda dan jangan sesuaikan kecuali / sampai diarahkan ke. Saya tidak tahu platform apa yang Anda kembangkan, tetapi Bootstrap atau Google Material Design adalah dua contoh.

Berkomunikasi, tetapi jangan mengganggu

Saya sarankan mengirim satu email ke pemilik produk sehari. Hanya kirim lebih dari itu jika keadaan darurat.

Jika Anda memiliki pertanyaan, jelaskan bagaimana Anda akan melanjutkan jika Anda tidak menerima panduan. Sebagai contoh:

Apakah pengguna aplikasi ini perlu mengaksesnya dengan perangkat seluler? Saat ini kami menganggap ini hanya sistem desktop / laptop.

Jangan panik

Saya telah terlibat banyak proyek untuk orang-orang yang tidak tahu istilah "persyaratan." Sebagian besar berhasil. Pemilik produk hands-off memberi Anda kebebasan untuk membangun solusi hebat.

Catatan, beberapa pemilik proyek dalam proyek-proyek ini tidak mungkin untuk menyenangkan dan bersembunyi di balik alasan "Aku terlalu sibuk untuk ..." alasan ketidakmampuan mereka. Tetapi sebagian besar “senang” dengan hasil akhirnya.

Sebuah proyek adalah tindakan mengurangi ketidakpastian sampai kepastian tercapai :

• Selalu ada beberapa tingkat ketidakpastian di awal. Terkadang ada sedikit ambiguitas dalam persyaratan. Terkadang, itu sangat samar. Anda harus berolahraga sebagai bagian dari pekerjaan.
• Kuncinya adalah untuk mengurangi berulang ketidakpastian ini (menggabungkan analisis, desain & implementasi), memperbaiki cerita pengguna & menerapkan sistem Anda.
• Kasus / skenario pengujian, dan kriteria penerimaan harus diklarifikasi dengan cara yang sama. Mereka akan berkontribusi untuk mengurangi ketidakpastian tentang kualitas dan kebenaran (antara lain).
• Pada akhirnya, kepastian yang cukup tercapai: pelanggan mendapatkan produk yang diuji yang sesuai dengan kebutuhannya dan dapat digunakan.

Itulah prinsip elaborasi progresif: persyaratan, kriteria, dan hasil akan diuraikan langkah demi langkah, seperti halnya pemahaman pelanggan tentang harapan dan persyaratannya sendiri melalui keterlibatannya dalam proses pengembangan.

Apakah ini masalah?

Semakin jelas persyaratan awal, semakin tinggi ketidakpastian, dan semakin tinggi waktu yang diperlukan untuk melakukan tugas. Jadi itu hanya masalah siapa yang akan melakukan pekerjaan tambahan dan siapa yang akan membayar biayanya.

Jawaban dari dua pertanyaan ini harus ada dalam kontrak. Atau akan menjadi subjek negosiasi. Dan pelanggan harus menerima keterlibatan tambahan (argumen utama adalah "sampah masuk, buang keluar", meskipun saya akan menyarankan Anda untuk menyajikannya dengan cara yang lebih diplomatis ;-))

" Tidak ada jadwal pertemuan rutin ". Nah, mengapa Anda tidak memulai dengan menjadwalkan pertemuan rutin ? Fakta saja bahwa Anda memiliki banyak pemilik produk menjamin bahwa proyek Anda TIDAK akan mudah, karena masing-masing orang AKAN memiliki persyaratan yang saling bertentangan yang HARUS dibahas secara langsung dengan semua pemangku kepentingan yang hadir.

Selain itu, saya sangat, sangat, sangat merekomendasikan Anda menyimpan catatan keputusan yang terperinci . Paling tidak Anda menuliskan segala sesuatu yang telah diputuskan seseorang, dengan tanggal dan daftar orang yang hadir ketika keputusan itu dibuat. Bahkan lebih baik jika Anda dapat menuliskan MENGAPA sesuatu diputuskan seperti itu. Tidak masalah apakah itu file di PC Anda, halaman di wiki intranet Anda, atau notebook di meja Anda. Log melindungi Anda dan proyek: ketika seorang tester mengatakan beberapa item "gagal", Anda dapat menunjukkan bahwa itu diputuskan seperti itu dengan orang-orang ini, dan itu bukan masalah Anda tetapi di antara mereka dan penguji. Jika ini mengarah pada spesifikasi yang diubah maka tidak apa-apa, tetapi pada titik ini mereka tidak dapat berharap untuk memenuhi tenggat waktu yang mereka pikirkan - atau mereka harus memotong ruang lingkup di tempat lain.

Sebuah proyek tanpa persyaratan yang jelas, kepemimpinan yang longgar, tidak ada definisi selesai (DoD), tidak ada yang mau bertanggung jawab untuk memastikan bahwa Anda memiliki informasi yang Anda butuhkan untuk melakukan pekerjaan Anda secara tepat waktu dan memenuhi tenggat waktu mereka adalah resep untuk proyek kegagalan.

Pengembangan berulang bukan saran yang buruk, tetapi membutuhkan kerja sama yang erat antara pemilik produk dan pengembang. Coba ajak seseorang dengan mengatakan, "Kami tahu kami akan memiliki pertanyaan. Siapa yang dapat secara teratur tersedia untuk memastikan mereka mendapat jawaban sehingga pengiriman proyek tidak tertunda?" Jadwalkan waktu reguler dengan seseorang untuk meninjau kemajuan dan menghilangkan hambatan. Jika mereka tidak menunjukkan, atau menolak, maka tindak lanjuti dengan korespondensi tertulis yang sopan dan penundaan dokumen atau non-tanggapan. Jika pemilik produk tidak tersedia, minta mereka memberikan perwakilan yang bisa.

Juga, ciri khas lain dari pengembangan berulang adalah bahwa perubahan dalam persyaratan mengharuskan perubahan dalam timeline. Anda tidak dapat berkomitmen untuk memenuhi tenggat waktu jika Anda tidak dapat mengembangkan timeline, dan Anda tidak dapat mengembangkan timeline jika Anda tidak memiliki ide bagus tentang apa yang perlu dilakukan. Alih-alih meminta spek secara dogmatis, tinjau spek saat ini, dokumentasikan semua pertanyaan yang Anda atau tim miliki terkait dengan bagaimana fungsinya, jadwalkan waktu dengan pemilik produk untuk membahasnya, dan dokumentasikan jawabannya. Setelah selesai, Anda akan memiliki spesifikasi berdasarkan keputusan mereka, yang kemudian dapat Anda setujui oleh pemilik produk (secara tertulis). Tujuan dari spec adalah untuk menghapus ambiguitas dan membuat DoD, yang persis apa yang bisa diberikan oleh sesi tanya jawab. Jika ada pertentangan dengan spec, jangan menyebutnya spec.

Jangan percaya siapa pun ketika mereka memberi tahu Anda bahwa itu akan mudah . Kadang-kadang itu sesederhana kedengarannya, dan saya mungkin percaya ini jika (dan hanya jika ) saya tahu pemilik produk cukup baik untuk sepenuhnya percaya bahwa persyaratannya benar-benar sesederhana seperti yang mereka katakan, dan spesifikasi saya telah asalkan cukup jelas (jika tidak, saya menjadwalkan sesi tanya jawab dan mendokumentasikannya). Saya telah berada dalam banyak situasi di mana kemudahan dari sudut pandang operasi sangat sulitdari sudut pandang pengembangan, atau Anda pikir Anda benar-benar selesai dan Anda mendengar kata-kata putus asa ("Oh, omong-omong, kami lupa tentang ..."). Contoh ... "Yang harus Anda lakukan adalah membaca file PDF ini dari repositori dokumen," yang, selama pengujian penerimaan berubah menjadi, "Oh, kami lupa bahwa beberapa di antaranya dibaca secara menyamping dengan cara yang sama sekali tidak konsisten, dan beberapa memiliki ukuran halaman yang salah, dan beberapa membutuhkan tiga halaman ini ditambahkan, dan kami membutuhkan mereka semua untuk menampilkan yang sama. Itu sangat mudah untuk diperbaiki, bukan? ".

Intinya adalah, itu mungkin sangat mudah, dan pertemuan singkat dapat mengkonfirmasi hal itu, memungkinkan Anda untuk mendokumentasikan semua asumsi dan mendapatkan konfirmasi bahwa mereka akurat dan benar. Saya merekomendasikan berdiri untuk menghilangkan hambatan Anda harus menulis kode kerja yang memenuhi harapan mereka, karena terlepas dari apakah Anda menginjak kaki, seseorang mungkin akan tidak senang pada akhirnya. Jika Anda gigih menjawab pertanyaan dan membuat seseorang jengkel, mereka akan melupakannya saat Anda memberikan produk yang bagus tepat waktu yang memenuhi persyaratan. Jika Anda gagal mendapatkan klarifikasi dan tidak memberikan, tidak ada yang akan ingat bahwa mereka mengatakan kepada Anda untuk tidak mengganggunya.

Tanpa spec, Anda memiliki kerja tim. Go Agile.

Duduklah bersama PO dan sempurnakan cerita awal kecil. "Kami akan memberikan hanya layar ini, hanya dengan tombol ini yang berbunyi 'bing!'". Pilih beberapa AC. Sampaikan ceritanya. Peragakan cerita. Ternyata tombolnya harus merah. Naikkan bug atau cerita baru. Menghadirkan tombol yang bong dan bang. Dan seterusnya.

Tentukan secara kolaboratif dan berikan irisan vertikal kecil yang sering diperagakan.

Jika pelanggan tidak akan bekerja dengan Anda dengan cara ini, cari jalan keluar.

Saya telah menghabiskan beberapa pekerjaan melakukan proyek seperti yang telah Anda uraikan. Selama PO tahu keputusan desain apa yang Anda buat dan mengapa Anda harus membuatnya, Anda harus baik-baik saja. Jika, di sisi lain, mereka tidak memahami keputusan desain, maka Anda perlu menekan mereka untuk setidaknya dokumen uji penerimaan pengguna tertulis.

Anda memerlukan spesifikasi yang terperinci dan dapat diverifikasi sebelum Anda dapat mulai menulis kode. Itu fakta, dan tidak ada jalan lain.

Jika tidak ada orang lain yang mau menulis spesifikasi itu, maka pengembang harus menulisnya. Jadi Anda mendapatkan spesifikasi yang tidak lengkap. Anda mengubahnya menjadi spesifikasi lengkap (yang berarti "inilah yang akan saya implementasikan kecuali orang lain memberi tahu saya untuk tidak"). Anda memberikan spek itu kepada para pemangku kepentingan dan memberi mereka kesempatan untuk memodifikasi spek. Hanya kesempatan untuk memodifikasi spesifikasi - tidak membatalkannya misalnya dengan mengatakan "Saya tidak suka seperti ini". Pada titik itu, itu spec Anda, atau mereka dapat memasok spec yang berbeda, tetapi tidak menghapus spec.

Mungkin merupakan ide bagus untuk mendapatkan ulasan cepat dari kolega Anda yang mungkin meningkatkan spesifikasi. Tapi bagaimanapun, Anda memiliki spec, Anda menulis kode sesuai, tes penguji sesuai. Dan Anda telah melakukan pekerjaan Anda: Anda memiliki spec dan mengimplementasikannya. Jika spek itu bukan yang diinginkan pelanggan, itu langsung menjadi tanggung jawab pemilik produk atau pelanggan yang tidak mau repot untuk menulis spek yang baik.