Kejang

Dalam artikel ini saya ingin berbagi pengalaman saya tentang bagaimana kami menyelesaikan masalah "pembekuan" tugas di perusahaan kami.

Saya bekerja di sebuah startup, yang, seperti semua startup lainnya, sedang mengalami fase pertumbuhan dari 10 orang setahun lalu menjadi 35 orang saat ini, dan jumlah programmer selama ini telah bertambah dari 5 menjadi 25 orang dan kebanyakan dari mereka datang dalam enam bulan terakhir.

Struktur perusahaan, meskipun masih muda, saya sebut kuno, karena tidak ada yang pernah terlibat dalam proses pembangunan. Dengan pertumbuhan, kami terbagi menjadi tim pengembangan, tim pengujian, dan tim devops, dan semuanya bekerja lebih atau kurang.

Proses pengembangan, jika bisa disebut "proses," adalah seperti ini:

Pekerjaan pengembang berakhir segera setelah kode lulus ulasan kode dan dia menggadaikannya dalam pengembangan.

Pekerjaan tester berakhir ketika ia menguji dan smerzhil di cabang utama.
Devops terkadang mengklik tombol "Deploy to Prod", setelah manajer proyek harian mengatakan: "Mereka belum dikerahkan untuk waktu yang lama, mungkin kita akan dibatalkan hari ini?"

Apa yang baik:

• Banyak otomatisasi, misalnya, status di Jira disinkronkan dengan label cabang di GitLab, tugas di Jira ditutup setelah penerapan ke prod, kode secara otomatis digunakan untuk menguji dan mengatur lingkungan dengan gabungan dalam pengembangan dan master, masing-masing.
• Semuanya tertutupi oleh tes.
• Pemrogram menulis sendiri rencana pengujian dan menguji fungsi utama.

Masalahnya:

• Penguji tidak dapat melakukan apa pun selama seminggu, karena tugas menggantung di status code_review. Pada akhir minggu, programmer masih melakukan review ini dan pada hari Senin penguji memiliki banyak pekerjaan.
• Karena setelah ulasan kode semuanya diperbaiki dalam pengembangan dan jika sesuatu mengandung bug, maka kami tidak dapat menyebarkan apa pun. Sementara satu pengembang memperbaiki bug ini, yang lain mungkin bau fitur lain yang juga mengandung bug. Karena itu, kami biasa menunggu satu atau dua minggu sampai brunch ini stabil dan tester memiliki waktu untuk menginjaknya dalam master sebelum salah satu pengembang melakukan sesuatu yang lain untuk dikembangkan.
• Menyebarkan fitur dalam bundel besar, yang menambah risiko pengujian buruk atau menangkap sesuatu selama penyebaran.

Saya akan menjelaskan dua kasus yang menjelaskan kepada kita bahwa tidak mungkin untuk bekerja lebih jauh.

Jadi, misalnya, pada hari Jumat, kami memiliki 15 brunch di status code_review, dan pada hari Senin semuanya mengubah status menjadi ready_for_test. Penguji memberi tahu Daily bahwa mereka sangat mencintai kita. Dan selama tiga bulan kami tidak dapat menjual, karena berbagai alasan, beberapa fitur yang agak besar.

Pertama-tama, kami menemukan banyak code_review. Ternyata masalah ini dapat diselesaikan dengan cukup sederhana berkat aturan berikut:

1. Hanya tiga tugas yang bisa dalam status code_review. Ini adalah aturan terpenting yang tidak bisa dilanggar.
2. Jika programmer telah menyelesaikan pengembangan dan ingin menerjemahkan tugas ke dalam code_review, ia melihat apakah ia dapat melakukannya (lihat aturan 1).
3. Jika sudah ada tiga tugas dalam status code_review, maka pertama-tama ia membantu rekannya membuat tinjauan kode. Dan jika dalam proses peninjauan dia memiliki komentar atau saran untuk perubahan, maka dia pergi untuk melakukan pemrograman berpasangan dengan seorang rekan yang tugasnya dia tinjau.

Gagasan utamanya adalah tidak membiarkan kode membeku ketika sudah ditulis, dan untuk memberikan penguji dengan aliran pekerjaan yang rata selama seminggu.

Kami menerapkan ini dalam satu jam: kami berkumpul, berdiskusi dan pergi untuk melakukan tinjauan dan melakukan pemrograman berpasangan.

Jika kebetulan seseorang lupa (dan kadang-kadang seseorang lupa) aturan pertama, maka frasa “Kami memiliki lebih dari 3 PR dalam kode_review” segera terbang ke ruang obrolan. Mari kita tinjau !!! ". Pada saat yang sama, tidak ada orang khusus yang akan memastikan bahwa tidak ada lebih dari tiga permintaan tarik, ini dilakukan oleh pengembang sendiri.

Terlepas dari kenyataan bahwa perubahan ini mencegah pembekuan tugas, kami masih memiliki masalah dengan penerapan dan kebocoran bug yang sedang dikembangkan. Karena setelah peninjauan kode kami selalu bergabung di cabang pengembangan, dan secara otomatis digunakan untuk lingkungan pengujian untuk pengujian.

Solusi ini adalah semacam perbaikan terbaru, dan kemudian perlu untuk membuat perubahan dasar pada proses.

Hal utama yang kami putuskan untuk lakukan adalah memindahkan bidang tanggung jawab. Sekarang perusahaan tidak memiliki tim pengembangan, tim pengujian, atau tim pengembang terpisah yang saling mentransfer tugas dan hanya bertanggung jawab atas bagian mereka.

Kami mengorganisir pengembang menjadi beberapa tim: satu untuk setiap klien, karena kami memiliki produk utama, tetapi disesuaikan untuk setiap klien untuk waktu yang agak lama (kami adalah hibrida dari produk dan perusahaan jasa). Sekarang fitur pengiriman ke prod adalah tanggung jawab tim. Tidak ada tim pengujian dan pengembang yang dikenal, tetapi ada QA sebagai layanan, dan DevOps sebagai layanan.

QA sebagai layanan adalah tim yang tidak menguji, tetapi memastikan kualitas produk. Insinyur QA membantu pengembang menulis rencana pengujian dan berpartisipasi dalam sesi pengujian. Jadi kami membebaskan mereka dari pengujian manual, dan mereka punya waktu untuk menulis tes ujung ke ujung dan mengembangkan alat untuk membantu dengan pengujian. Kami juga menerapkan sistem pemantauan.

DevOps sebagai layanan adalah tim yang mengembangkan skrip penerapan, mendukung pekerjaan lingkungan pengujian, dan mengotomatiskan berbagai tugas.

Proses pengembangan baru adalah ini:

1. Ada tugas, dari pelanggan, manajer produk atau salah satu yang terbaik.
2. Pada tahap perencanaan sprint, kami membawanya ke pengembangan.
3. Pengembang menulis kode di cabang terpisah untuk tugas dan ketika selesai menerjemahkannya ke status code_review.
4. Salah satu kolega melakukan review.
5. Ketika tugas telah lulus dari tinjauan, pengembang bergabung ke cabang dengan tugas semua yang berkomitmen untuk mengembangkan dan menyebarkan cabang ini ke lingkungan pengujian.
6. Kemudian ia merencanakan rapat umum yang kami sebut Sesi Uji dan mengundang insinyur dan rekan QA ke sana jika perlu.
7. Insinyur QA memeriksa dan memperbaiki rencana pengujian sebelum Sesi Tes.
8. Pada Sesi Tes, pengembang memeriksa seluruh paket tes sebagai demo. Terkadang rencana pengujian dipecah menjadi beberapa bagian dan kemudian kami uji secara paralel. Hal utama adalah bahwa ini dilakukan bersama di ruang terpisah untuk rapat.
9. Jika setelah pengujian bug tidak ditemukan, maka pengembang menggabungkan kodenya ke cabang develop dan langsung ke cabang master (ini adalah sesuatu yang belum kami ubah, karena kami masih perlu memperbarui skrip penerapan). Di masa depan kami berencana untuk hanya meninggalkan cabang master.
10. Setelah itu, pengembang memulai penyebaran pada pementasan, hanya untuk memverifikasi bahwa penyebaran masih berjalan pada lingkungan yang identik dengan produk.
11. Jika semuanya ok, maka segera sebarkan ke prod. Keputusan untuk menggunakan atau tidak dibuat oleh tim pengembangan, tetapi QA memiliki hak untuk menghentikan penyebaran jika menganggap bahwa pengujian tambahan diperlukan, atau bahwa perlu untuk menunggu jika perlu untuk memperbaiki beberapa bug kritis pada prod.

Menariknya, transformasi ini meluncurkan beberapa perubahan tambahan tidak dalam proses pengembangan, tetapi dalam perencanaan dan mengubah topik yang kita bicarakan di Harian.

Sekarang, karena pengembang bertanggung jawab untuk mengirimkan cerita pengguna kepada prod, pada perencanaan, kami mulai menulis cerita pengguna sedemikian rupa sehingga masing-masing independen dari yang lain, dan juga dapat digunakan secara independen, seperti unit yang dapat digunakan. Kisah pengguna bertambah besar, tetapi semakin kecil.

Juga mengenai perencanaan, kami tidak mengevaluasi waktu pengembangan, tetapi berbicara tentang kapan kami berencana untuk menggunakan fitur.

Di Daily, kami tidak mengatakan bahwa "Saya telah menyelesaikan pengembangan", tetapi mengatakan "hari ini saya akan menggunakan fitur X", atau "hari ini saya akan menghilangkan lingkungan pengujian, siapa yang punya waktu untuk membantu saya dengan Sesi Tes?"

Sebagai hasilnya, kami telah mengembangkan tim pengembangan independen yang memiliki lingkungan pengujian mereka sendiri dan merencanakan apa dan kapan akan digunakan.