Pada duri dan bintang di jalan untuk mengoptimalkan proses pembangunan

Mimpi, Mimpi

Pada malam musim gugur yang dingin, kami dan para pengembang aplikasi visualisasi 3D berkumpul di dapur ... minum kopi ... dan memikirkannya ... tentang referensi organisasi pengembangan.

- Teman-teman saya bekerja dengan gesit untuk saya: lari cepat, poin cerita, semua hal ...
- Ya, kami setidaknya akan meninjau ...



Faktanya adalah bahwa pada hari-hari itu, tidak begitu mulus dengan kami. Misalnya, menyimpan proyek di git sangat tidak biasa:

• ada beberapa repositori, dan masing-masing bagian berisi bagian dari proyek;
• beberapa repositori adalah umum, beberapa hanya terkait dengan beberapa proyek, beberapa hanya satu;
• untuk mendapatkan salinan yang berfungsi, Anda harus mengunduh konten dari semua repositori dan meletakkannya di folder tertentu.

Karena kami bekerja dengan grafik 3D dan kemudian menggunakan konsep "kontrol + templat (lokasi elemen pada layar, logika transisi)", untuk lebih spesifik, semuanya seperti ini:

• ketika mengerjakan kontrol, komit pergi ke repositori dengan kontrol dasar dan, mungkin, ke repositori dengan sumber daya (jika model tiga dimensi yang sudah digunakan harus digunakan di tempat lain);
• ketika bekerja dengan kontrol dan templat (misalnya, jika perlu untuk mengganti latar belakang dalam aplikasi di bawah panel bantuan), gambar harus diunggah ke repositori dengan sumber daya, dan tata letak diedit dalam repositori dengan templat. Jika latar belakang dibuat dengan kulit (gaya tunggal), maka 3 repositori dapat terlibat.

Dengan pendekatan ini, ulasan kode merupakan kemewahan untuk biaya:

• pengembangan dilakukan dalam satu cabang tunggal;
• perubahan pada satu tugas memengaruhi beberapa repositori dan pelacakan yang melakukan terkait dengan tugas yang sangat bermasalah.

Akibatnya, karena kurangnya kemampuan untuk "belajar dari kesalahan", bertukar pengalaman, menganalisis kode satu sama lain selama peninjauan, pengembang tidak dapat meningkatkan keterampilan mereka dengan cukup cepat. Dan untuk mengembangkan aplikasi "lebih cepat" - itu perlu. Dan untuk mempertahankan kecepatan pengembangan pada tingkat yang dapat diterima, pada setiap proyek baru, orang terlibat dalam tugas-tugas yang mirip dengan tugas mereka pada proyek sebelumnya. Yaitu jika seseorang sebelumnya bekerja dengan peta 3D, ia berulang kali mendapat tugas yang terkait dengan peta, atau jika seseorang pernah mengembangkan komponen "bagan", ia ditakdirkan untuk grafis. Dan ini memiliki logikanya sendiri, karena lebih cepat, tugas direalisasikan oleh orang yang telah mengalami serupa atau identik dengan itu. Akibatnya, ternyata para pengembang mengkhususkan diri pada hal-hal tertentu dan tidak dapat dipertukarkan.

Adapun metodologi pengembangan dan alur kerja yang jelas, mereka juga tidak diterapkan karena sejumlah alasan. Mulai dari fakta bahwa untuk ini perlu mencurahkan banyak waktu untuk memikirkan semua konsep dan proses pengembangan, berakhir dengan fakta bahwa tidak ada seorang pun yang membawanya. Baik saya, sebagai karyawan yang paling baru tiba, maupun orang-orang memiliki wewenang untuk mengatur ulang. Dan itu hanya tinggal menggerutu dan bermimpi.

"Di mana ada mimpi, selalu ada kesempatan"

Tentu saja, bagi saya, sebagai orang yang tidak acuh pada pekerjaannya, tujuannya adalah mengubah situasi. Kalau tidak, apa gunanya aktivitas saya, jika saya tidak dapat secara positif mempengaruhi proses yang ada dan menyediakan kondisi kerja seperti itu bagi orang-orang di mana mereka dapat mengungkapkan kemampuan dan peningkatan mereka? Perkembangan mereka yang menciptakan aplikasi, yang mewujudkan ide yang diproyeksikan di atas kertas, ke dalam kehidupan adalah pengembangan dari kedua proyek dan perusahaan secara keseluruhan.

Peluang yang baik untuk pencapaian tujuan adalah appru untuk mengembangkan modul visualisasi baru platform kami. Proyek ini tidak seperti yang lain, karena Itu bukan pengembangan aplikasi pada platform, tetapi implementasi bagian dari platform itu sendiri. Oleh karena itu, di sini kami tidak terikat pada konsep aneh menyimpan dan bekerja dengan proyek-proyek di banyak repositori git, yang bagi saya merupakan peluang besar untuk memperkenalkan ulasan kode.




Di sini, omong-omong, apa yang kami lakukan

Dan suatu pagi di musim dingin yang baik, saya menyerang arsitek proyek dengan proposal untuk memperkenalkan Gitflow. Pada awalnya, ia menganggap ide saya bertentangan, tetapi ada alasannya: beberapa model standar tidak selalu cocok. Namun, dalam proses komunikasi, opsi yang paling cocok dikembangkan untuk proyek ini, yang sekarang berhasil kami gunakan.

Gitflow kami yang dimodifikasi adalah sebagai berikut:

• ada cabang utama (kami menyebutnya master, tetapi Anda dapat memberikan nama apa pun agar tidak bingung);
• ada sprint di Jira, terbentuk dari tugas-tugas backlog yang disatukan oleh satu mikro-target;
• pengembang mengambil tugas dari daftar yang terbuka dalam sprint menjadi progres dan membuat cabang fitur dari master, menunjukkan kode tugas atas nama cabang fiturnya (misalnya, PLAYER-55);
• segera setelah pekerjaan pada tugas selesai, pengembang mengirimkan karyanya untuk ditinjau: melalui Gitlab menciptakan permintaan penggabungan untuk menguasai dan mentransfer tugas ke Jira pada Tinjauan dengan tautan ke permintaan penggabungan dalam komentar;
• jika peninjauan selesai dan semua diskusi ditutup, maka tugas di Jira ditutup, cabang fitur digabung menjadi master dan dihapus;
• jika ada komentar setelah peninjauan - di Jira tugas itu ditemukan kembali dari Peninjauan dan algoritma berjalan dari awal, kecuali bahwa cabang fitur telah dibuat.

Ketika semua tugas ditutup, kami memasuki tahap rilis:

• cabang rilis dipanggil jauh dari master, yang disebut dua digit, misalnya, rilis-3.0, di mana 3 adalah nomor versi proyek, dan 0 adalah jumlah cabang rilis (masing-masing, cabang rilis berikutnya akan disebut rilis-3.1, dll. );
• Pengujian lebih lanjut dari kandidat pelepasan dilakukan (biasanya pengembangan demo kecil);
• jika tidak ada cacat yang ditemukan selama pengujian, maka kandidat rilis siap untuk produksi: komit terakhir di cabang rilis ditandai dengan tag produksi yang terdiri dari 3 digit (misalnya, prod-3.0.0, di mana 3 adalah nomor versi proyek, 0 - nomor rilis cabang, 0 - nomor versi produksi), maka cabang rilis terjebak dalam master dan tidak dihapus, tidak seperti Gitflow klasik;
• jika cacat masih ditemukan, maka mereka terdaftar di Jira sebagai Bug dan kemudian proses perbaikan bug mirip dengan bekerja dengan tugas di cabang fitur (itu hanya diperiksa dari rilis, bukan dari master) dan ketika semua bug ditutup, kami meletakkan label produksi, versi adalah output ke prod dan cabang rilis digabung menjadi master, tanpa dihapus.

Dalam hal bug ditemukan dalam produksi, ada juga kesepakatan:

• perbaikan bug tersebut juga dilakukan di cabang rilis dari versi penjualan ini, jika pengeditan sangat mendesak, mereka ditandai sebagai perbaikan terbaru dan dilakukan langsung di cabang rilis dengan pimpinan tim;
• jika tidak, mengerjakan bug seperti ini mirip dengan mengerjakan bug yang ditemukan pada kandidat rilis.

Jadi mengapa tepatnya Gitflow dan hanya itu?

1. Memasuki cabang fitur adalah cara untuk memperkenalkan tinjauan, yang memungkinkan Anda untuk berbagi pengalaman, meningkatkan tingkat keseluruhan kualifikasi tim, dan, yang paling penting, sebagai hasilnya, untuk menghindari memasukkan kode berkualitas rendah ke dalam produk jadi yang tidak memiliki gaya umum, sulit dipahami dan penuh dengan bug.
2. Saya pikir banyak orang yang akrab dengan situasi ketika proyek dievaluasi sesuai dengan ketentuan referensi dan spesifikasi, anggaran dialokasikan untuk itu, Anda menerapkan fungsi sesuai dengan persyaratan dalam dokumentasi, tetapi di sini, entah dari mana, seseorang dari bos akan muncul dan Anda mendengar: "Oh, tapi mari kita tambahkan beberapa unicorn di sini, pelanggan akan menyukainya "," Dan bisakah Anda membuat kesempatan untuk memanggil teman di wilayah ini dengan mengklik wilayah di peta? Itu akan menjadi bom, lanjutkan "," Kita perlu menambahkan legenda "," Sekarang legenda perlu dihapus, dan tanda tangan juga "," Menghapus tanda tangan berlebihan, kembalikan. " Dan semua ini "gratis tanpa registrasi dan SMS." Dan kemudian, ketika menghitung biaya aktual, ternyata butuh banyak pekerjaan untuk dikembangkan dengan sejumlah kecil tugas (lagipula, "permintaan" di Jira biasanya tidak terdaftar, karena tidak setiap pengembang dapat menolak bos atau mengirimnya untuk mendaftarkan "permintaannya" ", Dan ini bisa dipahami). Pengenalan aturan penamaan cabang individu dengan kode Jira dan ketidakmampuan untuk menggabungkan cabang menjadi master tanpa mengikat Jira menghilangkan kehadiran pekerjaan yang tidak terdaftar dan konflik yang mungkin timbul jika pengembang "mulai mengunduh hak", mengharuskan Anda untuk mengisi "permintaan" sebagai tugas di Jira, dan juga memungkinkan Anda untuk memiliki gagasan yang jelas tentang berapa banyak pekerjaan yang sebenarnya dilakukan (tugas-tugas di Jira dikonfirmasi oleh kode yang terkait dengan mereka, kode tertulis melalui komunikasi dengan tugas terdaftar).
3. Koneksi Gitflow dengan Jira dalam hal memperbarui status tugas membantu menghindari situasi di mana beberapa orang melakukan tugas yang sama. Dalam hal memperbarui status sesuai dengan tahap Gitflow mereka, setiap orang akan melihat bahwa tugas ini dan itu sudah dalam proses atau sedang ditinjau, masing-masing, bagi mereka sudah ada cabang fitur di mana kode ditulis, dan Anda tidak perlu mengambilnya. Juga terlihat jelas siapa yang melakukan apa dan apa yang berhasil dapat saling mempengaruhi, siapa di antara mereka yang harus lebih sering menghubungi dan menyetujui implementasi tertentu, sehingga ketika merger tidak harus menyelesaikan konflik kode untuk waktu yang lama dan menyakitkan.
4. Karena kami mengembangkan platform untuk membuat aplikasi, ada baiknya mempertimbangkan bahwa produk jadi seseorang akan tergantung pada kebijakan kami untuk mendukung versi lama platform dan memperkenalkan yang baru. Ada kemungkinan bahwa beberapa pengguna platform karena alasan tertentu akan menggunakan versi terbaru platform dan menemukan bug yang terkait dengan platform. Jika kami menghapus cabang rilis, kami tidak akan dapat membantu pengguna kami dalam situasi seperti itu, terutama jika fungsi yang mereka gunakan dalam versi mereka dihapus atau dimodifikasi dalam implementasi platform baru. Dengan demikian, menyimpan cabang rilis memungkinkan Anda untuk memberikan dukungan kepada pengguna yang tidak bekerja dengan versi terbaru platform.

Bagaimana dengan Agile?

Seperti yang mungkin sudah Anda perhatikan, kami mulai perlahan-lahan mendekati prinsip pengembangan scrum tangkas, mulai dengan membagi tugas menjadi sprint untuk target mikro.



Selanjutnya diperkenalkan Poker Perencanaan, Poin Cerita, analisis kecepatan tim, retrospektif.
Partisipasi dalam Perencanaan Poker dan menugaskan Poin Cerita untuk tugas memungkinkan tim untuk memiliki pandangan yang lebih holistik dari proyek, struktur arsitekturnya, apa yang biasanya kita perjuangkan dan apa yang seharusnya hasilnya. Orang mendapat kesempatan untuk berpikir secara sistemik, dan tidak hanya dalam kerangka tugas mereka. Ini menguntungkan mempengaruhi perkembangan mereka sebagai profesional dan proyek itu sendiri:

• fitur-fitur baru yang bermanfaat ditawarkan, karena semakin jelas bagi pengembang apa dan di mana dapat ditingkatkan secara umum;
• lebih sering ditemukan kesalahan dan kekurangan yang dapat menjadi jelas hanya pada saat pengoperasian platform.

Karena ketersediaan data tentang jumlah tugas yang diselesaikan dalam sprint dan Story Points yang sesuai, menjadi mungkin untuk menganalisis kecepatan tim pengembangan untuk melakukan perencanaan yang lebih kompeten dan perkiraan waktu di masa depan.

Benar, ada beberapa chagrin dalam kerangka proyek kami dalam hal ini: komposisi tim sangat sering berubah, karena beberapa pengembang secara berkala diambil untuk proyek-proyek yang mendesak, menggantinya dengan yang gratis dari tugas. Karena itu, perkiraan kecepatan disetel ulang setiap kali. Hampir tidak mungkin untuk menghitung dalam kondisi seperti itu. Satu-satunya cara mereka datang adalah dengan mengumpulkan data pada setiap komposisi untuk 3-4 sprint, dan kemudian mencoba mengidentifikasi nilai rata-rata.

"Dan mari cepat" atau 3 aplikasi demo lengkap selama sebulan

Tentu saja, tidak ada yang membatalkan pengembangan aplikasi. Terutama jika mereka diperlukan untuk mencapai tujuan global perusahaan. Apalagi jika sangat dibutuhkan. Dan baru-baru ini, kebutuhan untuk implementasi cepat dari aplikasi demo untuk pertunjukan telah meningkat secara signifikan.

Tentu saja, setelah bekerja dalam paradigma baru, saya tidak ingin kembali ke percakapan lama sama sekali. Kemudian kami memutuskan untuk menggunakan bagian-bagian dari modul visualisasi baru (sebagai sistem yang terintegrasi, itu belum sepenuhnya siap untuk tugas-tugas itu), mengambil prinsip-prinsip pengembangannya sebagai panduan.
Karena belum semua pengembang berada dalam topik alur kerja, dan mengadaptasi orang-orang ke perangkat pengembangan baru adalah risiko besar dalam hal persyaratan demo "pembakaran" kami, kami mencoba untuk menemukan "jalan tengah" tertentu antara masa lalu dan, semoga, masa depan. Akibatnya, inilah yang terjadi dengan sebagian penggunaan prinsip-prinsip modul visualisasi baru pada demo:

1. Tim kecil. 2-3 pengembang, perancang, penguji, dan manajer.
2. Pengembangan paralel (kontrol sebelumnya dibuat terlebih dahulu, lalu templat dengan tampilan dan logika aplikasi).
3. Menggunakan tugas-tugas seperti Story in Jira. Tidak ada spesifikasi dan TK yang jelas, jadi saya mengumpulkan semua informasi yang tersedia tentang perilaku dan penampilan aplikasi yang diharapkan dan memasukkan semuanya ke dalam Story. Kemudian mereka diuji pada mereka, yang menyebabkan reaksi positif di antara penguji, karena semua informasi dikumpulkan di satu tempat, tetapi pada saat yang sama itu dibagi menjadi bagian-bagian fungsional, yang memfasilitasi verifikasi. Dan tim secara keseluruhan tidak harus membaca banyak teks resmi untuk memahami dan menyelesaikan tugas dengan benar. Juga, tidak seperti dokumen Word dengan spesifikasi, Story diperbarui lebih cepat, orang dengan cepat menerima deskripsi dengan penyempurnaan baru dan, karenanya, mulai mengimplementasikannya lebih cepat.
4. Gitflow dengan mengembangkan dan menguasai cabang, tetapi tanpa fitur:

• semua pengembangan dilakukan di cabang pengembangan, tetapi untuk mengecualikan keberadaan tugas yang tidak terdaftar, masing-masing komit harus ditandai dengan kode tugas dari Jira, dalam kerangka yang dilakukan;
• ketika semua tugas yang direncanakan untuk rilis diselesaikan, bangunan baru sedang disusun: seorang pemimpin tim melakukan peninjauan terhadap cabang pengembangan dan, jika semuanya baik-baik saja di sana, perubahan digabung menjadi master dengan penugasan tanda dengan nomor membangun. Jika kesalahan besar dan penyimpangan terungkap selama ulasan, kode dikirim untuk revisi dan hanya setelah dimasukkan dan diperiksa ulang apakah itu masuk ke master.
• build diberi nomor dengan dua digit, misalnya, 0,1 - ini selalu merupakan nomor tes build pertama, di mana 0 - berarti milik versi produksi, 1 - build number. Jadi, dalam jumlah setiap pengujian berikutnya, angka terakhir meningkat, hingga penguji dan manajer memberikan kesimpulan bahwa pengujian tersebut siap untuk produksi. Dengan demikian, jika ini adalah uji bangunan keempat (0,4), maka itu menjadi produksi pertama (1,0) dan tag yang sesuai diletakkan di cabang utama. Jika cacat terdeteksi dalam produksi, dan build produksi dikirim untuk diedit, maka digit kedua juga meningkat ketika penomoran semua build berikutnya (1.1, 1.2, dll.).

Dengan demikian, selama sebulan, kami menerapkan 3 aplikasi demo lengkap, yang kami terima ulasan positif dan yang terus berguna. Sebelumnya, kami tidak dapat mengimplementasikan fungsi seperti itu dengan begitu cepat dan dengan begitu banyak orang di tim.

Menurut pendapat saya yang sederhana

Apa yang saya pikirkan secara pribadi tentang ini?

• Bahwa organisasi proses benar-benar memengaruhi hasil dan bahwa mendengarkan dunia praktik pembangunan, yang diciptakan oleh pengembang sendiri dan berorientasi kepada mereka, bukan hanya "gaya, modis, awet muda", tetapi perlu (setelah melewati demo, untuk pertama kalinya dalam beberapa tahun praktik, kami terus melakukan sisanya. proyek, dan tidak duduk sampai malam 2 minggu setelah melahirkan, berkeringat wajah tumpukan ditemukan oleh pelanggan cacat memalukan).
• Tingkat kekacauan, kesalahpahaman dan tekanan pada proyek dengan alur kerja yang jelas lebih rendah (orang lebih baik dilengkapi dengan informasi yang relevan, mereka tahu di mana mendapatkannya jika perlu).
• Penggunaan alat manajemen proyek yang tepat memengaruhi pengembangan proyek itu sendiri dan partisipannya (karena optimalisasi pengembangan di Gitlab, Jira, pengenalan prinsip-prinsip kelincahan, menjadi mungkin untuk bertukar pengalaman dalam tim, keterampilan memompa dalam tim, lebih sering pengetahuan dan pengalaman para pemimpin tim junior dipindahkan dan pengembang menengah).

Ini rahasianya

Terlepas dari kesimpulan di atas, dan sesuatu yang lain menjadi jelas bagi saya:

- Tidak semua orang siap untuk apa yang mereka impikan.

Terkadang, ketika kita mengamati sesuatu dari samping, tampak bagi kita bahwa ini adalah sesuatu yang baik, berguna, diperlukan untuk keberhasilan, koreksi dan referensi. Tetapi mimpi itu layak menjadi kenyataan, seperti yang kita pahami: "Ini bukan yang saya bayangkan." Jadi dalam pekerjaan: tampaknya sekarang memberi Anda kondisi seperti di mana "perusahaan normal" bekerja, dan Anda akan berkembang. Tapi sayang sekali. Dan kebetulan Anda, tanpa energi, mencoba memberi orang sesuatu yang mereka impikan sebagai jaminan kesuksesan, tetapi keajaiban tidak terjadi: pekerjaan masih belum dilakukan dalam kualitas tinggi, dan Anda mengerti bahwa Anda mungkin telah menerima tipikal seseorang kata-kata dukungan untuk percakapan dapur untuk aspirasi dan impian nyata.

Jadi dalam proses memperkenalkan aturan dan prinsip baru, kami dihadapkan tidak hanya dengan umpan balik dan hasil yang positif, tetapi juga dengan persepsi negatif tentang apa yang terjadi. Bagi sebagian orang, bekerja dengan Jira dan Gitlab tampak seperti banyak keributan, dan mengubah persepsi ini sangat sulit sampai orang menemukan situasi bermasalah yang terjadi karena mengabaikan alur kerja yang diterima secara umum. Beberapa tugas masih dilakukan dengan ceroboh, deskripsi dalam cerita dan definisi tugas tidak diperhitungkan atau dianggap sebagai "permintaan pribadi" dan tidak dilakukan, meskipun mendaftar dengan Jira dengan pernyataan yang jelas.Secara umum, build dengan kualitas implementasi yang buruk atau implementasi yang tidak sesuai masih muncul, dan beberapa bug dibuka kembali dari build to build. Meskipun hasil akhirnya positif di semua demo, saya masih memikirkan fakta bahwa dengan orang-orang yang bertanggung jawab atas pekerjaan, yang peduli untuk memberikan hasil setinggi mungkin, kami berhasil tidak hanya mengimplementasikan fungsionalitas yang diperlukan, tetapi juga memperkenalkan fitur-fitur baru, mengoptimalkan aplikasi dan "Tambahkan ryushechek." Dan dengan tim di mana seseorang mampu menjadi terlalu malas atau kurang tertarik untuk mencapai hasil kualitas tertinggi, kami hanya menerapkan fungsionalitas dasar dan beberapa fitur kecil atas permintaan tambahan pelanggan setelah pengiriman.

Dan kemudian, mungkin, kesimpulan saya yang paling penting datang kepada saya:

- Bukan proses, bukan teknologi - kunci keberhasilan yang sesungguhnya, tetapi mereka yang menciptakan, menciptakan, mewujudkan ide menjadi kenyataan - orang dan sikap mereka terhadap pekerjaan mereka. Seorang musisi yang menempatkan jiwanya ke dalam karyanya akan mempengaruhi penonton, bahkan memainkan instrumen yang paling murah dan paling tidak nyaman. Dan beri dia Stradivari - dia akan membuat penonton gila. Dan ada orang-orang yang bahkan Stradivarius, setidaknya memberikan perkembangan terbaru dari produsen alat terkemuka - semuanya akan terdengar tidak penting.





Anda dapat memberi orang kondisi yang nyaman dan teknologi terbaik, tetapi pada akhirnya mendapatkan hasil yang tidak memuaskan dari aktivitas mereka, karena "dan begitulah seterusnya." Dan itu mungkin, jika tidak ada yang paling sukses, dan kadang-kadang bahkan menghambat implementasi yang kompeten, teknologi, Anda bisa mendapatkan hasil yang layak, karena mereka yang mencapainya tidak mampu menyerahkan pekerjaan yang belum selesai atau yang dilakukan dengan buruk. Dan sangat penting untuk membedakan, mendukung anggota tim seperti itu, untuk dapat mendengarkan mereka dan menciptakan kondisi yang menguntungkan untuk kegiatan mereka.

Teknologi dan organisasi proses benar-benar berdampak pada hasil dan sangat penting, tetapi kunci utama kesuksesan adalah pada orang-orang yang berbakat, bertanggung jawab, dan berorientasi pada pengembangan.