Haruskah tim Agile memberikan fitur baru setiap hari?


31

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.

Jawaban:


52

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.


2
+1: Jawaban yang luar biasa. Beberapa sudut pandang yang benar-benar bagus tentang apa yang "tangkas" seharusnya benar-benar maksudkan.
Jim G.

24

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.


Saya mengucapkan pertanyaan itu dengan buruk. Saya benar-benar bertanya tentang kelayakan memberikan fitur baru setiap hari, bukan tentang menjaga produk yang sudah ada agar tidak rusak oleh build harian. Saya telah memperbarui pertanyaan.
Joshua Smith

@ JoshuaSmith: jika cerita Anda cukup kecil, sangat mungkin untuk memiliki barang baru setiap hari. Dan jika Anda memiliki server integrasi berkelanjutan, memiliki produk yang rusak bukanlah suatu pilihan. Jika suatu fitur tidak siap, itu tidak disinkronkan dengan server, atau dilakukan di cabang pribadi. Saya lebih suka solusi pertama.

8

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.


Kedengarannya seperti seseorang berusaha membuat tim penanya melakukan sprint per hari. Anda tidak boleh menurunkan apa pun ke QA sampai sprint (atau selesai untuk kepuasan semua orang) DAN itu dianggap dapat diterima (jumlah minimum fitur yang berfungsi, bug yang dikenal didokumentasikan).
John Lyon

1
mari kita perjelas: "Anda tidak boleh menurunkan apa pun ke QA sampai cerita pengguna selesai dan masuk."
EL Yusubov

Klarifikasi sedikit lebih: Sebuah cerita tidak dilakukan sampai kode untuk cerita telah diuji.
Bryan Oakley

@ ElYusubov Itu juga pemahaman saya bahwa kami seharusnya memberikan fitur / cerita baru di akhir setiap sprint, yang benar-benar masuk akal.
Joshua Smith

4

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.


1
Inilah yang kami lakukan sekarang, tetapi fitur-fitur baru jarang membutuhkan hanya satu hari untuk diselesaikan, terutama dengan lepas pantai yang terlibat.
Joshua Smith

2
Yang baik-baik saja, gesit / scrum hanya mengatakan itu akan memberikan kode berpotensi shippable di akhir sprint, bahkan bukan fitur baru! Banyak tempat memiliki seluruh sprint yang hanya meningkatkan kinerja atau membersihkan kode. Setiap tempat yang mengharapkan Anda untuk memiliki fitur baru dilakukan setiap hari adalah menyalahgunakan scrum untuk memanfaatkan Anda.
Alan Barber

2

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.


Dalam beberapa hal saya pikir mendapatkan beberapa fitur baru ke QA setiap hari seharusnya lebih mudah pada proyek besar. mis. Jika Anda memiliki 5 tim pengembang / pengembang, Anda bisa meminta mereka melakukan sprint 1 minggu, masing-masing diimbangi oleh satu hari dari hari berikutnya.
Dan Neely

1

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.


1
Seribu kali, ini. Saya memberi tahu pimpinan proyek bahwa menjaga agar QA dipasok dengan pekerjaan bukan tanggung jawab tim saya dan ditolak keras.
Joshua Smith

Cobalah untuk kembali dengan fakta yang lebih meyakinkan: developersurvivalguide.com/how-to-convince-your-boss

@JoshuaSmith: Saya mengedit jawaban saya agar sesuai dengan hasil edit terakhir Anda, tetapi saya khawatir itu bukan jawaban yang Anda cari ...

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.