Siklus hidup perangkat lunak diketahui oleh sebagian besar programmer modern.
Bahkan seorang anak sekolah menulis program pertamanya
<?php echo "Hello, ! " ?>
atau
fprintf( ' !\n');
mengerti prosesnya.
- Memikirkan tugas - tahap ide
- Dia memikirkan tugas dan bagaimana hal itu perlu dilaksanakan - Analisis dan elaborasi persyaratan,
membangun model perangkat lunak dan rencana implementasi. Singkatnya, panggung arsitektur. - Pemrograman
- Pengujian. "Apa yang terjadi di sana"
- Operasi
Antara tahap 1-5, kami terus berinteraksi proses.
Untuk ini, ada semua jenis Air Terjun, Scrum, dll.
Jadi masalahnya, ketika proyek Anda mengembang ke beberapa jenis frontend,
seperti yang dibutuhkan dunia TI modern, pelanggan ingin memaksimalkan audiens untuk memaksimalkan keuntungan mereka sendiri.
Dan untuk alasan ini, kita semua mengamati banyak proyek di mana ada beberapa jenis antarmuka yang berinteraksi melalui API dengan backend terpusat.
Secara umum, "proyek kuat standar" memiliki tiga jenis bidang:
- Situs
- Aplikasi seluler di Android
- Aplikasi seluler iOS
Dengan satu API yang dikembangkan untuk bertukar data melalui REST.
Contoh yang baik yang akan saya andalkan adalah media sosial (lihat artikel saya sebelumnya tentang pemutar Anda sendiri berdasarkan video YouTube)
Sebuah proyek besar memiliki tiga opsi untuk mendapat untung atau kriteria apa pun itu
bersyarat web, apel dan android.
Lebih mudah bagi programmer untuk berinteraksi dengan arsitektur backend yang tersentralisasi dan berkonsentrasi pada bidang pribadi mereka, yang sedang mereka kembangkan.
Dan di sini sorot artikel muncul.
Faktanya adalah bahwa pada tingkat atas pengambilan keputusan di antara atasan
fitur baru terbentuk, yang menuju ke belakang. Tapi karena "bos" adalah orang yang tidak sempurna,
maka dia harus menurunkan kekuatannya ke tingkat yang lebih rendah.
Oleh karena itu, dalam kasus kami, sebagai suatu peraturan, di atas setiap front di sana juga muncul kepala "tingkat rendah" sesuai dengan alasan hierarkis atau formal. Sesuatu
jenis timlides untuk kesederhanaan.
Dan tugas mengembangkan proyek besar dalam bentuk semacam "siklus hidup pengembangan"
dan operasi perangkat lunak dibagi ke dalam siklus hidupnya.
Dan muncul pertanyaan dalam menyinkronkan proses siklus hidup "mini", karena jika Anda lebih dulu, misalnya, pengembang web dari fitur baru, Anda harus menunggu pengembang seluler.
Kalau tidak, makna fitur baru itu hilang dalam prioritas, karena kita semua sekarang di web dan di aplikasi seluler dari telepon pintar.
Mari kita pikirkan bagaimana cara mengevaluasi pengenalan fitur-fitur baru untuk meminimalkan sumber daya manusia dalam situasi seperti itu.
Di sini saya akan menyuarakan tesis:
- Saat menerapkan fitur di salah satu front, kita perlu memperhitungkan siklus front lainnya, atau stub standar program, sehingga nantinya kita bisa "mengejar" fitur front lainnya dan bahkan keluar.
- Anda dapat membangun skema untuk siklus pengembangan perangkat lunak secara keseluruhan sehingga setiap orang akan kondisional melakukannya dengan baik, maka fitur tersebut akan dilaksanakan tepat waktu, tetapi setidaknya independensi tim front-end di antara mereka sendiri akan hilang - maka umpan dan gesit untuk seluruh sistem kehilangan relevansinya, atau menambah waktu iterasi dengan pengembangan. Singkatnya, lebih banyak obrolan akan terjadi dan kode ini ditulis lebih lambat.
- Front terisolasi, pada prinsipnya, lebih cepat, tetapi lebih banyak pengujian integrasi manusia-biaya diperlukan.
- Skema yang saat ini sedang diterapkan - masing-masing front dikembangkan secara terpisah dan independen satu sama lain dengan interaksi minimum, tetapi di sini beberapa dasar-dasar TI hilang - kita akan mendapatkan sekelompok pengguna yang bukan nol yang terkadang melihat bug.
Di sini filosofi pertanyaannya adalah bahwa pengguna tidak suka bug menurut definisi. Dan pelanggan berusaha untuk memaksimalkan keuntungan, sehingga komplikasi besar dari sistem entah bagaimana akan memperlambat maksimisasi itu, karena ini adalah proses akhir-siklus hidup dari perangkat lunak.
Dalam proyek yang lebih kecil, proses ini bahkan lebih buruk - banyak pelanggan memberikan pengembangan ponsel ke situs jarak jauh, meskipun back-end dan web dilakukan sendiri, dan secara teratur menerima pengereman yang seragam pada implementasi fitur.
Di sisi lain, ada hambatan berbahaya untuk otomasi formal dari proses implementasi - itu adalah kebiasaan di antara pengembang untuk bertanya kepada pengguna tentang bergulir pembaruan, jadi dalam mode diam itu tidak akan bekerja untuk menggulingkan perubahan tanpa persetujuan.
Ide saya adalah ide seperti itu - sambil mempertahankan jenis utama siklus hidup dan memiliki subtipe dalam hal ini front independen, Anda perlu mengingat satu prioritas
jenis depan (untuk uang, alasan historis atau lainnya), tetapi mereka harus menjadi unit di bawah jenis siklus tingkat yang lebih tinggi.
Yaitu, jika front web prioritas bekerja pada scrum mingguan, maka scrum dalam pada front mobile harus memiliki scrum ganda pertama, dua minggu, jika tidak
kebingungan akan dimulai. Tetapi meluncurkan versi besar umum dari front harus dilakukan pada saat yang sama, jika tidak, Anda akan memiliki penulis artikel yang menulis ini. Mari kita pikirkan ...