Adakah praktik terbaik terkait serah terima dari arsitektur ke pembangunan?

Kami sedang mencari cara meningkatkan proses penyerahan tugas dari arsitektur ke pengembangan.

Pada satu ujung skala itu tidak ada panduan arsitektur Anda berisiko mendapat kekacauan, dengan setiap pengembang melakukan sesuatu dengan caranya.

Di ujung lain dari skala di mana semuanya ditentukan, spesifikasi membutuhkan waktu lebih lama daripada pengembangan, dan Anda berisiko memiliki tugas pengembangan yang sangat membosankan.

Adakah yang menemukan jalan tengah yang optimal di antara yang ekstrem ini? Artefak apa yang Anda hasilkan untuk pengembangan? Sebagai contoh: modul, struktur kelas, atau diagram urutan?

Saya akan memulai dengan mengatakan bahwa konsep tim "Arsitektur" yang terpisah merupakan penghinaan terhadap praktik pengembangan perangkat lunak yang baik. Tim arsitektur di lingkungan perusahaan cenderung menjadi puncak dari seniman pseudo-intelektual gading-menara terburuk * * yang dapat ditemukan di antara kumpulan pengembang.

Organisasi lain memperlakukan kelompok Arsitektur seperti imbalan politik dan pembenaran untuk gaji besar kepada anggota paling senior terlepas dari prestasi, pengetahuan atau keterampilan. Sebagian besar terdiri dari kedua jenis.

Setiap pengembang dapat dan harus menjadi arsitek dan harus terlibat dalam desain tingkat tinggi perusahaan. Pemikiran bahwa satu kelompok memiliki kontrol diktatorial lengkap atas setiap aspek desain perangkat lunak dan yang harus diserahkan kepada pengembang yang tidak berkontribusi pada desain, tidak memahami alasan di balik pilihan desain, dan mungkin memahami kelemahan kritis dalam desain menjadi lebih nyaman dan lebih dekat dengan implementasi aktual dan kode yang ada, terus terang sepenuhnya cacat dari intinya, dan secara konsisten akan menghasilkan salah satu dari tiga skenario:

• Pengembang tidak memahami desain, atau langsung menolaknya karena realitas implementasi saat ini, dan akhirnya menentukan desain sendiri yang tidak berdokumen dan mengimplementasikannya. Situasinya adalah dokumen desain formal yang tidak mencerminkan implementasi perangkat lunak.

• Para pengembang secara membabi buta mengikuti desain yang mungkin atau mungkin tidak mempertimbangkan persyaratan saat ini atau aspek unik dari cerita pengguna menjadi pertimbangan, menghasilkan implementasi yang buruk dan berkualitas buruk.

• Pengembang cerdas yang memahami dokumen desain, dan mampu mengimplementasikannya, cepat bosan karena tidak terlibat dalam diskusi desain. Mereka kemungkinan dikecualikan dari berpartisipasi dalam kelompok Arsitektur karena masalah politik atau senioritas, sehingga mereka menjadi frustrasi, bosan, dan pergi ke padang rumput yang lebih hijau. Hal ini berdampak negatif pada proyek yang mengakibatkan pengeringan otak yang menyebabkan siklus setan kualitas perangkat lunak yang buruk terus berlanjut.

Satu-satunya cara terbaik untuk mengurangi masalah ini adalah MENGUBAH kelompok Arsitektur dan mungkin menempatkan mereka pada posisi pemimpin teknologi. Peran kelompok Arsitektur harus lebih atau kurang sebagai "scrum of lead teknologi" jika Anda mau. Mereka jarang bertemu dan hanya membahas masalah arahan teknis tingkat tinggi, Eg. pikir diskusi bermigrasi dari Jawa ke Scala, Meninggalkan Oracle untuk MySQL, mungkin menulis perpustakaan utilitas umum yang mengamanatkan TIPE tertentu dari proses desain di atas yang lain, beralih dari StarUML ke Altova UML.

Desain perangkat lunak aktual dan nyata akan menjadi proses komunitas yang melibatkan SEMUA pengembang perangkat lunak, yang ditata oleh arahan tingkat tinggi dari kelompok Arsitektur.

Selalu ada masalah dalam bagaimana informasi dialirkan dari arsitektur ke uji pengembangan dan operasi. Cara mengatasi masalah-masalah ini tergantung pada beberapa faktor seperti:

• ukuran perangkat lunak
• kompleksitas
• budaya di organisasi Anda
• keyakinan.

Untuk kombinasi tertentu dari faktor-faktor ini pendekatan tangkas murni tim lintas fungsional dengan desain yang muncul adalah tepat. Informasi mengalir dengan bekerja bersama. Disiplin mendokumentasikan apa yang mereka butuhkan.

Untuk kombinasi lain dari faktor-faktor ini tim kecil arsitek, penguji, ahli operasi dan pengembang utama mungkin mulai dengan iterasi arsitektur perlahan membangun arsitektur, mendokumentasikan dan mendapatkan umpan balik langsung pada keputusan arsitektur mereka. Perlahan lebih banyak pengembang yang mengimplementasikan fitur dapat ditambahkan ke tim dan tim inti asli dapat dibuat lebih kecil.

Sebagian besar untuk proyek-proyek pemerintah dan keuangan disyaratkan bahwa lebih banyak dokumentasi ditulis di muka dan yang dapat memakan waktu lama tanpa umpan balik dunia nyata pada pilihan Anda. Dalam pikiran saya alasan terbesar mengapa banyak dari proyek ini gagal. Masih jika ini situasi Anda, saya akan membuat dokumentasi agar sesuai dengan persyaratan Dan daripada menggunakan opsi 1 atau 2 untuk benar-benar membangun perangkat lunak dan memperbaiki / menyesuaikan dokumentasi.

Semoga ini membantu.

Saya tahu ini tidak akan terlalu populer tetapi komentar yang Anda buat

Di ujung lain skala jika semuanya ditentukan, spesifikasi membutuhkan waktu lebih lama daripada pengembangan. Dan Anda berisiko memiliki tugas pengembangan yang sangat membosankan.

sebenarnya adalah sesuatu yang harus Anda perjuangkan. Jika desain dan spesifikasinya cukup solid sehingga tugas pengembangannya membosankan, maka biaya pengembangan turun. Ini jauh lebih murah untuk memperbaiki spesifikasi daripada memperbaiki kode, dan biaya terbesar dari proyek perangkat lunak bukan membangun, itu adalah dukungan jangka panjang. Dan kode pendukung yang didasarkan pada spesifikasi solid jauh lebih murah.

Saya tidak sepenuhnya setuju dengan jawaban maple_shaft, tetapi tidak ada cukup ruang di komentar untuk mengatakan seluruh bagian saya! ;-)

Saya setuju bahwa setiap pengembang dapat dan harus menjadi arsitek, tetapi itu tidak berarti bahwa setiap pengembang harus bertanggung jawab atas arsitektur seluruh produk atau sistem. Lebih lanjut, saya tidak berpikir Anda bisa melukis setiap tim arsitektur dengan sikat luas yang sama, dan ketika dilakukan dengan tepat tim arsitektur dapat memberikan nilai besar untuk keseluruhan proses pengembangan produk. Kesalahpahamannya adalah bahwa arsitek harus menentukan setiap aspek dari desain sistem. Sebagai gantinya mereka harus fokus pada desain tingkat yang lebih tinggi, dan menyerahkan detail implementasi kepada tim pengembangan mereka. Namun itu tidak berarti bahwa pengembang tidak boleh terlibat dalam proses perencanaan dan desain sejak awal.

Semakin besar dan semakin modular dan semakin kompleks suatu produk, semakin besar kemungkinan Anda akan menemukan berbagai bagian produk yang ditangani oleh tim pengembangan yang berbeda. Tim semacam itu tidak perlu memahami sistem secara keseluruhan asalkan mereka memiliki pemahaman penuh tentang bagian-bagian dari sistem yang menjadi tanggung jawab mereka. Seringkali tim tambahan ini dibawa sebagai subkontraktor untuk tujuan spesifik mengembangkan modul dalam bidang teknologi tertentu yang mungkin tidak dimiliki oleh arsitek atau tim lain. Bakat khusus saya terletak pada pengembangan API, dan saya belum melihat API berfaktor baik yang dikembangkan sepenuhnya secara organik tanpa menjadi kekacauan sepenuhnya dalam hal kegunaan, atau yang tidak mengharuskan seseorang untuk menonjol karena orang yang memastikan ada tingkat keseragaman antara berbagai aspek API. Saya dapat melanjutkan untuk mendaftar banyak contoh dan alasan, tetapi saya tidak berpikir bahwa situasi semacam ini adalah menara gading BS yang mungkin banyak orang pikirkan. Sayangnya, ada banyak tempat, khususnya di bidang pertahanan, medis, dan sektor keuangan di mana paranoia korporat menghasilkan pengembangan produk yang tidak ditentukan dengan baik dan bahkan lebih buruk dari jenis yang saya yakin maple_shaft paling peduli. Ini adalah hal-hal yang saya percaya memberi arsitek sedikit nama buruk yang tidak layak (secara umum). Sayangnya, ada banyak tempat, khususnya di bidang pertahanan, medis, dan sektor keuangan di mana paranoia korporat menghasilkan pengembangan produk yang tidak ditentukan dengan baik dan bahkan lebih buruk dari jenis yang saya yakin maple_shaft paling peduli. Ini adalah hal-hal yang saya percaya memberi arsitek sedikit nama buruk yang tidak layak (secara umum). Sayangnya, ada banyak tempat, khususnya di bidang pertahanan, medis, dan sektor keuangan di mana paranoia korporat menghasilkan pengembangan produk yang tidak ditentukan dengan baik dan bahkan lebih buruk dari jenis yang saya yakin maple_shaft paling peduli. Ini adalah hal-hal yang saya percaya memberi arsitek sedikit nama buruk yang tidak layak (secara umum).

Jadi di mana jalan tengah yang dicari OP? Jawabannya semua ada hubungannya dengan membuka saluran komunikasi. Arsitek perlu menyerahkan spesifikasi yang menggambarkan desain mereka secara cukup rinci untuk memastikan tim pengembangan akan memahami di mana batas-batasnya. Cerita dan Skenario Fitur dalam arti luas, di mana semuanya dianggap sebagai kotak hitam. Arsitek kemudian perlu memastikan bahwa tim memiliki akses ke waktu arsitek untuk mengkonfirmasi asumsi, dan untuk memiliki pertanyaan yang dijawab tentang spesifikasi yang tampak terlalu luas, atau tidak jelas. Setelah itu, ini benar-benar tentang memastikan bahwa masing-masing tim disadarkan tentang apa yang sedang dikerjakan oleh tim lain, dan bahwa mereka tahu siapa yang harus bekerja sama dengan tim lain untuk memastikan setiap bagian dari sistem akan bermain dengan baik dengan bagian lainnya. Tim-tim ini saling bertemu secara langsung. Setelah sistem dirancang pada tingkat terluas, arsitek harus benar-benar menjadi orang-orang yang dituju oleh tim ketika mereka membutuhkan pemeriksaan kewarasan, dan untuk memastikan bahwa "visi" produk tetap terjaga. Mereka juga harus ikut serta dalam proses integrasi apa pun yang diperlukan, dan memberikan "penutup udara" yang sangat dibutuhkan untuk tim pengembangan dari para manajer, pelanggan, dan pemegang saham lainnya, sambil tetap memastikan berbagai orang ini dapat berkumpul bersama untuk bekerja di antara mereka bagaimana hal-hal seharusnya bekerja.

Arsitek IMHO harus menjadi fasilitator & komunikator pertama dan terutama, dan desainer kedua. Seperti apa tingkat spesifikasinya? Saya pikir arsitek terbaik adalah mereka yang bertanya kepada tim mereka tentang tingkat detail yang diinginkan tim, dan di antara mereka menemukan keseimbangan yang berfungsi. Tim yang berbeda mungkin memiliki persyaratan berbeda dalam hal jumlah dokumentasi atau arahan yang diperlukan. Tim senior mungkin menemukan diagram yang digambar secara kasar dan obrolan cepat mungkin cukup untuk memulai, sementara tim yang diisi dengan pengembang yang relatif junior mungkin memerlukan sedikit lebih banyak untuk membuatnya berjalan. Di atas segalanya, arsitek perlu mendorong pengembang untuk menggunakan bakat desain mereka sendiri untuk mendapatkan hasil akhir terbaik dari masing-masing tim.

Karena Anda berusaha untuk meningkatkan sesuatu, maka Anda sudah merasakan masalah dalam proses Anda. Penyebab utama untuk situasi tertentu mungkin adalah sebagai berikut: Pengembang tidak dapat mengidentifikasi diri mereka dengan arsitektur, karena itu dipaksakan kepada mereka oleh seseorang dari luar. Menyerahkan arsitektur untuk pengembangan kemungkinan besar tidak akan menyelesaikan akar permasalahan ini.

Jadikan arsitektur bagian dari tim pengembangan. Runtuhkan perbatasan antara arsitek dan pengembang. Ini memastikan bahwa informasi akan mengalir. Jika tim pengembangan berpartisipasi dalam membentuk arsitektur mereka tidak akan menganggapnya sebagai sesuatu yang asing. Menanamkan pengetahuan tentang arsitektur ke dalam tim. Ajari mereka faktor-faktor pendorong di balik arsitektur perusahaan untuk menghindari kekacauan yang Anda sebutkan. Libatkan pengembang ketika keputusan arsitektur harus dibuat untuk menghindari kebosanan yang Anda sebutkan. Serah terima tidak diperlukan lagi dan Anda telah memenuhi peran Anda sebagai arsitek dalam tim pengembangan.

Anda perlu memberikan informasi sebanyak mungkin untuk tim di masa depan untuk menjaga kode. Jika Anda tidak memiliki diagram urutan misalnya, pengembang dipaksa untuk melacak kode langkah demi langkah, sehingga membuang waktu.

Juga ada ruang bagi tim baru untuk membuat asumsi yang tidak valid.

Secara umum harus ada dokumen tentang apa proyek itu, spesifikasi teknis, kasus uji unit dan diagram urutan / kelas.

Saya akan mengatakan bahwa pandangan diagram Kelas membuat model serta kode adalah solusi. Diagram kelas mewakili tampilan statis arsitektur proyek Anda. Maksud saya, Anda memiliki paket> kelas, intefaces, enum> atribut, mehtods dll ...> dll. Jika Anda terlihat baik, metamodel UML2 memiliki struktur yang persis sama dengan proyek java atau dotnet.

Apa yang kami gunakan dalam proyek kami hanyalah diagram kelas yang disimpan ke dalam satu model. Kami menghasilkan tampilan model jika classifier sudah ada atau membuat yang baru di grafis jika itu baru. Pengembang dapat melihat diagram dan model kami karena disimpan di root folder proyek di dalam CVS. Apa yang saya suka adalah bahwa pengembang juga dapat memodelkan karena jika ada perubahan pada level kode maka model secara otomatis diperbarui pada CVS untuk seluruh tim.

Ini bekerja dengan sangat baik dan tidak perlu tahu UML karena diagram kelas sangat sederhana dan rekayasa balik akan melakukan pekerjaan dan membuat tampilan grafis dari kode. Navigasi sederhana, tampilan lanjutan dan terperinci di mana banyak komentar dapat ditambahkan dengan diagram yang selalu terkini dan terlihat di CVS langsung di proyek. Diagram kelas UML saya sekarang adalah Magic :-)