Suatu ketika mandor berdiskusi dengan pelanggan potensial tentang renovasi rumah kecil. Pemilik rumah khawatir dindingnya miring. Rumah itu dibangun dari batu bata, dinding batunya hanya berdiri di atas tanah. Penopang kayu diperkuat di sekeliling sekeliling rumah, tetapi dindingnya masih berusaha runtuh.
- Rumah Anda rusak, rekonstruksi diperlukan, - kata mandor. - Kami akan meregangkan kabel listrik untuk menyalakan peralatan, menggali lubang, membuat drainase, mengisi fondasi ... - Tidak, tidak! - pemilik rumah menyela dia, - Saya tidak membutuhkan lubang pondasi, saya perlu dinding! House! - Dalam hal ini, mungkin Anda akan berpikir untuk membeli rumah modular? - menyarankan mandor.
Saya berbicara dengan sebuah startup bulan lalu. Dia memiliki layanan web yang berfungsi yang telah ditulis oleh berbagai orang selama beberapa tahun, dan sekarang manajemen sedang memikirkan apa yang harus dilakukan dengannya. Para pendiri memberi tahu saya tentang keinginan mereka untuk menyewa tim yang terdiri dari sepuluh pengembang untuk menulis ulang atau memodernisasi aplikasi. Saya bertanya kepada mereka tentang kisah pengguna, dokumentasi, pelacak masalah, dan mereka menjawab bahwa mereka tidak memilikinya. Mereka meminta daftar apa yang saya sarankan untuk mereka lakukan, dan saya menulis ini:
Buat daftar parameter utama yang memengaruhi penjualan: SLA, fungsionalitas, apa pun yang mengikat tugas virtual ke dunia nyata.
Tentukan konteks DDD dan buat dokumentasi tingkat tinggi untuk membahas arsitektur dan membantu pengembang baru merasa nyaman dengan proyek tersebut.
Identifikasi kemacetan sistem yang menyebabkan masalah penskalaan dan ketersediaan.
Selaraskan tujuan jangka menengah tim TI dengan manajemen senior.
Buat alur kerja berdasarkan alat interaksi tim seperti papan, pelacak, messenger, repositori.
Atur proses perekrutan dan bergabung dengan proyek pengembang baru.
Buat sistem pemantauan dan cadangan.
Buat penguraian tugas jangka menengah secara bertahap dan tulis jadwal.
Buat CI / CD.
Tulis rencana perubahan arsitektur.
Prioritaskan tugas di backlog.
IT- .
, , . . , , .
.
, : , , , , , . , , - , IT- - , . . , , - . - , . . , , , . Oracle. : , , — , , , , , , , . , -, , . Oracle corp, .
- - . , . , - . , .
- , . .
- , IT-. - , , , , .
, , , , , code review, , - . SLA - , .
. . , , . . . - , , , . . , , . , - .
, , - , MVP. , . , , . - , .
, , . - , .
(CI/CD) . , , . CI/CD - . , . . git. CI/CD - , , QA , , , . , . , , .
- , , . . . . , . , .
-, . SCRUM planning-. . - . , . , , .
, , , , , - . .
, -? , " Wordpress, 38% - ». . SAAS, outsource. , IT. , , . , , , -, , , , , .
Bagaimana jika Anda hanya menulis kode tanpa rencana, tes, pelacak - panggil saja dan diskusikan sepanjang jalan? Mungkin pengembang akan memahami masalah dengan benar dan menulis solusi yang benar, atau mungkin mereka harus berganti pengembang beberapa kali dan menulis ulang aplikasi beberapa kali. Perbedaannya terletak pada prediktabilitas hasil.