Menulis buku pegangan pengembang di seluruh perusahaan


17

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.


3
Proses Anda saat ini sangat buruk. Apakah Anda memiliki dukungan perusahaan untuk mengubah proses Anda saat ini, itu tidak akan murah, jenis perubahan yang diperlukan akan mengambil uang. Ada banyak buku tentang hal ini, sebagian besar dari pracices memiliki alat, yang diperlukan untuk menerapkannya dengan cara yang tidak memerlukan banyak usaha.
Ramhound

berbelanja topik buku pegangan?
nyamuk

1
@gnat Poin bagus. Lihat edit.
Phil

hasil edit yang bagus (Anda rupanya mengikuti tautan). Saya juga mengubah topik apa yang menurut Anda penting ... untuk sesuatu seperti Bagaimana Anda mengukur pentingnya topik ... - dengan begitu, akan lebih sesuai dengan panduan Jeff sejauh yang saya mengerti
nyamuk

1
Saya tidak terlalu peduli tentang bagaimana mengukur pentingnya topik, karena saya pikir saya sudah bisa melakukannya. Sebaliknya, saya mencari contoh. Saya selalu menganggap jawaban pertanyaan abstrak lebih baik jika disertai dengan contoh. Lihat edit. BTW, saya menghargai bantuan Anda membuat pertanyaan saya lebih baik.
Phil

Jawaban:


20

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.


6
Saya suka seberapa sering Anda mengedit ini. Bagaimana ... lincah dari Anda. :)
Phil

Kami tidak perlu ingin memodifikasi prinsip gesit secara umum. Kami hanya akan memodifikasi praktik tertentu seperti XP, karena kami tidak benar-benar memiliki tenaga untuk mengimplementasikan semua peran yang diperlukan. Itu mungkin pertanyaan lain untuk hari lain.
Phil

Maaf, saya menghapus jawaban untuk sekarang karena pertanyaannya telah dimodifikasi.
Phil

1
Poin bonus jika Anda menyiapkan wiki perusahaan untuk menyimpan info ini ...
Spencer Rathbun

Hai Spencer, itu menarik. Saya juga baru mulai menggunakan wiki github dengan penurunan harga. Ada pemikiran tentang bagaimana mereka membandingkan. Jelas banyak orang yang tahu github dari kode dan penurunan harga dari SO, jadi mudah untuk diadopsi.
Michael Durrant

4

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.


2
+1 untuk menjaganya tetap sederhana dan berkonsentrasi pada isu-isu penting. Kami benar-benar tidak memerlukan mandat "pemerintah besar" pada gaya pengkodean.
kirk.burleson

3

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).


2

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.
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.