Desain di satu tim, coding di tim lain

Saya akan terlibat dalam proyek di mana semua desain perangkat lunak dibuat oleh tim lokal dan desain ini dikirim ke tim lepas pantai untuk pengkodean.

Ini adalah pertama kalinya saya menghadapi proyek dengan karakteristik ini dan bagi saya rasanya agak aneh: Para manajer mengharapkan kita untuk membuat dokumen desain yang sangat rinci sehingga tidak ada ruang untuk kesalahan bagi tim lepas pantai; dari sudut pandang saya mereka membuat kita mengkode dalam kertas sementara kita bisa melakukannya dalam IDE.

Jadi, pertanyaan saya adalah apakah pendekatan ini baik, atau terbukti benar? Apa pertimbangan utama yang harus dimiliki oleh proses perangkat lunak kita agar berhasil dalam proyek kita?

Pendapat saya:

Jika semua yang Anda berikan kepada orang-orang lepas pantai adalah dokumen dan diagram, Anda akan memiliki banyak miskomunikasi dan kekecewaan .

Rekomendasi saya

• Jangan memberi mereka begitu banyak dokumen, melainkan antarmuka dan kelas abstrak untuk mengikat mereka ke dalam tujuan desain Anda .

• Mengharuskan mereka menggunakan standar penamaan yang dikenal.

• Meminta mereka untuk menggunakan tes unit.

• Kirim salah satu desainer / arsitek Anda ke luar negeri ke tempat mereka untuk mengawasi prosesnya, itu masih akan lebih murah daripada pengkodean di rumah, tetapi Anda akan mendapatkan hasil yang lebih baik.

Ini disebut Big Design Up Front, alias Waterfall. Itu tidak secara luas dianggap sebagai metodologi yang sangat sukses. Tetapi saya telah melihatnya bekerja, dan ketika itu bekerja, ia bekerja dengan sangat baik. Sangat mahal untuk melakukannya dengan benar.

Ini juga yang diminta oleh majikan Anda.

Tim lepas pantai tidak bekerja seperti yang dilakukan tim darat. Anda harus sangat, sangat spesifik tentang apa yang Anda inginkan, jika tidak, Anda tidak akan mendapatkan yang Anda inginkan.

Proyek terakhir saya adalah perancang perangkat lunak. Semua pengembangan di luar negeri. Kami berhasil. Jadi proses ini bisa berhasil.

Saya memang menghasilkan banyak dokumentasi tetapi itu tidak berarti komprehensif dan tidak berarti instruksi langkah demi langkah atau rinci ke nama kelas, nama fungsi dll. Sebagai contoh, saya menghasilkan diagram urutan, use case, alur kerja, sistem, dan integrasi diragram, serta dokumentasi desain yang lebih rinci sesuai kebutuhan.

Itu benar-benar tergantung pada seberapa besar Anda mempercayai pengembangan lepas pantai. Saya percaya tim luar negeri saya menjadi pengembang yang kompeten. Yang mengatakan, saya memberikan arahan secara keseluruhan tetapi memberi mereka kelonggaran untuk mengimplementasikan yang menurut tim luar negeri menyenangkan. Di masa lalu mereka lebih dikelola secara mikro. Dalam situasi tertentu saya akan membimbing mereka menggunakan pola desain sesuai kebutuhan. Saya juga secara teratur melakukan tinjauan kode dan analisis pada kode yang mereka tulis dan akan menyarankan upaya refactoring atau membersihkan. Juga, karena beberapa tim mengalami kecelakaan dengan kendaraan rekreasi, saya akhirnya mengkodekan beberapa cerita selama implementasi karena kami akhirnya kekurangan sumber daya.

Selain itu, saya pikir proses ini benar-benar hanya berhasil pada kekuatan pimpinan teknis Anda pada proyek dan komunikasi antara bisnis, perancang, prospek, dan pengembang. Kami menghabiskan banyak waktu untuk membahas setiap fitur dan cerita dan memastikan bahwa sumber / sumber daya lepas pantai mengetahui dengan baik apa persyaratannya. Jika mereka tidak mengajukan pertanyaan selama peninjauan fitur / cerita maka mengharapkan beberapa masalah. Selain itu, pekerjaan tidak dianggap selesai sebelum ada bisnis signoff. Sehingga membuat semua orang bertanggung jawab karena semuanya dilacak dalam alat yang mengelola pengembangan tangkas.

Seperti yang sudah disinggung oleh salah satu jawaban lain, proses pengembangan termasuk standar penamaan (aturan resharper built in), cakupan test case (itu menggunakan TDD, Mocking, dll) jadi jika ada proses pengkodean yang baik dan prosedur di tempat itu akan meningkat peluang Anda untuk proyek yang sukses.

Biaya utama pengembangan lepas pantai adalah komunikasi. Dokumentasi adalah salah satu cara komunikasi, namun, dokumen tidak dapat mencakup semua perincian dan potensi perubahan biasanya.

Tidak yakin seberapa besar proyek Anda. Saya berasumsi ini besar, kalau tidak, tidak perlu menggunakan tim pengembang lepas pantai. Demikian pengalaman saya

1. Tentukan kode kerangka, antarmuka publik, antarmuka layanan, dll., Dan tinjau bersama
2. Tetapkan tes penerimaan dengan pihak lain
3. Membagi dokumen besar menjadi cerita kecil, bekerja berdasarkan cerita kecil. Dokumen besar hanyalah gambaran besar dari keseluruhan sistem
4. Tetapkan poin-poin penting dari cerita, satu minggu atau dua minggu

1 dan 2 sebenarnya tentang pengembangan, untuk memastikan pihak lain memahami persyaratan dengan baik, dan kedua belah pihak menggunakan pola yang sama. 3 dan 4 adalah bagian dari metodologi pengembangan gesit, tetapi untuk pengembangan lepas pantai, sulit untuk menggunakan proses tangkas penuh.

Saya pikir sedikit banyak kita semua bekerja seperti itu. Seseorang di suatu tempat merancang sesuatu dan kami mengkodekan sesuatu yang merupakan bagian dari atau bekerja dengan sistem. Contohnya adalah membangun aplikasi berdasarkan kerangka kerja, seperti aplikasi non-game di perangkat seluler. Banyak keputusan UI telah dibuat oleh tim desain dari orang-orang yang membangun kerangka kerja. Mereka mengendalikan semuanya, mulai dari belajar menulis aplikasi hingga menjual aplikasi Anda. Jika Anda ingin melihat mengapa model ini berhasil, lihat saja jumlah dokumentasi dan alat yang disediakan oleh beberapa vendor.

Contoh lain adalah aplikasi web dengan banyak dari mereka mencoba menerapkan gaya REST. Yang ini tidak benar-benar memberitahu cara mengimplementasikan sesuatu, meskipun ketika ada spesifikasi tentang cara menggunakan HTTP. Lagi pula, ada spesifikasi dan prinsip panduan untuk diikuti. Jika Anda melihat jumlah diskusi tentang implementasi REST di stackexchange atau di tempat kerja, itu seperti ada arsitek yang memberitahu orang untuk mengimplementasikan sesuatu dengan cara tertentu. Itu masih model yang sukses, saya pikir, dengan begitu banyak orang mengikuti gaya ini.

Dari dua contoh itu Anda dapat melihat bagaimana desain disebarkan, beberapa sebagai spesifikasi kertas, yang lain dilengkapi dengan buku, alat, dan contoh. Anda dapat melihat bagaimana orang bertanya (dalam volume), mencoba untuk mendapatkan pemahaman yang benar dengan derajat yang berbeda tergantung standar / desain apa yang mereka coba ikuti. Pergi saja ke stackoverflow dan tonton;)

Jika Anda memberi saya spesifikasi Anda, saya akan bertanya. Jika Anda memberi saya unit test, saya akan kode dan tes.