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?
Jawaban:
Tidak ada yang secara inheren tidak kompatibel antara bentuk QA ini dan metodologi berbasis iterasi seperti Scrum.
Dalam Scrum, tim memberikan hasil pada siklus X-mingguan yang menjadi pelanggannya. Bagian penting di sini adalah bahwa, jika tim pengembangan melakukan Scrum, maka pelanggan mereka adalah tim QA, bukan pengguna akhir produk Anda.
Sebagai pengembang, saya akan mempertimbangkan produk yang dapat dikirim ke QA jika memiliki peluang untuk lolos dari semua pengujian. Ini mungkin berarti bahwa beberapa tes QA telah dilaksanakan pada build harian, tetapi bagaimana hal itu mempengaruhi tes rilis resmi oleh tim QA tergantung pada organisasi Anda.
sumber
Untuk sebagian besar situasi kehidupan nyata tangkas berhenti saat pengiriman ke QA / UAT atau apa pun namanya.
Upaya untuk beralih dari QA ke Produksi dalam lingkungan kehidupan nyata sering diremehkan. Dalam banyak kasus, ini melibatkan pengguna bisnis nyata dalam pengujian, manajemen keluar dari lini nyata manajer bisnis, menjadwalkan rilis dengan operasi, dll. Dll. Ini bukan hal sepele!
Dalam kasus ekstrim, perangkat lunak ini mungkin memerlukan sertifikasi oleh lembaga luar, atau, harus melalui pengujian keamanan yang ketat.
Dalam keadaan ini, sangat tidak mungkin untuk membayangkan lebih dari satu rilis per kuartal kecuali untuk perbaikan bug.
Semakin buruk untuk produk perangkat lunak yang serius. Dokumentasi perlu dibuktikan dan dipublikasikan. Brosur pemasaran perlu diubah. Tenaga penjualan harus diberi tahu apa yang mereka jual (bukan tugas mudah!) Dll. Anda benar-benar tidak ingin menjalankan bisnis ini lebih dari setahun sekali.
sumber
Solusi jangka pendek adalah memberi QA periode waktu ekstra setelah iterasi Anda untuk menyelesaikan pengujian. yaitu. Jika Anda memiliki iterasi dua minggu, jangan lepaskan sampai minggu ke 3. QA tidak akan menguji apa pun terhadap iterasi berikutnya, selama minggu pertama itu.
Tetapi saya akan memperingatkan Anda di muka tentang apa yang akan terjadi (setelah melihat ini di beberapa tim): Anda akan berakhir dalam situasi di mana satu iterasi Anda menyelesaikan pekerjaan dua minggu, QA kelebihan beban, mereka mendatangi Anda untuk itu seluruh QA minggu dan, iterasi berikut, Anda hanya akan menyelesaikan satu minggu. Iterasi itu, QA tidak akan ada hubungannya dan Anda akan berpikir Anda telah menyelesaikan masalah. Tetapi kemudian iterasi berikutnya Anda akan memulai siklus lagi.
Jadi, segera setelah Anda menambahkan minggu itu, hanya untuk memastikan bahwa rilis Anda stabil (karena satu hal yang saya pelajari adalah bahwa jika Anda kehilangan kepercayaan bisnis, Agile menjadi semakin sulit untuk diimplementasikan), langsung saja ke rencana jangka panjang.
Beli salinan Pengiriman Berkelanjutan Jez Humble , membacanya, dari depan ke belakang, menyebarkannya ke seluruh tim. Buat semua orang terinspirasi. Kemudian terapkan semua yang Anda bisa darinya.
Jadikan proses pembuatan apik sebisa mungkin. Terapkan kebijakan unit-test dan buat mereka berjalan di setiap bangunan. Jadikan proses penyebaran sebagai hal paling licin yang pernah Anda lihat. Tiga klik? Tidak cukup apik.
Setelah Anda melakukan semua ini, tidak masalah lagi jika bug regresi sesekali berhasil. Anda tahu mengapa? Karena Anda akan dapat (opsional) mundur, memperbaikinya, menyebarkan lagi, sebelum bisnis hancur berkeping-keping. Bahkan petugas kebersihan malam akan dapat mengembalikan Anda, prosesnya akan sangat sederhana.
Saya tahu apa yang Anda pikirkan: Kami tidak punya waktu untuk melakukan semua itu. Biarkan saya memberitahu Anda, Anda lakukan. Jika Anda kelebihan QA, Anda menggunakan terlalu banyak per iterasi. Jadi jangan. Jika Anda belum kelebihannya, tanyakan mengapa mereka belum memiliki test suites otomatis. Anda akan segera.
Lakukan semua ini dengan visibilitas penuh ke bisnis. Perkirakan lebih rendah dan suntikkan sebagian dari karya ini ke dalam iterasi. Atau, lebih baik lagi, pisahkan menjadi cerita dan buat mereka untuk memprioritaskannya, di samping yang lainnya.
Jelaskan kepada mereka bahwa a) itu akan meningkatkan stabilitas rilis dan b) itu akan meningkatkan kemampuan Anda untuk menanggapi masalah bagi mereka dan c) itu akan membeli mereka lebih banyak kecepatan nanti. Ini adalah perusahaan langka yang tidak menginginkan hal-hal ini. Ini jelas bukan perusahaan Agile yang tidak menginginkannya, jika Anda mendapat perlawanan, Anda akan tahu Anda memiliki masalah yang berbeda.
Setelah Anda menerima Continuous Delivery down, Anda dapat mulai mempersingkat waktu QA di akhir iterasi. Adalah kepentingan semua orang untuk membawa iterasi kembali secara paralel, sesegera mungkin. Mungkin Anda akan memiliki satu hari di akhir iterasi, di mana Anda perlu mengisi waktu. Saya sudah menjawab apa yang harus dilakukan tentang itu di tempat lain .
sumber
Tampaknya ada masalah dengan cara Anda memutuskan apa yang sebenarnya dimaksud
work for release N.Untuk beberapa alasan aneh (saya hanya bisa menebak ada beberapa kesalahpahaman tentang resep Agile tertentu) Anda entah bagaimana memutuskan bahwa pendekatan tangkas mengamanatkan semua upaya tim QA untuk dimasukkan dalam iterasi.
Ada sedikit lebih banyak tentang kelincahan di bawah ini tetapi pertama, mari kita memilah
work for release N...Lihat, tidak ada alasan kuat bagi tim pengembangan untuk mendefinisikan pekerjaan seperti itu. Justru sebaliknya, dari uraian Anda, jelas bahwa alih-alih "unit kerja" monolitik, ada beberapa unit seperti itu, dengan tonggak yang mudah dirasakan ...
Perhatikan juga bahwa cara Anda mendefinisikan
work for release Njuga tidak dipaksakan oleh alur kerja QA. Dari apa yang Anda gambarkan, sepertinya mereka memiliki jadwal sendiri (dan cukup masuk akal).Diberikan di atas, cara yang lebih realistis untuk mendefinisikan unit kerja dalam kasus Anda bisa seperti berikut:
Release Candidate NRelease Candidate N patch 1Release Candidate N patch 2Di atas adalah unit kerja Anda, tidak peduli apakah Anda gesit atau apalah.
Ini alami dan nyaman untuk didefinisikan, diikuti, dan dilacak. Ini juga menyatu dengan baik dengan jadwal QA, memungkinkan untuk koordinasi odf dev dan upaya QA yang nyaman.
Pemahaman di atas tentang kompatibilitas dengan Agile terlihat salah secara mendasar dan inilah sebabnya ...
Asumsi yang Anda buat tidak ada hubungannya dengan Agile, jika kita mengambil filosofinya pada nilai nominal seperti yang ditunjukkan oleh namanya, itu adalah pendekatan yang mendukung dan mempraktikkan kelincahan .
Dari perspektif itu, bertahan dengan alur kerja "tetap" tertentu dan mengabaikan apakah itu nyaman atau tidak hanya bertentangan dengan semangat Agile. Dengan mengikuti "prosedur" secara sembrono, mengarah pada praktik - praktik yang direndahkan sedemikian fasihnya dalam Manifesto Agile Setengah-Arsed "... kami memiliki proses dan alat wajib untuk mengendalikan bagaimana individu-individu (kami lebih suka istilah 'sumber') berinteraksi" .
Anda dapat menemukan lebih banyak tentang ini dalam jawaban untuk pertanyaan lain , yang dikutip di bawah ini. Lihatlah catatan pada "rilis shippable", sepertinya saat itu OP telah bingung dengan cara yang sama:
sumber