Setelah lebih dari dua tahun bekerja di struktur departemen pengembangan yang sangat sunyi, "lone-wolf", kami mengadopsi Agile SCRUM. Bagus. Saya suka Agile; sebagai pengembang, ini membuat Anda tetap fokus, sibuk, dan produktif tanpa memiliki banyak pemangku kepentingan yang mendorong proyek demi proyek, dengan harapan mereka semua akan dilakukan kemarin.
Namun, ada satu aspek pindah ke SCRUM versus "model" kami saat ini, yang saya pikir orang di luar Pembangunan tidak akan suka sedikit pun. Itulah kemampuan mereka saat ini untuk meminta kami melakukan perubahan kecil "selagi Anda menunggu". Sebagian besar dari pengembangan kami hanya untuk konsumsi internal, dan kami sebagian besar berada di gedung yang sama. Jadi, sudah lazim selama bertahun-tahun bagi seorang pimpinan departemen atau manajer di tempat lain untuk datang ke "pemilik basis kode" aplikasi tertentu dan meminta barang-barang kecil (kadang-kadang tidak begitu kecil, tapi kami cukup baik untuk tidak mengambil tiga- proyek minggu berdasarkan "drive-bys" ini). Bahkan bos kami terkadang menyampaikan hal-hal yang disampaikan kepadanya dengan cara ini. Sangat sering, jika kita bekerja dalam basis kode yang dimaksud pada saat itu, kita cukup memunculkan file sumbernya,
Dengan metodologi Agile SCRUM dasar, perubahan ini akan dicatat sebagai cacat (kami tidak memenuhi persyaratan yang ditentukan dalam cerita yang sebelumnya dikonsumsi) atau cerita kecil baru (kami memenuhi semua persyaratan yang disebutkan, tetapi persyaratan itu tidak lengkap, kabur atau tidak benar , atau mereka berubah setelah pengiriman setelah pengguna melihat fitur baru). Either way, sebagian besar akan menjadi salah satu-pointer di sebagian besar, jika tidak nol, dan prioritas relatif rendah (sistem ini dapat digunakan dalam kondisi saat ini, tapi akan jadi lebih dingin jika ...), membuat mereka tidak mungkin dibawa berlari ketika bekerja backlog top-down.
Kemungkinan ini dinaikkan pada pertemuan dev sebagai sumber oposisi aktif untuk proses Agile kami oleh departemen lain, yang akan melihatnya sebagai kurang "gesit" daripada kemampuan kami saat ini untuk membuat tweak kecil berdasarkan permintaan. Ini adalah masalah IMO yang valid; para pemangku kepentingan di balik PO tidak selalu sepakat tentang hal-hal apa yang paling penting, karena mereka semua tidak memiliki sudut pandang yang sama, namun biasanya hanya para manajer yang membuat keputusan akhir, dan oleh karena itu bias mereka adalah yang ditampilkan di jaminan produk.
Sebuah solusi kemudian diusulkan, yang sementara ini disebut "toples permen" (istilah lain yang dibuang adalah "perahu saus"). Perbaikan kecil yang diminta oleh "orang-orang kecil" di berbagai departemen, yang tidak cacat dalam cerita yang ada, yang diperkirakan dengan konsensus atau aklamasi dalam tim untuk mengambil kurang dari setengah hari pengembang, dan itu akan membuat dampak langsung, signifikan, dan positif pada pengalaman pengguna menurut pendapat pengguna akhir, dimasukkan dalam daftar secara paralel dengan jaminan simpanan utama. Mereka akan diidentifikasi sebagai "cerita", tetapi akan disimpan terpisah dari simpanan utama cerita "besar" yang menjadi prioritas. Jika, sewaktu-waktu selama kemajuan normal sprint, kami bekerja di area sistem di mana salah satu tweak ini dapat dibuat, membuat tweak sepele, kita bisa membawa tweak ke sprint dan kode di samping cerita yang lebih besar. Melakukan initidak boleh membahayakan penyelesaian cerita yang lebih besar atau pekerjaan berkomitmen lainnya. PO juga akan memiliki akses ke daftar ini, dan jika mereka mengerjakan cerita pengguna yang akan datang menyentuh fitur dasar yang melibatkan tweak, mereka dapat melipatnya ke dalam cerita sebagai persyaratan dan kemudian kami akan memenuhi persyaratan seperti yang akan kami lakukan lain. Ini, diperkirakan, akan membuat tweak lebih mungkin untuk dikerjakan lebih cepat daripada nanti.
Ini memicu reaksi di antara kita dengan pelatihan ScrumMaster "uh-uh". Ada satu jaminan simpanan. Dua backlog memperkenalkan pertanyaan tentang item # 1 mana yang benar - benar paling penting, item mana yang menentukan kecepatan nyata , dan dari mana dari dua backlog cerita mana yang sebenarnya berada (demarkasi ukuran / kompleksitas akan memiliki beberapa kasus yang jatuh secara relatif sewenang-wenang ke satu sisi atau yang lain). "Biarkan prosesnya bekerja", kami berkata; jika perubahan benar-benar signifikan bagi pengguna akhir, mereka akan membuat suara yang cukup untuk membuat kepala departemen membuat keputusan waktu / uang di papan, dan itu akan menabrak kesadaran tim dev menuju bagian atas tumpukan.
Saya pikir saya akan mengajukan pertanyaan: Menurut pendapat Anda, apakah daftar paralel cerita "ukuran gigitan" memiliki nilai dalam mendapatkan perubahan kecil, bermanfaat tetapi pada akhirnya prioritas rendah dibuat lebih cepat, atau apakah secara keseluruhan itu keputusan yang lebih baik untuk melipatnya ke dalam tumpukan utama dan membiarkan proses dasar mengatur inklusi mereka dalam sprint?