Beberapa informasi latar belakang
Saya bagian dari tim pengembang perangkat lunak internal. Terdiri dari
- 5 pengembang (dengan pengalaman mulai dari 2 hingga 5 tahun, saya salah satunya)
- 3 staf implementasi (mereka melakukan penyebaran dan pelatihan perangkat lunak)
- dan 1 manajer proyek.
Kami mengembangkan banyak proyek kecil hingga menengah, dan jadwal mereka biasanya tumpang tindih. Pembangunan berjalan seperti ini:
- "Klien" memberi kami satu set persyaratan awal
- Kami mengembangkan sistem sesuai spesifikasi tersebut
- Sajikan sistem tersebut ke "klien"
- "Klien" memberi kami persyaratan tambahan berdasarkan presentasi tersebut
- Ulangi 2-4 sampai "klien" kehabisan persyaratan baru atau tanggal target penyebaran sudah dekat
- Mengatur dan menggunakan sistem
Ini, bersama dengan fakta bahwa itu adalah "klien" yang menangani tenggat waktu sebagian besar waktu (yang merupakan bendera merah, dari apa yang saya lihat di sini di Programmer dan PM.SE) dan kami tidak mengikuti arahan metodologi pengembangan yang pasti. untuk pengkodean koboi, hampir tidak dapat dipelihara kode, dan bug yang melewati produksi, antara lain. Itu sebabnya kami memilih untuk mengadopsi metodologi berbasis Agile seperti Scrum.
Mengapa scrum?
Itu adalah inisiatif manajer kami, dan semua orang tampaknya menyetujuinya, mengingat situasi kami saat ini.
Masalah dengan Scrum
Beberapa elemen Scrum memiliki konflik dengan pengaturan kami saat ini yang tidak dapat kami atasi dengan mudah, terutama sifat "jack-of-all-trade" dari pengembang Agile. Tim penempatan tidak tahu cara memprogram, dan pengembang memiliki keterampilan komunikasi dan pelatihan di bawah rata-rata. Dan lineup ini tidak akan benar-benar berubah dalam waktu dekat.
Pertanyaan
Apakah itu mempengaruhi efektivitas Scrum sebagai metodologi? Apakah perubahan lain perlu dilakukan untuk mengkompensasi? Atau akan lebih baik untuk meninggalkan pemikiran sama sekali dan berpikir tentang metodologi yang berbeda?