Apa yang harus Anda sertakan dalam dokumen pendekatan pengembangan? [Tutup]

Saya sedang memproduksi dokumen "pendekatan pengembangan" bersama untuk sumber daya lepas pantai saat mereka menuju proyek kami.

Dokumen terbaru (serupa) yang digunakan perusahaan kami adalah lebih dari 80 halaman, dan itu tidak termasuk standar pengkodean / dokumen konvensi.

Kekhawatiran saya adalah bahwa dokumen ini tidak akan habis dan karena itu akan gagal.

Apa yang seharusnya ada dalam dokumen pendekatan pembangunan? Apakah ada pedoman yang layak tentang topik ini?

EDIT: Dokumen pendekatan pengembangan harus merinci praktik dan teknik yang akan digunakan oleh pengembang perangkat lunak saat perangkat lunak dirancang, dibangun, dan diuji.

Di salah satu perusahaan tempat saya bekerja, kami memiliki seluruh pendekatan berorientasi proses ini dengan banyak dokumen (sebagian besar diminta untuk diisi oleh Manajer Proyek). Namun, terlepas dari panjang dan penjelasannya, saya menyadari bahwa itu hampir tidak digunakan untuk membantu orang - pengembang nyata.

Jadi saya memutuskan untuk menarik diri dengan tujuan khusus "membantu para pengembang". Hal terpenting yang saya mulai adalah mengumpulkan pertanyaan paling mendasar - FAQ yang sebenarnya .

Apa yang saya pelajari adalah bahwa mengikuti hal-hal penting bagi kebanyakan orang ketika mereka ingin mengadopsi proses tertentu, dan banyak hal yang mereka mungkin tidak punya ide sebelumnya tetapi akan sangat menghargai jika mereka memahami logika.

Berikut adalah topik utama yang harus dibantu oleh dokumentasi semacam itu:

1. Proses pengembangan hingga penerapan - Bagaimana seharusnya kode disusun, disusun, diterbitkan (dalam bentuk DLL, perpustakaan, yang dapat dieksekusi, penginstal, halaman web, dan bagaimana kode tersebut akan digunakan dan diuji)?

2. Bagaimana seharusnya kita melakukan kontrol versi? (dan mengapa jika ada pemula). Memahami bagaimana struktur repositori, kode etik - ketika check-in dapat diterima dan kapan tidak, ketika versi / tag diumumkan, bagaimana tambalan, penggabungan akan diterapkan, dan apa yang diharapkan kebersihan saat tambalan atau rilis dinyatakan selesai

3. Melaksanakan Metodologi - apakah kita gesit, apakah kita melakukan desain muka, metodologi yang kita gunakan? Sekarang mengingat ini, itu mungkin merupakan perbaikan untuk perusahaan tertentu. Sekarang, bagi kebanyakan orang, mereka ingin tahu bagaimana kita akan mengimplementasikannya untuk proyek yang diberikan. Ini sangat spesifik tentang proyek yang akan memungkinkan orang untuk memvisualisasikan tonggak yang berbeda dan apa yang berpotensi penting. Dalam proyek yang berorientasi penelitian - kami ingin menunjukkan "selalu memvalidasi algoritma kritis sebelum membangun di atasnya" dalam bungkus menyusut saya akan fokus pada kebenaran dan pentingnya fitur.

4. Tanggung jawab komunikasi - Menentukan bagaimana Anda melakukan komunikasi formal - ini tidak dilakukan dengan apakah orang-orang tertentu dapat berbicara satu sama lain - tetapi orang-orang harus memiliki perasaan mengenai apa yang cukup penting (masalah, keputusan desain, pembekuan fitur) untuk diumumkan atau bahkan diperdebatkan sebelum melanjutkan implementasi.

5. Akhirnya, kita semua harus memiliki pemahaman yang sama tentang kualitas kode, standar pengkodean dan secara umum apa yang kita anggap baik atau di bawah tingkat kebersihan.

Saya berharap saya akan memulai setiap proyek dengan dokumen seperti itu - namun, itu tidak mudah. Namun yang penting adalah untuk mengatasi semua masalah yang berhubungan dengan perilaku sehari-hari dan pilihan pengembang. Ini berjalan jauh ketika beberapa rilis ke pasar perlu dikirimkan.

Akhirnya, saya juga menyarankan agar mencoba bersikap informal. Biasanya, orang-orang yang berorientasi pada proses tidak begitu menyukai dokumen informal yang berpotensi disalahpahami di luar konteks. Namun, itu harus dilakukan sedemikian rupa sehingga menghubungkan para pengembang.

Apa yang Anda sebut "dokumen pendekatan pengembangan" biasanya disebut Rencana Manajemen Proyek Perangkat Lunak . (Saya juga pernah mendengarnya disebut Rencana Proyek Perangkat Lunak atau Rencana Pengembangan Perangkat Lunak .) Dengan persyaratan itu, Anda harus dapat Google untuk beberapa sampel yang ada di luar sana. Seperti yang dikatakan Victor Hurdugaci dan Donal Fellows, Rencana Manajemen Proyek Perangkat Lunak yang Anda tulis akan (1) disesuaikan dengan kebutuhan Anda dan (2) diperbarui sebagai dokumen hidup ketika situasinya berkembang. Yang sedang berkata, menulis satu dari awal bisa sulit jika Anda belum pernah menulis sebelumnya dan Anda tidak tahu apa lagi yang harus masuk ke dalamnya.

Ada beberapa panduan melalui Standar IEEE 1058 (Standar IEEE untuk Rencana Manajemen Proyek Perangkat Lunak, 1998). Ada salinan standar yang diposting di sini . Saya menemukan rencana ini cukup berat, tetapi ini adalah tempat yang layak untuk mendapatkan ide - dan Anda mungkin perlu bobot ekstra jika Anda menginginkan semuanya secara tertulis untuk tim yang berada di luar negeri. Ada juga garis besar yang cukup bagus - dan beberapa narasi hebat tentang bagaimana merencanakan proyek perangkat lunak - dalam sebuah buku yang sering saya baca untuk proyek perangkat lunak tradisional (tidak gesit): Manajemen Proyek Perangkat Lunak Berkualitas oleh Futrell, Shafer, dan Shafer.

Dokumen pendekatan adalah dokumen 'Tidak ada di sini atau di sana' . Ini adalah dokumen yang biasanya ditanyakan oleh Manajer Proyek (Manajer Vendor) organisasi bisnis dari Manajer Proyek (Manajer Pengembangan Perangkat Lunak) dari Organisasi Pengembangan Aplikasi Perangkat Lunak.

Tujuan dari dokumen ini bervariasi berdasarkan pada kebutuhan dari Organisasi Bisnis PM.

Dapat berisi arsitektur hw, fungsi sistem, rencana komunikasi, rencana konfigurasi, rencana pemuatan sumber daya, tumpukan teknologi, arsitektur aplikasi, dan sebagainya.

sekali lagi, daftar di atas adalah variabel berdasarkan kebutuhan .. :)

Saya belum melihat literatur formal tentang dokumen tersebut. jika ada oleh penulis standar Pressman dll. bagikan ..

atau saya melewatkan sesuatu.

Dokumen terbaru (serupa) yang digunakan perusahaan kami adalah lebih dari 80 halaman, dan itu tidak termasuk standar pengkodean / dokumen konvensi.

Karena Anda sudah memiliki beberapa dokumen, itulah titik awal Anda. Bertanya pada diri sendiri:

1. Apa yang berguna dalam dokumen ini?
2. Apa yang hilang?
3. Mengapa (tidak) saya menggunakan dokumen ini?

Setelah Anda mendapatkan jawaban, potong apa yang tidak diinginkan dan tambahkan bagian yang hilang.

Isi dokumen yang sebenarnya tergantung pada sumber daya yang tersedia dan saya percaya sulit untuk berspekulasi dengan menggunakan informasi yang disediakan.

Sekedar petunjuk: Anda akan ingin menyesuaikan dokumen ini dari waktu ke waktu jadi jangan menulis terlalu banyak;)

Praktik pengembangan berubah dari waktu ke waktu seiring perubahan kebutuhan Anda dan sekumpulan bahasa, perpustakaan, dan kerangka kerja yang Anda gunakan berubah. Perubahan ini tidak terhindarkan dan akan berarti bahwa apa pun yang Anda letakkan di atas kertas akan segera kedaluwarsa (hampir). Cara mengatasi ini? Simpan semuanya di wiki, dan dorong semua orang di tim Anda - baik internal maupun eksternal - untuk membantu agar tetap diperbarui dan relevan.

Setelah Anda mengambil langkah dari dokumen mati ke yang hidup, perdebatan tentang apa yang harus dimasukkan menjadi kurang mendesak: Anda hanya memasukkan apa yang dapat Anda pikirkan sekarang dan kembali ke sana di kemudian hari. (Hal yang baik adalah Anda tidak harus memahami segalanya untuk dapat menulis dokumen di tempat pertama.) Anda mungkin juga ingin menyemai semuanya dengan konten usang dari dokumen 80 halaman yang lama; itu akan memberi Anda banyak materi garis besar jika tidak ada yang lain, menyelamatkan Anda dari keharusan untuk berpikir tentang menulis banyak hal membosankan.

Buat dokumen singkat. Gunakan penataan gaya koran - mulai dengan detail tingkat tinggi dan ikuti dengan spesifik. Alih-alih memasukkan praktik standar - cukup rujuk saja dan detail penyimpangan dari standar.

1: Jika Anda sudah melakukan proyek dalam perusahaan Anda, ikutilah proses itu. Mungkin bahkan mensub-kontrakkan manajemen pengembangan proyek Anda kepada mereka. Jangan menemukan kembali roda.

2: Jika Anda belum melakukan pengembangan di rumah, bersikeras bahwa kontraktor yang Anda gunakan memiliki metodologi yang baik yang mereka gunakan untuk proyek. Kemudian gunakan metodologi itu.

Percaya tapi verifikasi. Anda mencoba membuang sampah dalam jangka panjang. Jadi jangan biarkan mereka melakukan apa pun, ikuti proses apa pun dengan hanya hasil di akhir. Bersikeras bahwa pengiriman awal harus dilakukan dan diperiksa sebelum mereka melanjutkan.

Di luar itu saya pada dasarnya ditto di @Dipan