Agile, Waterfall dan perubahan persyaratan

Adakah yang memiliki masalah proyek yang didefinisikan sebagai 'Agile' yang dikuasai oleh perubahan persyaratan? Saya bekerja pada proyek pengembangan yang dijalankan dalam 4 minggu Sprint tetapi selalu ada perubahan di antara Sprint ini. Apakah masih didefinisikan sebagai Agile? Saya merasa ini semacam proses Agile sub - Persyaratan proses Agile harus didefinisikan pada awal sprint dan ditinjau menjelang akhir. Apakah saya benar dalam hal ini? Tolong beri tahu saya pengalaman Anda dalam hal ini.

Persyaratan proses Agile harus didefinisikan pada awal sprint dan ditinjau ke arahnya. Apakah saya benar dalam hal ini?

Tidak, ini tergantung pada sifat proyek (dan prosesnya).

Ada beberapa model pengembangan lincah di mana persyaratan dimaksudkan untuk diperbaiki selama sprint, dan hanya boleh berubah untuk sprint berikutnya (contoh yang menonjol adalah Scrum).

Namun, ada juga proses di mana perubahan dapat terjadi hampir kapan saja (selama pelanggan menerima penundaan dan pekerjaan tambahan yang disebabkan oleh perubahan itu). Kanban sering digunakan untuk mengelola alur kerja ini (meskipun Kanban juga dapat dikombinasikan dengan Scrum).

Model mana yang Anda ikuti tergantung pada detail masing-masing proyek.

Jadi ya, jika pelanggan merasa mereka membutuhkan kemungkinan untuk terus mengubah persyaratan, maka proses yang gesit dapat mengakomodasi hal ini. Namun, pelanggan harus menyadari konsekuensi dari perubahan yang konstan, dan harus memahami bahwa mereka akan memperlambat proyek.

Ini bermuara pada prinsip-prinsip dari manifesto tangkas - "Individu dan interaksi atas proses dan alat", dan "Menanggapi perubahan setelah mengikuti rencana".

Saya pikir pertanyaan yang harus Anda tanyakan adalah: Mengapa Anda dibanjiri oleh perubahan persyaratan? Penyebab umum meliputi:

• Pengembang tidak memiliki (cukup) kontak dengan pengguna akhir sehingga mereka tidak dapat memahami kebutuhan pengguna. Alih-alih mereka memperlakukan persyaratan seperti kubus Rubik yang abstrak - mereka mengikuti surat persyaratan tersebut tanpa mencoba memahami semangat mereka
• Seseorang (mis. Dari pemasaran) menambahkan persyaratan yang tidak masuk akal bagi pengguna akhir (tetapi mis. Terdengar bagus di brosur). Jadi ada pertempuran antara persyaratan "nyata" dan persyaratan "lainnya" yang diperjuangkan oleh pengembang
• Cakupan proyek tidak ditentukan ("Yah, jika Anda menerapkan pengolah kata, tidak bisakah Anda hanya menambahkan modul kecil yang melakukan akuntansi penggajian kami? Oh, dan Bill dari tim pengembangan lain bertanya seberapa sulit akan adalah membuat pengolah kata mengkompilasi kode C ++ juga? ")

Apa pun masalahnya, Anda harus memperbaikinya. Menenggelamkannya di bawah lapisan "Agile" (atau metodologi lainnya) tidak akan berfungsi.

Setidaknya dalam Scrum, yang tampaknya merupakan proses Agile yang paling populer dengan tipe manajemen saat ini, ruang lingkup Sprint diperbaiki. Jika Sprint Backlog Anda berubah selama sprint, itu bukan Scrum, itu kekacauan. Sprint Backlog harus dibuat pada awal sprint dan tetap diperbaiki sampai akhir sprint (saat Anda membuat Sprint Backlog baru untuk sprint berikutnya).

Jika Product Backlog Anda berubah selama sprint, itu bukan masalah besar. Perubahan hanya menjadi pekerjaan baru yang diprioritaskan, diperkirakan, dan dipilih seperti persyaratan lain untuk sprint berikutnya. Namun, jika persyaratannya sangat berubah sehingga Pemilik Produk harus membatalkan sprint secara teratur, Anda memiliki Masalah dengan modal 'T'.

Mungkin Anda perlu sprint yang lebih pendek?

Untuk kewarasan programmer, yang terbaik adalah jika persyaratan tidak berubah selama revisi / sprint.

Dalam situasi Anda, ada dua opsi yang jelas:

1. sprint yang lebih pendek
2. dapatkan pelanggan untuk setuju untuk tidak mengubah persyaratan selama revisi / sprint kecuali seluruh revisi / sprint dibatalkan dan direncanakan ulang

Saya sangat merekomendasikan keduanya .

Masalah utama adalah Anda yakin bahwa Anda menggunakan Scrum tetapi tidak. Terutama pemilik produk Anda tidak mengikutinya. Dalam Scrum, sprint adalah zona aman dan tidak ada perubahan pada cerita pengguna yang berkomitmen yang dapat dibuat kecuali sprint saat ini dibatalkan. Adalah tanggung jawab master Scrum untuk menegakkan ini. Jika ini tidak berhasil di lingkungan Anda maka itu adalah masalah proses = Anda tidak menggunakan Scrum.

Perubahan paling sederhana yang dapat Anda lakukan (jika Anda ingin mengikuti Scrum) adalah membuat sprint Anda lebih pendek - misalnya satu minggu. Sprint 4 minggu dianggap sebagai opsi pada hari-hari awal Scrum tetapi hari ini umum adalah 1 - 2 minggu dan 3 minggu dianggap sebagai batas atas. 4 minggu adalah waktu yang sangat lama dalam perubahan lingkungan.