Apakah kurangnya persyaratan fungsional gesit?

Saat ini semua orang ingin gesit. Di setiap tim tempat saya bekerja, bentuk lincah berbeda. Beberapa hal biasa - seperti pengaturan atau perencanaan harian, tetapi bagian lain sangat bervariasi.

Di tim saya saat ini ada satu detail yang saya anggap mengganggu. Kurangnya persyaratan fungsional. Tidak hanya tidak ada bentuk harapan tertulis tetapi juga dalam tugas-tugas itu agak samar-samar mendefinisikan apa yang perlu dilakukan.

Tujuan proyek adalah untuk menulis ulang sistem lama menggunakan teknologi baru. Sistem lama juga tidak memiliki dokumentasi yang masuk akal. Yang pasti sampai saat ini tidak ada. Deskripsi persyaratan pemilik bisnis - mari kita lakukan dalam implementasi baru dengan cara yang sama seperti yang lama. Tampaknya masuk akal tetapi tidak. Sistem lama adalah semacam kode spageti dan mengekstraksi persyaratan bisnis dari itu mahal. Tampaknya situasi memengaruhi perencanaan secara negatif. Pasti itu rentan terhadap kesalahan dan bug dalam implementasi baru (menghilangkan beberapa detail).

Karena itu saya berpikir - apakah benar-benar gesit untuk tidak memiliki persyaratan bisnis jika menulis ulang sistem lama?

Apakah persyaratan fungsional kurang atau tidak gesit, itu adalah resep untuk bencana. Anda tidak dapat membangun kembali suatu sistem ketika Anda tidak tahu bagaimana sistem itu bekerja.

Anda perlu memberi tahu pemilik bisnis bahwa Anda tidak tahu cara kerja sistem lama.

Pilihan terbaik Anda adalah bekerja dengan pemilik bisnis Anda atau beberapa pengguna berpengalaman untuk memahami proses bisnis yang sedang dimainkan, dan mengembangkan tes penerimaan Anda sendiri. Jika Anda dapat bekerja dengan beberapa pengguna akhir, Anda mungkin mendapatkan umpan balik lebih lanjut tentang cara kerja sistem lama.

Jika gagal, Anda harus melakukan beberapa pengujian eksplorasi di lingkungan non-produksi untuk memenuhi persyaratan Anda sendiri. Sering kali ketika pemilik bisnis mengatakan "membuatnya bekerja seperti yang lama" mereka dibatasi pada waktu, dan tidak dapat membantu Anda seperti pemilik bisnis seharusnya. Anda memerlukan keahlian beberapa pengguna berpengalaman, atau banyak pengujian manual di pihak Anda untuk memahami cara kerja sistem lama.

Beri tahu pemilik bisnis bahwa kurangnya persyaratan dan pemahaman tentang sistem lama akan sangat meningkatkan waktu yang diperlukan untuk membangunnya kembali - sekitar tiga kali lipat atau lebih besar. Dihadapkan dengan peningkatan waktu dan biaya, pemilik bisnis akan memberi Anda keahlian yang diperlukan untuk mengumpulkan persyaratan lebih cepat, atau memutuskan penulisan ulang tidak layak secara ekonomi saat ini.

Anda akan mendapatkan salah satu dari yang berikut:

• Persyaratan yang tepat dan siklus pengembangan yang lebih cepat
• Saatnya mengumpulkan persyaratan dan membangun kembali perangkat lunak
• Sebuah proyek baru yang tidak akan berakhir menjadi tanda hitam dalam karier Anda

Agile tidak mengubah kebutuhan akan persyaratan fungsional, tetapi pada umumnya mengubah cara Anda mengumpulkannya . Cara non-agile adalah bagi seseorang untuk melalui proses panjang kemudian memberi Anda semacam dokumen yang berisi semua persyaratan untuk sistem.

Cara lincah untuk mengumpulkan persyaratan adalah bekerja bersama untuk menentukan persyaratan untuk peningkatan kecil dari sistem, membangunnya, kemudian mendapatkan umpan balik dan melakukan penambahan berikutnya. Dalam situasi Anda di mana Anda mengalami kesulitan membuat pemilik bisnis untuk memulai proses, saya akan mulai dengan menghabiskan setengah hari menjelajahi bagian dari sistem lama yang ingin Anda kerjakan selanjutnya, dan menghasilkan daftar pertanyaan tentang persyaratan.

Kemudian duduklah bersama pemilik bisnis Anda dan ajukan pertanyaan kepada mereka. Beberapa pertanyaan akan mudah dijawab oleh mereka, ada yang lebih mudah bagi Anda untuk menjawab dengan melihat kode, dan ada pula yang sulit dijawab dengan cara apa pun. Pecahkan pertanyaan-pertanyaan sulit menjadi potongan-potongan kecil sampai Anda mencapai sesuatu yang dapat dijawab.

Tujuannya adalah untuk mendapatkan cukup dari pertanyaan Anda yang dijawab untuk membangun sesuatu, mendapatkan umpan balik, dan memulai kembali proses. Ingat, semakin kecil perubahan Anda dan semakin pendek siklus umpan balik Anda, semakin sedikit masalah besar jika Anda membangun hal yang salah.

Menangkap persyaratan adalah bagian penting dari setiap proyek perangkat lunak (sukses). Tetapi menulis spesifikasi persyaratan tidak.

• Pendekatan dokumentasi-sentris dapat berakhir seperti permainan Whispers Cina: ahli subjek menyuarakan persyaratan, analis menuliskannya, dev mencoba menulis sesuatu yang sesuai dengan deskripsi analis, pengguna akhir bingung karena perangkat lunak tidak dapat memecahkan masalah mereka.

  Teknik lincah menunjukkan bahwa pengembang harus mengumpulkan persyaratan langsung dari para ahli materi pelajaran, biasanya pengguna akhir. Ada berbagai teknik untuk melakukan ini, misalnya dengan berbicara melalui skenario contoh dengan SME. Pengembang sangat piawai dalam menemukan case edge dan meminta SME untuk mengklarifikasi bagaimana seharusnya software berperilaku pada case edge.

• Alih-alih mengumpulkan semua persyaratan di muka (dan karenanya berisiko kesalahpahaman besar), tim tangkas kemungkinan akan mulai dengan sepotong kecil persyaratan, membangun prototipe, dan menggunakannya untuk mengumpulkan umpan balik untuk iterasi berikutnya.

• Ketika pemahaman tentang persyaratan bergeser dari waktu ke waktu, spesifikasi persyaratan statis akan ketinggalan zaman. Bagaimana ini bisa dicegah?

  Dengan menyatakan persyaratan sebagai pengujian yang dapat dijalankan. Ternyata "spesifikasi yang dapat dibaca" dan "tes yang dapat dijalankan" bukan konsep eksklusif, tetapi dapat menjadi satu dan dokumen yang sama. Misalnya Mentimun dan ide-ide lain keluar dari ruang BDD bisa sangat membantu di sini.

Jika Anda menulis ulang sistem yang lama, sistem yang asli dapat menjadi sumber persyaratan yang bagus. Tetapi aspek mana yang relevan? Apakah fitur ceruknya bahkan digunakan? Bug mana yang harus diimplementasikan kembali untuk kompatibilitas? Biasanya tidak ada solusi untuk berbicara dengan pengguna akhir.

Memiliki sistem kerja yang baik juga dapat sangat membantu untuk menguji perangkat lunak baru, tetapi itu tidak terkait dengan masalah lincah.

Perhatikan bahwa proyek dengan ruang lingkup tetap, waktu tetap dengan tenggat waktu menjulang adalah kebalikan dari gesit. Pendekatan lincah yang normal adalah memilih sepotong fungsionalitas dan pertama memberikan itu, kemudian beralih. Hal-hal terpenting dilakukan terlebih dahulu, hal-hal yang kurang penting di kemudian hari (atau tidak pernah). Jika semuanya penting dan HARUS dilakukan SECEPATNYA, maka tidak ada yang penting dan proyek tidak mungkin memberikan apa pun.

Dalam situasi Anda, kurangnya persyaratan bukanlah fitur yang gesit tetapi lebih merupakan kasus disfungsi organisasi. Jika Anda ingin proyek berhasil, Anda perlu menemukan cara untuk memotong disfungsi ini. Misalnya mendesak pemilik bisnis untuk tidak menulis dokumen persyaratan lengkap, tetapi cobalah untuk mengatur pertemuan di mana mereka menjelaskan persyaratan mereka untuk fitur yang paling penting. Anda dapat melihat sistem lama untuk detailnya. Kemudian implementasikan fitur itu, dan lakukan iterate.

Begini cara kami melakukannya. Kami berbicara dengan pemilik. Kami berbicara dengan Manajer. Kami berbicara dengan pengguna yang melakukan pekerjaan. Apa yang kami temukan dengan duduk di meja pengguna dan menonton (dan mengajukan pertanyaan) sangat berguna. Manajer tahu pengguna mana yang harus kami duduki.

Kami menemukan bahwa beberapa bagian dari sistem bekerja dengan sangat baik, dan kami dapat dengan mudah menulis persyaratan yang cukup untuk memulai merancang dan mengkode dan menguji kasus dan sebagainya, tetapi bagian lain memiliki beberapa solusi buruk yang digunakan oleh pengguna di lantai, yang tidak disadari oleh para manajer dan pemilik. Untuk bagian-bagian dari sistem lama ini, kami kembali ke bisnis dan berbicara tentang alur kerja dan proses sebentar sebelum kami dapat menentukan tugas-tugas yang lebih kecil dan dengan demikian dapat memecahnya menjadi unit-unit yang diinginkan oleh metode tangkas kami.

Jadi, sementara Agile dapat dengan cepat melepas beberapa bagian dari sistem, yang lain harus memiliki sedikit pemikiran dan dokumentasi sebelum kami dapat memulai.

Mengumpulkan persyaratan dalam kerangka Agile dan tidak ada yang menyebutkan Kisah Pengguna? Kisah pengguna pada dasarnya adalah definisi tingkat tinggi dari apa yang harus mampu dilakukan oleh perangkat lunak. Biasanya, umpan balik atau permintaan apa pun yang berasal dari bisnis atau pengguna akhir dapat ditulis sebagai kisah pengguna. ... Anda dapat menganggap kriteria penerimaan sebagai persyaratan fungsional yang mendukung cerita pengguna.

Pertanyaan ini mengisyaratkan apa yang salah dengan gerakan lincah. Bukan salah orang yang mengajukan pertanyaan; Saya jatuh ke dalam perangkap ini sepanjang waktu karena bertahun-tahun kehidupan perusahaan melatih saya untuk melakukannya.

Perangkap yang saya bicarakan adalah berpikir bahwa ada cara Agile yang ditentukan dan benar untuk melakukan sesuatu. Ini mungkin karena orang berpikir Agile ada. Anda tidak bisa melakukan Agile lebih dari yang Anda bisa lakukan Pragmatis.

Tidak memiliki "spesifikasi fungsional" atau apa pun, kedengarannya mengkhawatirkan, tetapi mungkin tidak. Berapa banyak detail yang perlu Anda mulai? Keamanan dan kinerja adalah yang jelas yang dikenal di muka dan berlaku sepanjang jalan. Jika tidak, apakah itu mesin Harga Opsi atau aplikasi jam?

Apakah akan ada rilis terus-menerus, diskusi, belajar, kembali dan mengubah perangkat lunak? Apakah Anda membuat perangkat lunak atau perangkat keras?

Pengembang yang bekerja dalam proses air terjun sering tidak terlibat sampai tahap selanjutnya, yang merupakan masalah. Melibatkan mereka lebih awal atau dari awal berarti mereka mengetahui hal-hal yang tidak jelas, tidak terdefinisi dan setengah matang, yang tampaknya mengecewakan pengembang lama, ketika sebenarnya bagian dari pekerjaan mereka adalah untuk mengajukan pertanyaan, seperti "apa persyaratan fungsional untuk hal ini yang akan kita bangun? "

Mengidentifikasi lubang dalam rencana itu bukan tentang menemukan kesalahan, ini hanya pengembangan perangkat lunak.

Untuk alasan ini, saya suka jawaban Guy.