Di perusahaan saya, kami berhasil bekerja dengan praktik lincah - tetapi tanpa menggunakan iterasi. Alasan utamanya adalah kita tidak dapat menemukan cara yang bersih untuk menyesuaikan QA dalam siklus iterasi.
Kami memahami QA sebagai sedikit ekstra verifikasi untuk bangunan tertentu (kandidat rilis) sebelum bangunan ini digunakan untuk pelanggan. Intinya adalah untuk menghindari bahwa satu komit jahat merusak seluruh rilis. Karena Anda tidak pernah tahu yang mana itu, QA harus menunggu sampai semua fitur / komit untuk rilis dibuat. (Tidak ada kata-kata terakhir yang terkenal "Itu hanya perubahan kecil" diizinkan.)
Jika QA menemukan bug dalam kandidat rilis, pengembang memperbaiki bug ini di cabang rilis masing-masing (dan menggabungkannya ke dalam trunk). Ketika semua bug diperbaiki, build baru dikerahkan untuk QA untuk menguji ulang. Hanya ketika tidak ada bug ditemukan di kandidat rilis tertentu, itu ditawarkan kepada pelanggan untuk verifikasi.
Ini biasanya membutuhkan sekitar dua hingga tiga kandidat, sekitar satu minggu, per rilis. Waktu untuk menulis perbaikan biasanya jauh lebih rendah daripada upaya pengujian. Jadi untuk membuat para pengembang sibuk, mereka bekerja pada rilis N + 1 sementara QA bekerja pada N.
Tanpa menggunakan iterasi, ini tidak masalah karena kita bisa tumpang tindih pekerjaan untuk rilis N dan N +1. Namun, dari apa yang saya pahami, ini tidak kompatibel dengan pendekatan berbasis iterasi seperti Scrum atau XP. Mereka menuntut iterasi untuk dapat dirilis pada akhirnya dengan semua upaya pengujian untuk dimasukkan dalam iterasi.
Saya menemukan bahwa ini pasti mengarah ke salah satu hasil yang tidak diinginkan berikut:
(A) Pengembang menganggur pada akhir iterasi karena QA perlu waktu untuk memverifikasi kandidat rilis dan pekerjaan memperbaiki bug tidak sepenuhnya membuat para dev sibuk.
(B) QA sudah mulai bekerja sebelum kandidat rilis pertama siap. Inilah yang paling direkomendasikan di Stack Exchange. Tapi itu bukan apa yang dipahami perusahaan saya sebagai QA karena tidak ada kandidat rilis spesifik yang diuji. Dan "perubahan kecil" yang memecah segalanya masih bisa diperkenalkan tanpa disadari.
(C) Bug dibawa ke iterasi berikutnya. Ini juga direkomendasikan di Stack Exchange. Saya tidak berpikir itu solusi sama sekali. Ini pada dasarnya berarti bahwa kita tidak pernah mendapatkan versi terverifikasi karena setiap kali perbaikan bug dilakukan, komitmen baru yang belum diverifikasi ditambahkan ke cabang yang sama juga.
Apakah ada jalan keluar dari dilema ini?