Seseorang di perusahaan saya baru-baru ini mengusulkan perubahan pada produk inti kami yang menurut manajer kami harus memicu apa yang saya kira perusahaan saya anggap sebagai siklus QA penuh (yaitu menguji seluruh rangkaian produk dari bawah ke atas). Tampaknya QA kami membutuhkan waktu 12 minggu untuk melakukan siklus QA penuh untuk produk kami. Masalah saya dengan ini adalah bahwa kami mencoba untuk melakukan pengembangan Agile (walaupun sebagian besar berpegang pada pendapat saya). Kami akan melakukan seluruh set sprint dan kemudian melakukan rilis, yang QA akan memakan waktu lama untuk melewati kurasa. Pertanyaannya adalah, jika QA kita akan membutuhkan waktu 12 minggu untuk melakukan pekerjaan mereka, bukankah kita harus berhenti berusaha melakukan Agile? Apa gunanya mencoba melakukan Agile dalam situasi seperti ini?
Haruskah kita berhenti berusaha gesit jika QA membutuhkan waktu 12 minggu?
Jawaban:
Yah, jawaban langsung untuk pertanyaan Anda adalah Mu, saya khawatir - tidak ada cukup detail untuk membuat tebakan apakah Anda harus berhenti atau tidak.
Satu-satunya hal yang saya cukup positif adalah bahwa tingkat kelincahan harus didorong oleh kebutuhan pelanggan / pasar (yang Anda tidak memberi info tentang).
- Sebagai contoh, sebagai pengguna IDE saya sangat senang untuk meng-upgrade ke versi baru sekali atau mungkin dua kali setahun dan saya tidak pernah terburu-buru untuk melakukan itu. Yaitu jika siklus rilis mereka adalah 3 bulan ( 12 minggu ) maka saya sangat senang dengan itu.
Di sisi lain, saya dapat dengan mudah membayangkan, katakanlah, perusahaan perdagangan keuangan bangkrut jika dibutuhkan lebih dari sebulan untuk perangkat lunak mereka beradaptasi dengan perubahan pasar - siklus uji 12 minggu dalam kasus ini akan menjadi jalan menuju neraka. Sekarang - apa kebutuhan produk Anda dalam hal ini?
Hal lain yang perlu dipertimbangkan adalah kualitas tingkat apa yang diperlukan untuk melayani kebutuhan pelanggan / pasar Anda?
- Contoh kasus - di sebuah perusahaan yang pernah saya bekerja, kami menemukan bahwa kami memerlukan beberapa fitur baru dalam produk yang dilisensikan dari beberapa vendor perangkat lunak. Tanpa fitur ini kami sangat menderita, jadi ya, kami benar-benar ingin mereka gesit dan memberikan pembaruan dalam waktu sebulan.
Dan ya, mereka tampak gesit dan ya mereka merilis pembaruan itu dalam sebulan (jika siklus QA mereka adalah 12 minggu maka mereka kemungkinan besar hanya melewatkannya). Dan fitur kami bekerja dengan sangat baik - kira kita seharusnya benar-benar bahagia? tidak! kami menemukan bug regresi showstopper di beberapa fungsi yang bekerja dengan baik sebelumnya - jadi kami harus tetap menggunakan versi yang lebih lama.
Sebulan lagi berlalu - mereka merilis versi baru: fitur kamiada di sana tetapi bug regresi yang sama juga ada di sana: sekali lagi, kami tidak memutakhirkan. Dan satu bulan lagi.
Pada akhirnya kami hanya dapat meningkatkan setengah tahun kemudian begitu banyak untuk kelincahan mereka.
Sekarang, mari kita lihat lebih dekat ke 12 minggu yang Anda sebutkan ini.
Opsi apa yang Anda pertimbangkan untuk mempersingkat siklus QA? seperti yang dapat Anda lihat dari contoh di atas, hanya melewatkannya mungkin tidak memberi Anda apa yang Anda harapkan sehingga Anda lebih baik, lebih gesit dan mempertimbangkan berbagai cara untuk mengatasinya.
Misalnya, apakah Anda mempertimbangkan cara untuk meningkatkan kemampuan uji produk Anda?
Atau, apakah Anda mempertimbangkan solusi brute-force untuk hanya menyewa lebih banyak QA? Betapapun sederhananya terlihat, dalam beberapa kasus ini memang cara untuk pergi. Saya telah melihat manajemen yang tidak berpengalaman mencoba untuk memperbaiki masalah kualitas produk dengan secara buta merekrut lebih banyak pengembang senior di mana hanya sepasang penguji profesional rata-rata yang akan mencukupi. Menyedihkan sekali.
Yang terakhir tetapi tidak sedikit - saya pikir seseorang harus gesit tentang penerapan prinsip-prinsip tangkas. Maksud saya, jika persyaratan proyek tidak gesit (stabil atau berubah perlahan), lalu mengapa repot? Saya pernah mengamati manajemen puncak memaksa Scrum dalam proyek-proyek yang berjalan dengan baik tanpa. Sayang sekali itu. Tidak hanya tidak ada peningkatan dalam pengiriman mereka tetapi lebih buruk, pengembang dan penguji semua menjadi tidak bahagia.
pembaruan berdasarkan klarifikasi yang diberikan dalam komentar
Bagi saya, salah satu bagian terpenting dari Agile adalah memiliki rilis yang dapat dikirim pada akhir setiap sprint. Itu menyiratkan beberapa hal. Pertama, tingkat pengujian harus dilakukan untuk memastikan tidak ada bug yang muncul jika Anda berpikir Anda bisa merilis build ke pelanggan ...
Rilis shippable saya lihat. Hm Hmmm. Pertimbangkan menambahkan satu atau dua suntikan Lean ke dalam koktail Agile Anda. Maksud saya, jika ini bukan kebutuhan pelanggan / pasar maka ini hanya akan berarti pemborosan sumber daya (pengujian).
Saya tidak melihat kriminal dalam memperlakukan Sprint-end-release hanya sebagai beberapa pos pemeriksaan yang memuaskan tim.
- dev: yeah itu terlihat cukup bagus untuk dilewatkan ke penguji; TA: ya itu terlihat cukup bagus untuk kasus ini jika pengujian-shippable lebih lanjut diperlukan - hal-hal seperti itu. Team (dev + QA) puas, itu saja.
... Poin paling penting yang Anda buat adalah di akhir respons Anda dalam hal tidak menerapkan gesit jika persyaratannya tidak gesit. Saya pikir ini tepat. Ketika kami mulai lincah, kami melakukannya, dan situasinya masuk akal. Tetapi sejak itu, banyak hal telah berubah secara dramatis, dan kami berpegang teguh pada proses di mana hal itu mungkin tidak masuk akal lagi.
Anda benar sekali. Juga dari apa yang Anda gambarkan sepertinya Anda sampai pada kondisi (kematangan tim / manajemen dan hubungan pelanggan) yang memungkinkan Anda untuk menggunakan pengembangan model iteratif reguler alih-alih Scrum. Jika demikian maka Anda mungkin juga tertarik untuk mengetahui bahwa menurut pengalaman saya dalam kasus seperti iteratif reguler terasa lebih produktif daripada Scrum. Jauh lebih produktif - ada hanya begitu banyak overhead kurang, itu hanya jauh lebih mudah untuk fokus pada pengembangan (untuk QA untuk masing-masing fokus pada pengujian).
- Saya biasanya memikirkannya dalam hal Ferrari (seperti iteratif reguler) vs Landrover (sebagai Scrum).
Saat mengemudi di jalan raya (dan proyek Anda tampaknya telah mencapai jalan raya itu ) Ferrari mengalahkan Landrover.
Ini adalah off-road di mana seseorang membutuhkan jip bukan mobil sport - Maksud saya jika persyaratan Anda tidak teratur dan / atau jika pengalaman kerja tim dan manajemen tidak begitu baik, Anda harus memilih Scrum - hanya karena mencoba go regular akan membuat Anda macet - seperti Ferrari akan macet di luar jalan.
Produk lengkap kami benar-benar terdiri dari banyak bagian yang lebih kecil yang semuanya dapat ditingkatkan secara mandiri. Saya pikir pelanggan kami sangat ingin meningkatkan komponen yang lebih kecil lebih sering. Tampak bagi saya bahwa kita mungkin harus fokus pada rilis dan QA'ing komponen yang lebih kecil di akhir sprint sebagai gantinya ...
Di atas terdengar seperti rencana yang bagus. Saya pernah bekerja di proyek semacam itu. Kami mengirimkan rilis bulanan dengan pembaruan yang dilokalkan dalam komponen kecil berisiko rendah dan QA sign-off untuk ini semudah mendapatkannya.
- Satu hal yang perlu diingat untuk strategi ini adalah memiliki verifikasi yang dapat diuji bahwa perubahan dilokalkan di tempat yang diharapkan. Bahkan jika ini sejauh perbandingan file bit-demi-bit untuk komponen yang tidak berubah, lakukan atau Anda tidak akan mendapatkannya dikirim. Masalahnya, itu QA yang bertanggung jawab untuk kualitas rilis, bukan kami pengembang.
Adalah sakit kepala penguji untuk memastikan bahwa perubahan tak terduga tidak lolos - karena terus terang sebagai pengembang saya punya cukup hal lain yang perlu dikhawatirkan yang lebih penting bagi saya. Dan karena itu mereka (penguji) benar-benar sangat membutuhkan bukti kuat bahwa segala sesuatu berada di bawah kendali dengan rilis yang mereka uji coba.
Oh, aku merasakan sakitmu. Ada beberapa perubahan serius yang perlu Anda lakukan pada tim QA agar ini bisa berfungsi.
Saran saya adalah membagi tim menjadi tiga tim:
Pengujian fitur - Perputaran cepat untuk menguji perkembangan baru.
Pengujian regresi - Pengujian penuh produk sebelum keluar dari pintu. Ini seharusnya tidak memakan waktu 3 bulan, bahkan setelah mengurangi ukuran tim karena sebagian besar bug akan ditemukan oleh tim pertama.
Pengujian otomatis - Menulis rangkaian uji regresi lengkap untuk mempercepat pekerjaan tim pengujian regresi.
Tim ketiga adalah bonus, tetapi jika Anda tidak dapat memiliki dua tim pertama maka Anda juga bisa menjadi air terjun.
Sebagai ilustrasi:
Perhatikan bahwa tim QA Anda mungkin bekerja di luar lingkaran (ATDD), dan Anda sedang bekerja di dalam.
Saya pikir tidak apa-apa untuk bekerja seperti itu; jika Anda dapat membuktikan dalam pengujian otomatis Anda bahwa Anda memenuhi persyaratan pelanggan pada setiap sprint, Anda dapat mengizinkan QA untuk melakukan tes pada waktu luang mereka, dan mendatangi Anda dengan cacat, yang kemudian dapat Anda lakukan dalam sprint berikutnya.
Sepertinya Anda memiliki masalah "Definisi Selesai".
Mengingat bahwa grup QA Anda bersifat eksternal, dan hanya terlibat pada rilis pelanggan, Anda tidak dapat mengandalkan mereka untuk mendapatkan umpan balik yang tepat waktu tentang masalah. Itu berarti jika Anda ingin umpan balik yang cepat, Anda harus membawa beberapa tingkat pengujian "di rumah" untuk tim.
Perlakukan Grup QA seolah tidak ada. Bertindak adalah jika rilis Anda pada akhir sprint akan digunakan untuk lingkungan Anda yang paling penting pada hari berikutnya. Perangkat lunak tidak selesai sampai siap untuk pergi ke pelanggan.
QA seharusnya tidak menemukan apa pun.
Ini akan lebih sulit untuk dicapai. Anda mungkin akan memiliki beberapa hal yang menyelinap melalui beberapa kali pertama. Tes penerimaan otomatis dan tes "regresi" adalah teman terbaik Anda di sini. TDD akan membantu Anda membangun sebagian besar suite tersebut. Anda harus bisa tahu - dengan cepat - jika Anda telah merusak sesuatu.
Apakah Anda memiliki perwakilan pelanggan / pemilik produk yang dapat melihat rilis yang diberikan sebelum QA selesai dengan itu dan memberi Anda umpan balik otoritatif di atasnya? Jika demikian, Anda dapat melakukannya, dan mendapatkan sebagian besar manfaat dari, metode tangkas sambil memperlakukan QA sebagai sumber umpan balik sekunder yang agak lambat. Rilis hanya akan "resmi siap" setelah QA selesai, tetapi Anda tidak perlu menunggu mereka sebelum memulai berikutnya.
Tetapi jika aturan perusahaan mengatakan bahwa pelanggan tidak boleh melihat rilis sebelum QA selesai dengan itu, maka Anda bisa lupa tentang menjadi gesit, sampai Anda berhasil mengubah aturan itu.
Proses yang Anda uraikan bukanlah proses yang gesit. Tim yang memiliki tingkat kelincahan tinggi mampu memberikan bangunan yang andal dan berpotensi dirilis setiap sprint. Dalam sebagian besar implementasi tangkas, fungsi QA dibangun dalam tim tangkas membantu untuk mencapai tujuan ini.
Jika Anda, pimpinan proyek Anda, pemilik produk Anda dan pengembang tidak bekerja bersama dan Anda tidak memiliki rencana perbaikan (retrospektif) maka beri nama proses Anda sesuatu yang lain dan lanjutkan. Tampaknya masalah tim Anda bukan kesalahan manajer atau QA. Mereka tampaknya bereaksi terhadap beberapa masalah sistemik yang keluar dari organisasi pembangunan. Semua tidak hilang jika tim mau mengambil tanggung jawab dan mulai bekerja dengan pemangku kepentingan.
Anda bisa mencoba tiga hal. Pertama, pastikan setiap pemangku kepentingan memiliki peran yang didefinisikan secara ringkas dan bahwa setiap orang memahami tanggung jawab mereka. Dua, stabilkan build dan dapatkan signoff dari QA tanpa memasukkan lebih banyak perubahan. Tiga, otomatisasi uji institut. Tim QA akan mencintaimu karenanya.
Sayang sekali umpan baliknya memakan waktu begitu lama, tapi saya pikir tidak ada gunanya berhenti dengan gesit. Pada akhir sprint (atau pasangan) Anda merilis produk yang Anda yakini dapat dijual di pasaran. Untuk tim Anda gesit membawa kemampuan untuk fokus pada pekerjaan yang harus dilakukan dan menjaga produk yang dapat dilepas. Ketika QA menemukan masalah, saya sarankan untuk membuat laporan bug untuk masalah ini dan mengatasinya dalam sprint berikutnya (jika mereka memiliki prioritas yang cukup tinggi).
Tes lapangan produk kami memakan waktu 8 minggu penuh ditambah bahwa kami bergantung pada petani luar. Masih dengan melakukan lincah kami dapat tetap fokus pada pekerjaan yang ada dan menghasilkan versi baru dengan sangat cepat ketika dibutuhkan.
Masalahnya terletak (di mata Anda) dengan departemen QA dapatkah masalahnya diselesaikan di sana? Sudahkah Anda mendiskusikannya?
Apa yang dilakukan orang-orang QA saat Anda menjalankan beberapa sprint? Kedengarannya mereka merasa perlu menguji segalanya setelah setiap perubahan (Itulah sebabnya mereka menunggu sejumlah besar perubahan.).
Tim pengembang gesit, tetapi perusahaan lain tidak.
Siapa pun yang bertanggung jawab atas QA juga tidak tahu apa yang ia lakukan atau mereka telah melakukan Jedi Mind Trick pada manajemen tingkat atas dan diizinkan untuk mengambil waktu manis mereka. Bagaimana QA bisa lebih lama dari pengembangan?