Saya bekerja untuk perusahaan kecil. Lengan pengembangan perangkat lunak perusahaan sebelum saya dipekerjakan terdiri dari seorang pria yang bekerja sendiri secara otodidak. Sekarang saya telah menulis perangkat lunak untuk perusahaan selama beberapa tahun, saya telah ditugaskan untuk membangun praktik pengembangan perangkat lunak resmi di seluruh perusahaan. Saat ini kami tidak memiliki pedoman, selain

Tulis kode, ujilah, masukkan ke dalam file .zip dan kirimkan ke klien. Poin bonus untuk TDD dan kontrol versi.

Bos saya ingin saya menulis buku pegangan pengembang perangkat lunak yang mendefinisikan proses umum, protokol, alat, dan pedoman yang kami gunakan untuk menyelesaikan sesuatu. Dengan kata lain, dia menginginkan buku "Inilah yang kami lakukan di sini" untuk memudahkan karyawan baru mengenal cara kami melakukan berbagai hal, serta membantu bos saya memahami apa yang dilakukan antek-anteknya dan bagaimana mereka melakukannya. Itu.

Cara saya melihatnya, saya meletakkan fondasi dan itu harus dilakukan dengan benar. Bagaimana Anda memilih topik untuk buku pegangan seperti itu? Bisakah Anda memberikan beberapa contoh topik?

Catatan Samping: Jika itu penting, kami terutama adalah toko Microsoft .NET. Dan kami melihat praktik lincah seperti XP dan Scrum, tetapi kami mungkin harus banyak memodifikasinya untuk membuatnya bekerja di perusahaan kami.

Saya akan memecahnya menjadi beberapa bagian seperti

• Staf saat ini - nama dan judul (idealnya dengan foto)
• Aplikasi, login ke mereka, data untuk mengetahui dan permintaan izin telah dikirimkan
• Bookmark ke situs perusahaan dan situs eksternal utama yang relevan dengan bisnis
• Aplikasi yang digunakan perusahaan untuk komunikasi, email, pemesanan ruang konferensi, layar saham
• Prosedur untuk kegiatan terkait perusahaan seperti tanda terima Pengeluaran, pemesanan perjalanan
• Pengaturan Mesin Pengembang. Jelaskan proses pengaturan mesin pengembang baru secara rinci. Ini biasanya 'diharapkan' hanya memakan waktu sehari, tetapi seringkali butuh 3-5 hari dalam kenyataan.
• Proses pengembangan, bagaimana pekerjaan dilacak, ditugaskan dan diperbarui dan alat apa yang digunakan.
• Bagaimana cara menguji, apa yang harus diuji, kapan harus menguji, di mana untuk menguji.
• Standar pengkodean termasuk konvensi penamaan file dan standar khusus bahasa.
• Cara menangani bug, ke mana mendokumentasikannya, bagaimana cara memperbaikinya.
• proses penyebaran, apa hal utama yang perlu diketahui untuk dorongan produksi.
• Bagaimana mendokumentasikan, apa yang harus didokumentasikan, Kapan mendokumentasikan
• Di mana barang 'adalah', mis. Lokasi untuk Kode, Data, Standar, Dokumentasi, Tautan, dan aset lainnya.

Menjadikannya modular juga akan memungkinkan Anda atau orang lain memperbarui karya secara terpisah, misalnya nama dan posisi karyawan akan sering berubah ketika orang datang dan pergi.

Untuk setiap bagian saya akan berusaha keras untuk menulisnya dari sudut pandang 'pemula'. Yang paling penting adalah memastikan itu benar-benar masuk akal bagi seorang pemula. Bos Anda jelas bukan orang yang tepat untuk mengulas hal ini karena ia bukan audiens yang dituju. Dia benar menginginkannya, pastikan konten tidak berakhir sedang diuji oleh dia. Juga seorang 'pemula' keduanya hanya memiliki "1 minggu" sebagai pemula ... dan hanya memiliki satu sudut pandang. Jadi, kemungkinan (dan direkomendasikan) bahwa dokumen tersebut akan disempurnakan dengan setiap karyawan baru. Sebenarnya itu adalah tugas yang cukup bagus untuk juga menetapkan mereka untuk minggu pertama mereka, yaitu "Perbarui manual pemula".

Untuk Agile / SCRUM:

Bagian tersulit dari melakukan Agile dan SCRUM adalah 'sungguh-sungguh' melakukannya.

Untuk membaca saya akan mulai di http://agilemanifesto.org/ dan pergi dari sana.

Saya juga akan membaca http://www.halfarsedagilemanifesto.org/ yang terkenal yang menambah fakta bahwa Anda benar-benar harus merangkul semua aspek agar bisa berfungsi. Jika Anda harus banyak memodifikasi Agile untuk organisasi Anda, kemungkinan orang menginginkan manfaatnya - tanpa menggunakan proses yang benar. Fakta ini sendiri harus disajikan untuk mengusir setengah-setengah.

Sepertinya Anda harus memperkenalkan beberapa praktik sebelum mendokumentasikannya!

a) Kontrol sumber - bagaimana Anda menyimpan sumber Anda dan melakukan kontrol revisi

b) Manajemen rilis dan pelacakan - bagaimana Anda membangun, menghitung rilis, membandingkan kandidat rilis saat ini dengan rilis sebelumnya

c) Manajemen masalah - bagaimana Anda melacak bug di rilis Anda.

Ini adalah hal-hal yang cukup mendasar tetapi mereka dapat mengambil banyak waktu (dan mungkin membutuhkan biaya) untuk diterapkan.

Topik yang akan saya sertakan dalam buku pegangan pengembang:

• Peran / posisi dalam departemen dan tanggung jawab yang sesuai
• Persyaratan perangkat lunak mesin pengembang (yaitu lingkungan pengembangan yang disyaratkan)
• Di mana dan bagaimana mengakses repositori kode sumber
• Alat pengembangan yang digunakan (misalnya IDE)
• Gaya / standar pengkodean
• Standar dokumentasi
• Proses pengujian
• Proses pembangunan
• Proses penyebaran
• Dukungan dan proses manajemen masalah
• Di mana mendapatkan versi terbaru dari buku pegangan ini

Ingatlah bahwa buku pegangan ini hanya boleh berisi item-item khusus untuk pengembangan, dan bukan informasi untuk seluruh perusahaan (yang seharusnya ada di buku pegangan karyawan).

Penggunaan Kontrol Sumber

• Alat kontrol sumber mana yang Anda gunakan.
• Sintaks perintah / alat umum dalam IDE.
• Strategi percabangan / penggabungan.
• Apa yang seharusnya menjadi unit komit? Berapa lama terlalu lama untuk memeriksa file / tidak melakukan?
• Tingkat "kematangan" apa yang ditunjukkan oleh komitmen / check-in? Kompilasi? Tes unit lulus? Ditinjau?
• Apa yang diharapkan untuk dimasukkan dalam catatan untuk komitmen / check-in.
• Prosedur rollback.