Haruskah tim Agile memberikan fitur baru setiap hari?

Perusahaan saya berada di tengah-tengah transisi dari pengembangan gaya air terjun ke Agile / Scrum. Di antara hal-hal lain, kami diberitahu bahwa harapannya adalah agar kami memiliki fitur kerja yang baru , yang dapat diuji (oleh QA) di akhir setiap hari.

Sebagian besar pengembang kami kehilangan sekitar 2 jam sehari untuk rapat dan overhead perusahaan lainnya. Ini berarti bahwa dalam periode 6 jam (paling lama) tertentu apa pun, kita harus merancang, menulis, menguji unit, membuat, dan menggunakan (dengan catatan rilis) kode yang cukup untuk menghasilkan fitur lengkap untuk dimainkan bersama QA. Saya mengerti bahwa catatan build / deploy / release dapat diotomatisasi dengan pengaturan CI yang tepat tetapi kami belum ada di sana.

Kami juga memiliki kontingen lepas pantai yang besar menulis kode sisi server kami, dan perbedaan waktu 12 jam membuatnya semakin sulit.

Kami berupaya untuk membagi cerita menjadi irisan vertikal yang sempit dan dalam untuk menyelesaikan fitur ujung ke ujung secepat mungkin, tetapi sebagian besar hari terasa agak panik dan saya sering melihat orang mengambil jalan pintas yang bodoh dan rapuh untuk memastikan QA memiliki bangunan mereka. Masalah ini diperparah setelah sprint telah berlangsung selama beberapa hari, ketika cacat yang tak terhindarkan mulai bergulir dan harus masuk ke dalam jendela 6 jam yang sama.

Apakah ini langkah normal untuk tim Agile? Bahkan jika kita berhasil menerapkan pengaturan CI, saya tidak bisa melihat bagaimana kita dapat mempertahankan kecepatan ini dan masih membuat perangkat lunak yang berkualitas.

Sunting: Ada beberapa jawaban bagus di sini. Itu membuat saya sadar bahwa apa yang sebenarnya saya tanyakan adalah, apakah tim Agile memberikan fitur baru setiap hari. Saya memperbarui judulnya.

Kejahatan yang dilakukan atas nama Agile akhir-akhir ini membuat saya sedih. Banyak orang mengalami kesulitan melakukan transisi ini.

Agile Manifesto: "Kami menghargai orang dan interaksi dibandingkan proses dan alat.". Ketika orang-orang jelas-jelas terluka, prosesnya salah. Saya tidak ingin memberi tahu Anda cara melakukannya, tetapi akan membagikan bagaimana saya melakukannya.

Di tim saya, bagian penting adalah untuk menghindari komit dengan kode repo bersama yang rusak dengan cara yang akan menghabiskan sisa waktu tim. Dalam pengertian ini saja, saya berusaha untuk 'memberikan kode kerja setiap hari'. Jangan pecahkan QA. Jangan blokir pengembang lain. Idealnya saya tidak pernah memeriksa bug. (ha ha).

Implikasinya bukan bahwa Anda harus melakukan sesuatu setiap hari. Implikasinya adalah bahwa Anda hanya harus melakukan hal-hal yang baik, sehingga setiap hari Anda bisa mendapatkan semua hal-hal baik yang dilakukan oleh siapa pun. Dengan cara ini tim terus menembakkan semua silinder.

Di tim saya, QA adalah konstan. Saya membangun produk komersial, sehingga proyek tidak pernah berakhir sampai produk tersebut usang. Insinyur QA menguji fitur yang tersedia untuk diuji. Insinyur QA selalu memiliki jaminan simpanan. Tidak pernah ada cukup waktu QA untuk menguji atau mengotomatisasi semua yang kita inginkan secara ideal.

Jika pengembang perlu beberapa hari sebelum menggabungkan perubahan untuk fitur atau memperbaiki, tidak apa-apa, dianjurkan jika itu membantu mereka mendapatkan kode yang benar sebelum mengambil risiko pada waktu kita. Pengembang dapat melakukan kode ke repo atau cabang pribadi mereka tanpa mempengaruhi tim atau QA. Pengembang dapat menjalankan tes unit atau otomatisasi regresi pada kode yang dibangun dari repo pengembang atau cabang pribadi. Pada kasus yang berisiko, Insinyur QA akan bekerja dengan pengembang untuk menguji sebelum penggabungan, untuk melindungi tim dari keterlambatan.

Dalam hal ini, saya mempraktikkan apa yang diinginkan manajer Anda. Hampir setiap hari selama 12 tahun terakhir tim pengembangan saya memiliki kode yang berfungsi di repositori bersama. Kami hampir selalu siap untuk dikirim. Kadang-kadang kita tidak mencapai ini, tetapi kita tidak terlalu khawatir tentang hal itu. Terkadang disengaja, untuk mengakomodasi perubahan alat utama atau penggabungan yang sulit.

Manifesto Agile, bagi saya, meringkas yang terbaik dari pemikiran baru tentang proses pembangunan yang muncul pada 1990-an. Saya cukup percaya pada prinsip-prinsip itu, tetapi detail prosesnya bisa beragam. Seperti yang saya lihat, tujuan Agile adalah menyesuaikan proses Anda dengan kebutuhan produk dan klien Anda, bukan menjadi budak proses.

Jika Anda memiliki perangkat lunak yang berfungsi kemarin, mengapa tidak bekerja hari ini? Jika Anda tidak menyelesaikan tugas apa pun hari ini, build todays akan sama dengan kemarin. Membangun harian dan laju perkembangan adalah hal-hal yang terpisah. Hanya karena Anda memiliki versi harian, itu tidak berarti Anda memiliki fitur baru di setiap versi.

Ketika akhirnya beberapa fitur selesai dan check-in di cabang utama, maka Anda harus memiliki proses otomatis yang membangun perangkat lunak dan menjalankan tes. Jika ada masalah dengan tes membangun atau menjalankan, tim diberitahu dan mereka memfokuskan upaya mereka untuk membuatnya bekerja lagi. Itulah cara CI bekerja dan bagaimana hal itu membantu Anda merilis perangkat lunak yang bekerja setiap saat.

Jawaban Singkat: Tidak . Itu tidak bisa dilakukan setiap hari.

Namun, tim lincah seharusnya mengirimkan karya perangkat lunak atau cerita pengguna di setiap sprint . Biasanya, pertemuan status diadakan setiap hari untuk melihat kemajuan dan hambatan.

Sehubungan dengan perangkat lunak berkualitas , proses integrasi berkelanjutan (CI) akan memastikan bahwa kontrol kualitas diterapkan pada bagian-bagian kecil dari upaya (check-in), dan dilakukan sesering mungkin jika dikonfigurasi. Ini juga menargetkan untuk meningkatkan quality of software, dan untuk mengurangi waktu yang dibutuhkan untuk mengirimkannya, dengan mengganti praktik tradisional menerapkan kontrol kualitas setelah menyelesaikan semua pengembangan.

Tidak, seharusnya tidak ada harapan untuk menghadirkan fitur-fitur baru setiap hari. Tidak semua fitur dapat dipecah menjadi ukuran kecil sehingga dapat memiliki pengembang menyelesaikan fitur dalam ~ 6 jam waktu pengembangan.

Jika Anda melakukan scrum, Anda harus melakukan sprint minimal 2 minggu, dengan fitur berukuran sekitar 0 hingga 8 hari untuk selesai. Janji kepada pemilik produk adalah memberikan kode kerja yang benar, teruji, dan diverifikasi yang dapat dimasukkan ke dalam produksi di akhir sprint. (CATATAN: Anda tidak harus benar-benar memproduksinya tetapi tujuannya adalah bisa jika Anda mau)

Metodologi yang baik menyarankan Anda menyiapkan server CI (Continous Integration) di mana Anda mengotomatiskan pembuatan setidaknya satu perangkat lunak yang berfungsi setiap hari. Idenya adalah Anda memeriksa kode Anda segera setelah Anda menyelesaikan fitur sehingga bisa berada di siklus build berikutnya dan kemudian di tangan QA untuk pengujian.

Ingat tujuannya adalah untuk memiliki fitur yang dilakukan dan diuji pada akhir sprint! Anda tidak ingin harus membuat QA menunggu hingga hari terakhir sprint untuk Anda membuat build dan kemudian meminta mereka menguji semua fitur. Mereka tidak akan punya waktu untuk menguji semuanya dan Anda tidak akan punya waktu untuk memperbaiki bug ...

Jika Anda tidak dapat mengatur server CI maka praktiknya adalah Anda harus secara manual membuat build baru untuk QA setiap kali pengembang memeriksa kode yang sudah selesai dan mengklaim bahwa ia selesai dengan fitur dan siap untuk menyerahkan ke QA.

Ini sebenarnya tergantung pada ukuran proyek; jika proyek ini besar, tidak ada cara yang layak untuk mencapai ini.

Build harian (atau bahkan lebih sering) yang berasal dari alat integrasi berkesinambungan, tidak berarti perangkat lunak yang berfungsi; itu hampir tidak berarti kode yang dapat dikompilasi.

Ada banyak proyek di luar sana yang menghasilkan bangunan harian, yang berkat integrasi berkelanjutan, adalah perangkat lunak yang berfungsi. Setidaknya secara teori.

Artinya belum tentu berisi fitur-fitur baru. Mungkin beberapa perbaikan bug kecil, atau tidak sama sekali.

Secara teori, jika Anda tidak dapat menyediakan lebih banyak pekerjaan untuk QA Anda setiap hari, Anda harus menambah jumlah pengembang atau mengurangi jumlah penguji. Ide yang mengerikan!

Tugas Anda adalah menyelesaikan sesuatu.

Katakan pada QA bahwa mereka akan mendapatkan sesuatu untuk diuji setelah selesai. Anda perlu menjelaskan kepada mereka mengapa.

Saya pikir Anda bingung tentang ide "CI". Anda mungkin ingin mengunjungi artikel yang sangat bagus ini oleh Martin Fowler tentang bagaimana CI bekerja dalam praktiknya . Itu seharusnya menjawab pertanyaan Anda dengan benar.