Bagaimana cara kerja manajemen persyaratan dalam jangka panjang dengan proyek Agile?

Persyaratan Manajemen dalam jangka pendek untuk proyek Agile sepertinya masalah yang terpecahkan bagi saya.

Dari sudut Scrum, persyaratan baru atau perubahan pada persyaratan yang ada disampaikan melalui Cerita Pengguna. Dan User Stories yang dikelompokkan dalam Epic atau Feature memfasilitasi pengiriman persyaratan yang lebih besar dan lebih kompleks.

Tentu saja, Kisah Pengguna secara teknis bukan dokumen persyaratan. Ini adalah pengelompokan pekerjaan yang dapat dikelola yang memetakan apa yang sering disebut Vertical Slice of Function. Dan ruang lingkup cerita-cerita ini dapat didefinisikan dengan jelas melalui penggunaan Kriteria Penerimaan (AC).

Jadi, meskipun Cerita Pengguna bukan persyaratan formal, menjelajahinya dapat memberi Anda gagasan yang cukup jelas tentang persyaratan yang mendasarinya. Dalam jangka pendek.

Saya katakan dalam jangka pendek karena, ketika sebuah proyek berlangsung, jumlah Cerita Pengguna meningkat. Dengan demikian, menjelajah melalui daftar Cerita yang semakin meningkat untuk menemukan Persyaratan menjadi semakin tidak efisien dari waktu ke waktu.

Masalah ini diperparah ketika Anda mempertimbangkan Cerita Pengguna yang berkembang, menggantikan, atau bahkan meniadakan Cerita sebelumnya.

Sekarang, bayangkan jeda 2 tahun antara iterasi pembangunan pada suatu proyek (stabil dalam produksi). Tim asli sudah pergi dan begitu pula semua pengetahuan mereka.

Jika tim asli tahu ini akan terjadi (misalnya, itu adalah sifat bisnis), lalu tindakan apa yang bisa mereka ambil untuk membantu tim berikutnya?

Tentu, backlog akan memberikan beberapa informasi, tetapi itu hampir tidak dalam bentuk yang mudah dijelajahi.

Jadi, apa yang dapat dilakukan untuk membantu tim selanjutnya memahami keadaan proyek, termasuk mengapa dan bagaimana proyek itu sampai di sana?

Dalam pengalaman saya, hal-hal berikut ini tidak berfungsi:

• Backlog grooming untuk menghapus atau memperbarui Cerita Pengguna sebelumnya sehingga Backlog dapat dibaca sebagai dokumen persyaratan.
• Dokumentasi Sprint di mana anggota tim ditugaskan untuk mendokumentasikan kondisi sistem saat ini.
• Dokumentasi melalui Tes Perilaku . Pendekatan ini adalah satu-satunya yang saya lihat mendekati bekerja. Sayangnya, tes Kode Perilaku adalah korban dari Masalah Penamaan. Meskipun tes mungkin mendokumentasikan sistem dengan baik, membuat tim pengembang yang berfluktuasi untuk menulis tes mereka mengikuti terminologi Domain yang sama, kata-kata, dan gaya hampir tidak mungkin.

Jadi, untuk mengulangi:

Bagaimana cara mengelola Persyaratan proyek Agile dalam jangka panjang?

Bagi saya ini adalah gajah yang tak terucapkan di ruangan dengan proyek Agile: bagaimana Anda mencegahnya berkembang menjadi kekacauan?

Mari kita lihat Manifesto Agile sejenak. Keinginan tangkas:

1. Pengiriman awal dan berkelanjutan
2. Merangkul persyaratan yang berubah
3. Sering mengirimkan perangkat lunak yang berfungsi
4. Pengembang dan pemangku kepentingan bisnis bekerja bersama setiap hari
5. Membangun proyek di sekitar individu yang termotivasi, memberi mereka lingkungan dan dukungan yang mereka butuhkan, dan memercayai mereka untuk menyelesaikan pekerjaan
6. Tatap muka percakapan sebagai mode komunikasi utama
7. Perangkat lunak yang berfungsi sebagai ukuran utama kemajuan
8. Pembangunan berkelanjutan
9. Perhatian terus menerus terhadap keunggulan teknis dan desain yang baik
10. Kesederhanaan - Memaksimalkan pekerjaan yang tidak harus Anda lakukan
11. Secara berkala, tim merefleksikan bagaimana menjadi lebih efektif, kemudian menyesuaikan dan menyesuaikan perilakunya sesuai dengan itu

Saya telah menyoroti empat terakhir. Mengapa? Karena merekalah yang akan mencegah proyek runtuh karena bobotnya sendiri.

Pembangunan berkelanjutan berarti Anda (semoga) memiliki seseorang yang mengawasi keseluruhan proses pengembangan, seseorang yang dapat mengarahkan kapal melampaui pengembangan perangkat lunak sedikit demi sedikit, seseorang yang memiliki visi menyeluruh dari seluruh proyek, seseorang dengan pengetahuan yang tajam arsitektur perangkat lunak, desain sistem, prinsip-prinsip logika bisnis dan ergonomi UI. Seorang arsitek, dengan kata lain.

Arsitek adalah orang yang mengatakan, "Saya tahu Anda memintanya, tetapi jika kami membangun benda lain ini, kami dapat menghindari ketiga fitur lainnya yang hanya membingungkan, dan fokus pada persyaratan inti." Dialah yang memberi tim waktu untuk mengurangi utang teknis. Dialah yang membawa struktur dan organisasi menyeluruh ke proyek. Dialah yang memanggil rapat tempat tim berkumpul dan bertanya, "Bagaimana kita bisa melakukan hal-hal yang lebih baik?"

Dan dialah yang memelihara dokumen persyaratan utama.

Dalam buku Menguasai Proses Persyaratan , penulis berpendapat bahwa ada tiga jenis pelanggan, tiga jenis proyek perangkat lunak: Kelinci, Kuda dan Gajah. Kelinci adalah proyek perangkat lunak kecil yang hanya membutuhkan persyaratan informal; Anda bekerja secara langsung dengan pelanggan dalam sprint kecil, ruang lingkup proyek dibatasi, dan perangkat lunak dilakukan dalam jangka waktu yang relatif singkat. Gajah adalah proyek raksasa yang membutuhkan banyak perencanaan di muka, sejumlah besar dokumentasi, dan cakrawala waktu yang lama. Mereka bisa dibilang tidak gesit, meskipun Anda dapat memecahnya menjadi proyek-proyek kecil yang dapat dibangun menggunakan tangkas.

Ini adalah proyek Kuda yang agak membingungkan dari perspektif lincah. Mereka masih dapat dibangun berulang, Anda masih dapat menggunakan sprint pendek, tetapi tanpa disiplin dalam proses pengumpulan dan perencanaan persyaratan, mereka dapat dengan mudah lari dari rel. Ini adalah proyek-proyek yang dapat mengambil manfaat dari proses pengumpulan persyaratan yang disiplin, dan kemudian adaptasi dan modifikasi yang hati-hati terhadap persyaratan-persyaratan tersebut seiring pertumbuhan proyek, sambil tetap mempertahankan visi menyeluruh untuk keseluruhan proyek.

Dari sudut pandang pribadi, saya bekerja dengan tim kecil yang terdiri dari sekitar selusin pengembang. Pada saat tertentu, kami dapat mengerjakan tiga proyek perangkat lunak secara bersamaan, mulai dari beberapa ribu baris kode hingga lebih dari 100.000. Pelanggan kami mengira mereka kelinci, tapi mereka benar-benar kuda. Pelanggan bertunangan, tetapi tidak setiap hari.

Sejauh ini, area terlemah kami adalah mengumpulkan persyaratan spesifik, dapat diuji, dapat diukur dan mengelola harapan pelanggan relatif terhadap ruang lingkup proyek. Tapi kami sedang mengusahakannya.

Pertanyaannya tidak sepenuhnya jelas tetapi sepertinya Anda prihatin dengan persyaratan penelusuran . Satu ide yang cenderung hilang dalam Agile dalam pengalaman saya adalah bahwa persyaratan bisnis adalah apa yang pelanggan inginkan untuk dilakukan sistem, sementara kisah pengguna adalah persyaratan fungsional yang menyatakan bagaimana sistem bekerja. "Sebagai pengguna, saya ingin bisa X." Tapi itu dilakukan untuk memenuhi persyaratan, yang mungkin hilang dalam kisah pengguna.

Apa yang berfungsi dengan baik dalam pengalaman saya adalah menghubungkan persyaratan bisnis dan cerita pengguna di kedua arah. BR # 1 dapat diwujudkan dengan cerita A dan B. Cerita C mungkin mencakup BRs # 2 dan # 3. Letakkan ini di pelacak proyek Anda, spreadsheet, apa pun yang Anda gunakan.

Jangka panjang, ini membantu menghubungkan apa yang diminta pelanggan (BR) dengan apa yang dilakukan sistem (cerita) untuk mencapai persyaratan tersebut. Ini harus menjadi dokumentasi yang cukup minimal yang tidak sulit untuk dipelihara, sesuai dengan pola pikir Agile yang tidak menghasilkan dokumentasi yang tidak diperlukan siapa pun dan merupakan tugas yang harus selalu diperbarui.

Ini juga menyediakan cara bagi anggota proyek baru untuk mempercepat karena mereka memiliki sesuatu untuk ditinjau untuk mendapatkan sejarah di balik mengapa perangkat lunak melakukan apa yang dilakukannya.

Saya sebenarnya bekerja di proyek kanban maintenace dari sebuah toko web besar di mana pengembang asli tidak tersedia lagi.

setiap direktori pengguna / persyaratan / perbaikan bug memiliki nomor tiket dan setiap perubahan kode-sumber ditautkan ke nomor tiket di bidang kode-kontrol-komentar.

sourcecontrol-checkin-s (svn) secara otomatis memperbarui tiket yang sesuai sehingga dalam tiket saya memiliki tautan ke semua perubahan-perubahan sourceconrtol.

Jika modul / fungsi baru diimplementasikan, ada juga nomor tiket dalam kode sumber.

Dalam sistem tiket (redmine), tiket dihubungkan antara satu sama lain sebagai (duplikat, bug, penyempurnaan, ....)

sehingga Anda dapat mengikuti tiket dan melihat perubahan persyaratan dari waktu ke waktu.

Contoh: saya harus mengejar sesuatu di "orderConfirmation-Web-page". Dalam kode sumber halaman saya melihat komentar: 'dibuat untuk "# 4711"' sehingga saya dapat menghubungkan tiket baru saya ke tiket lama "4711" atau salah satu penggantinya.

Secara pribadi, saya membuang cerita pengguna sebagai sumber dokumentasi tentang apa yang dapat dilakukan sistem. Kecuali jika langkah aktif telah diambil untuk membuat dokumentasi (yang telah kami lakukan untuk beberapa klien kami yang lebih tradisional), basis aplikasi adalah dokumentasi terbaik.

Meskipun, itu bukan hal baru.

Jika Anda menggunakan Agile versi yang lebih diskalakan (seperti SAFe ), Anda akan memiliki jaminan simpanan lain yang bukan jaminan simpanan implementasi. Pada dasarnya terlihat seperti ini:

1. Portofolio Backlog (Perencanaan strategis epos dan anggaran)
2. Backlog Program / Rilis (Fitur dan Epik)
3. Backlog Proyek / Tim (Kisah, Paku, Bug)

Saya tidak akan merekomendasikan mendokumentasikan di tingkat Tim Backlog. Ini terlalu terperinci dan jarang ada yang mau pergi ke tingkat detail. Belum lagi bahwa mungkin ada cerita di dalam Rilis yang bertentangan dengan cerita sebelumnya dalam tumpukan Tim.

Sebagai gantinya, saya akan merekomendasikan bekerja di tingkat Backlog Rilis Anda untuk memberikan dokumentasi tingkat Rilis. Cerita-cerita ini jarang meledak sekali ditugaskan untuk rilis tertentu, dan bisa menjadi cara yang stabil dan cepat untuk meninjau apa yang sedang dikerjakan dalam rilis yang diberikan.