Apakah scrum memiliki kelebihan dalam kontrak pertahanan?

12

Mendengar di watercooler kemarin: "Scrum tidak memiliki tempat dalam kontrak pertahanan."

Saya cenderung tidak setuju dalam arti bahwa saya percaya Scrum dapat disesuaikan untuk bekerja dalam banyak skenario dan saya dapat melihat pertahanan menjadi salah satunya. Ini memicu perdebatan besar di antara rekan-rekan saya (banyak dari kita yang bekerja dalam kontrak pertahanan) dengan perpecahan yang cukup adil untuk / melawan.

Untuk menjadikan ini pertanyaan yang tepat: Adakah yang berhasil menggunakan (atau memiliki pengalaman bekerja dengan) scrum dalam situasi kontrak pertahanan? Apa yang bekerja dengan baik, apa yang tidak bekerja dengan baik dan apa modifikasi (jika ada) untuk vanilla scrum yang Anda lakukan?

development-process scrum development-methodologies

— Sean Madden
sumber

3

Agile berusaha keras untuk membuang sampah. Organisasi yang berusaha sukses dengan gesit harus disejajarkan dengan tujuan itu. Organisasi politik cenderung memiliki prioritas lain.

— Martin Wickman

5

"Scrum tidak punya tempat dalam kontrak pertahanan."

Dalam pengalaman saya, hambatan utama adalah pelanggan. Sebagian besar lembaga pemerintah memiliki model air terjun dalam DNA mereka. Bahkan kontrak dilakukan dalam fase air terjun - pertama kita akan mendanai persyaratan, kemudian desain, lalu implementasi. Dalam teori air terjun klasik, mereka bahkan mungkin berpikir mereka bisa membuat perusahaan yang berbeda untuk melakukan fase yang berbeda.

Ada cara untuk menyiasatinya melalui IMO. Lakukan persyaratan dan desain awal seperti air terjun, lalu dalam implementasinya pisahkan persyaratan menjadi cerita pengguna yang berulang. Gunakan tes internal / pengguna ahli untuk mengevaluasi setiap iterasi. Tergantung pada pelanggan, mereka mungkin atau mungkin tidak tertarik untuk berpartisipasi. Bukan scrum murni, tapi mungkin itu yang terbaik yang bisa Anda lakukan.

— Doug T.
sumber

3

Saya bekerja sebagai pekerja magang untuk tiga tim di fasilitas Laboratorium Penelitian Angkatan Udara, sekali dalam mengembangkan perangkat lunak produksi, sekali dalam prototyping cepat, dan ketiga kalinya dalam verifikasi dan validasi pekerjaan kontrak. Kedua posisi pengembangan itu gesit. Faktanya, posisi produksi sangat dekat dengan Scrum, dengan lebih sedikit interaksi pelanggan (perangkat lunak disampaikan setiap beberapa iterasi, pelanggan di tempat setiap 3-6 bulan), dan ini pada tahun 2006. Saya setuju bahwa pembelian dan pemahaman pelanggan adalah yang terbesar masalah, tetapi beberapa lembaga pemerintah (atau setidaknya tim) memang merangkul metode Agile.

— Thomas Owens

@ Thomas Owens Komentar ini akan menjadi jawaban yang bagus.

— Hugo

1

Walaupun mungkin sulit untuk sepenuhnya mengimplementasikan Scrum, akan bermanfaat jika mengadopsi beberapa praktik Scrum. Misalnya, sekarang bagaimana Anda melakukan pengumpulan persyaratan, Anda masih dapat memiliki rilis dan demo yang sering. Anda masih bisa mendapat manfaat dari retrospektif berkala. Lihatlah proses lain seperti Lean atau Kanban dan lihat apakah ada yang mereka miliki yang dapat membantu tim Anda juga.

Alih-alih mengikuti setiap proses secara dogmatis, pikirkan tentang bagaimana Anda dapat meningkatkan proses khusus untuk tim Anda, proyek Anda, dan dalam industri Anda. Proses penting . Metodologi tim memiliki dampak besar pada perangkat lunak yang dikirimkan.

— epotter
sumber