Agile, Waterfall dan perubahan persyaratan

10

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.

agile requirements

— Aravind A
sumber

"Perubahan persyaratan" adalah istilah yang longgar. Apakah perubahan itu karena pelanggan benar-benar berubah pikiran tentang persyaratan yang disetujui? Apa yang memicu perubahan itu? Jika ini terus terjadi maka Anda perlu memeriksa kembali bagaimana Anda mengumpulkan persyaratan. Tidak ada metodologi SE yang bisa memenuhi kurangnya pengumpulan persyaratan yang tepat.

— NoChance

@Emmad Perubahan persyaratan terjadi selama UAT ketika pengguna merasa bahwa kegunaan dapat ditingkatkan dengan cara tertentu. Hal ini menyebabkan penumpukan masalah pra produksi. Ini tentu saja bukan Agile.

— Aravind A

@ Aravind A: UAT terjadi di akhir sprint, bukan? Maka setiap ide / perubahan baru yang muncul selama UAT biasanya akan menjadi cerita untuk sprint berikutnya (jika Anda menggunakan sprint).

— sleske

Mungkin apa yang disarankan @sleske berfungsi untuk Anda, tetapi juga, kemudahan penggunaan dapat diujicobakan terlebih dahulu jika pengguna memiliki persyaratan yang luar biasa. Terkadang, dalam proyek yang terikat oleh sumber daya, Anda perlu mengontrol ambisi pengguna Anda.

— NoChance

9

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".

— sleske
sumber

Tidakkah proses ini membuat Agile lincah? Maksudku, seberapa jauh Agility bisa berjalan? Jika pengembang memenuhi persyaratan untuk pertama kalinya, pasti ada permintaan di waktu berikutnya. Saya merasa ini adalah salah satu dari banyak masalah yang menyebabkan kualitas kode terombang-ambing.

— Aravind A

@AravindA Kualitas kode harus menjadi perhatian yang terpisah dan terlepas dari berapa kali perubahan kode, tim harus fokus pada standar kualitas kode yang sama setiap saat. Bahkan, kualitas kode lebih penting karena persyaratan dan kode berubah terus-menerus.

— maple_shaft

2

@maple_shaft benar - kualitas (setidaknya sebagian besar) ortagonal terhadap perubahan persyaratan. Beri saya req: Saya mulai menulis kode yang baik. Jika saya selesai, dan mendapatkan req baru, atau setengah jadi dan mendapatkan perubahan, saya mulai (kembali) menulis kode yang baik. Setelah menyoroti dampaknya pada jadwal / komitmen saat ini / dll.

— sdg

Perubahan persyaratan yang memiliki pengaruh besar bagaimana sistem dirancang akan menghasilkan penundaan besar atau kompromi kualitas. Itu sebabnya Anda harus melakukan beberapa analisis air terjun tua yang baik (bisa juga berulang) di mana Anda mencoba mengurangi risiko penampilan "tiba-tiba" mereka.

— MaR

@les Terima kasih atas penjelasannya. Saya rasa saya mengerti sekarang. Saya pikir saya harus lebih mengenal Agile.

— Aravind A

12

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.

— nikie
sumber

@nike Terima kasih. Inilah yang saya pikirkan. Poin ketiga Anda cocok dengan skenario saya. Beberapa pelanggan hanya mengambil keuntungan dari pekerjaan 'Agile' dengan berpikir itu adalah peluru perak untuk menyelesaikan pekerjaan lebih cepat.

— Aravind A

9

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?

— Adam Jaskiewicz
sumber

+1 untuk membutuhkan sprint yang lebih pendek. Skala kembali ke 2 minggu dan lihat apakah itu membantu.

— John

1

4 minggu memang terdengar cukup lama untuk sprint, terutama pada proyek yang menderita ketidakstabilan persyaratan.

— Carson63000

7

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

Dalam situasi Anda, ada dua opsi yang jelas:

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

Saya sangat merekomendasikan keduanya .

— Steven A. Lowe
sumber

3

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.

— Ladislav Mrnka
sumber