Bagaimana desain arsitektur dilakukan di lingkungan yang gesit?

Saya telah membaca Principles for the Agile Architect , di mana mereka mendefinisikan prinsip-prinsip selanjutnya:

Prinsip # 1 Tim-tim yang memberi kode sistem merancang sistem.
Prinsip # 2 Bangun arsitektur paling sederhana yang mungkin bisa berfungsi.
Prinsip # 3 Jika ragu, buat kode.
Prinsip # 4 Mereka membangunnya, mereka mengujinya.
Prinsip # 5 Semakin besar sistem, semakin lama landasannya.
Prinsip # 6 Arsitektur sistem adalah kolaborasi peran.
Prinsip # 7 Tidak ada monopoli dalam inovasi.

Makalah ini mengatakan bahwa sebagian besar desain arsitektur dilakukan selama fase pengkodean, dan hanya desain sistem sebelum itu. Ini baik saja.

Jadi, bagaimana desain sistem dilakukan? Menggunakan UML? Atau dokumen yang mendefinisikan antarmuka dan blok utama? Mungkin sesuatu yang lain?

Disclaimer: Saya saya seorang arsitek di lingkungan lincah tapi, sebagai Helmuth von Moltke Elder mengatakan, "Tidak ada rencana pertempuran bertahan kontak dengan musuh". Dengan kata lain, kepraktisan berarti bahwa huruf yang tepat dari pedoman tidak selalu dapat diikuti.

Sebagian besar poin yang diangkat di atas diikuti sebaik mungkin oleh tim. Namun, prinsip 1 (Tim yang memberi kode pada sistem merancang sistem) benar-benar sulit untuk diikuti ketika tim terdiri dari puluhan (atau ratusan) pengembang yang terbagi di berbagai benua dan zona waktu . Ini tidak ada hubungannya dengan keterampilan atau sikap pengembang, lebih dari masalah logistik mereka semua hadir untuk mengumpulkan persyaratan dari pelanggan dan memahami sistem kompleks yang ada.

Jadi, bagaimana desain sistem dilakukan? Menggunakan UML? Atau dokumen yang mendefinisikan antarmuka dan blok utama? Mungkin sesuatu yang lain?

Seringkali arsitek mengidentifikasi komponen utama kemudian mendefinisikan antarmuka di antara mereka (termasuk persyaratan non-fungsional seperti keamanan, kecepatan dan keandalan) dan mendelegasikan desain internal komponen ke tim individu . Ini adalah kompromi yang baik antara membiarkan tim mendesain komponen mereka sendiri tanpa mengharuskan semua orang tahu segalanya tentang sistem.

Setiap organisasi memiliki seperangkat standar sendiri untuk desain arsitektur dan ini kadang bervariasi dari proyek ke proyek di dalam organisasi. Desain ini dilakukan sebelum tim memulai pengkodean atau sedini mungkin dan biasanya berisi (dan bukan daftar lengkap):

1. Persyaratan yang diperluas dan definisi ruang lingkup. Ini termasuk kasus penggunaan atau kisah pengguna yang menyempurnakan persyaratan bisnis tingkat yang lebih tinggi. Saya pribadi suka menggunakan RFC 2119 untuk persyaratan non-fungsional. Desain didasarkan pada dan ditelusuri kembali ke ini. Meskipun mungkin tidak sesuai dengan definisi umum desain, ini sering sama pentingnya.
2. Gambaran umum yang terdiri dari jaringan tingkat tinggi atau diagram komponen dan halaman teks. Ini untuk khalayak yang sangat luas, dari manajemen tingkat atas hingga dev dan QA. Ini jarang menggunakan UML atau notasi yang ditentukan karena khalayak luas.
3. Detail untuk masing-masing komponen, seringkali berfokus pada antarmuka atau API di antara mereka seperti yang disebutkan di atas. Antarmuka dapat ditentukan sebagai tanda tangan metode dalam bahasa target dengan rincian prekondisi dan pascakondisi. Komponen mungkin memiliki diagram jaringan, seperti menunjukkan tata letak VM di cloud atau pusat data dan pengaturan jaringan mereka. Database relasional biasanya akan memiliki diagram Entity-Relationship.
4. Daftar risiko arsitektur dan mitigasinya, jika diketahui. Seperti persyaratan, ini menunjukkan keputusan desain dan pertukaran.

Singkatnya, desain sistem dalam proses gesit persis sama dengan yang ada dalam proses air terjun tradisional. Namun, dalam lingkungan yang gesit, kurang dari desain dilakukan di muka dan lebih banyak dari itu didelegasikan ke tim komponen . Kuncinya adalah menentukan seberapa dalam pada awalnya, keputusan mana yang harus ditunda dan identifikasi kapan keputusan perlu dibuat. Keputusan yang memengaruhi banyak tim pengembangan harus dibuat lebih awal, terutama skalabilitas dan keamanan. Keputusan seperti menambahkan bahasa tambahan ke produk yang sudah diinternasionalkan dapat ditunda hingga sangat terlambat.

Setelah desain awal dibuat, arsitek bekerja dengan masing-masing tim dan meninjau desain mereka. Jika desain tambahan atau perubahan desain diperlukan untuk suatu unit kerja (seperti scrum sprint), arsitek bertujuan untuk menyediakannya pada saat unit kerja dimulai. Arsitek juga bertanggung jawab untuk mengkomunikasikan perubahan apa pun kepada tim atau pemangku kepentingan yang terkena dampak.

Penafian: Saya bukan pelatih / arsitek lincah - inilah yang saya lihat dalam proyek lincah yang saya kerjakan dan saya pikir itu bekerja dengan baik.

Saya tidak berpikir itu cukup ditentukan oleh Agile bagaimana Anda melakukan arsitektur - lincah berfokus pada metodologi dan praktik pengembangan. UML di sisi lain hanyalah bahasa untuk mengkomunikasikan arsitektur Anda yang sangat lincah (Anda menggunakannya jika sesuai dengan proyek Anda dan tim Anda).

Salah satu prinsip arsitektur yang benar-benar berlaku, adalah mengambil keputusan pada saat yang paling bertanggung jawab yang terakhir - artinya tidak masalah jika Anda belum mengambil semua keputusan di awal proyek, terutama karena Anda memiliki sedikit informasi pada tahap ini. Seiring waktu, Anda dapat mengambil keputusan yang "mengembangkan" arsitektur. Ya, ini mungkin terlihat seperti pengerjaan ulang, tetapi ini juga disebabkan oleh fakta bahwa Anda telah mempelajari hal-hal baru tentang lingkungan, persyaratan, apa yang mungkin tidak, dll.

Hal utama yang akan Anda ingin menghindari adalah arsitektur busuk - di mana kode ini tidak benar-benar sesuai dengan setiap arsitektur tertentu dan hanya berantakan kusut. Perbedaan utama dibandingkan dengan mengembangkan arsitektur, adalah bahwa dalam arsitektur yang terakhir, Anda mengambil keputusan sadar secara berkala dan mendokumentasikannya dengan alasan yang jelas, lalu menindaklanjuti untuk memastikan kode Anda mengikutinya.

Saat melakukan pengembangan yang didorong oleh tes, Anda membuat kode tes yang menguji modul Anda secara terpisah (= independen dari modul lain mungkin)

Untuk memudahkan pembuatan kode pengujian, Anda memperkenalkan antarmuka ke modul lain yang dapat dengan mudah diejek.

Dengan cara ini sebagai sisi mempengaruhi Anda secara otomatis mendapatkan arsitektur di mana sambungan antara modul sekecil mungkin.

Menurut saya tdd juga karya arsitektur.