Pindah dari proyek satu orang ke proyek tim di masa depan. Apa yang harus saya lakukan sekarang dalam persiapan dan apa yang bisa menunggu?

Untuk menguraikan saya tertarik untuk mengetahui apa yang orang pikir Anda perlu lakukan ketika masih proyek satu orang (kontrol sumber tim, dokumentasi, membangun dll) dan hal-hal apa yang tidak perlu dilakukan sampai saat ketika orang kedua datang ke proyek.

Siapa pun yang memiliki pengalaman bergerak melalui skenario ini, wawasan mereka akan dihargai.

Apa yang saya pelajari. (Saya mencoba urutan yang berbeda. Saya salah. Ini adalah urutan di mana segala sesuatu menjadi relevan.)

1. Masukkan semuanya ke dalam kontrol kode sumber. Gunakan sesuatu yang setiap orang memiliki akses dan mulai sekarang . Tidak ada pengecualian. Tidak ada penundaan Tidak ada alasan.

2. Buat area QA / Tes yang benar-benar terpisah dari lingkungan "kerja" atau "pengembangan" pribadi Anda. Setidaknya id pengguna yang terpisah. Idealnya pada VM terpisah.
   Pisahkan sepenuhnya. Tidak mungkin tumpang tindih dengan lingkungan kerja Anda saat ini.

3. Hentikan pengujian di luar pengujian unit di lingkungan kerja Anda sendiri. Kode dan unit test Anda lakukan "seperti diri Anda sendiri". Semua pengujian lain (integrasi, kinerja, apa pun) yang Anda lakukan pada VM terpisah. Jangan pernah menguji diri sendiri. Selalu uji sebagai pengguna QA yang terpisah. Idealnya pada VM terpisah.

   "Bekerja untuk saya," adalah hal buruk untuk dikatakan kepada anggota tim Anda. Sangat buruk. Anda perlu mencari tahu apa yang mereka lakukan salah. Beberapa kali sehari.

4. Berencana untuk menuliskan semuanya. Gunakan alat markup teks biasa (RST atau Markdown atau sesuatu) sehingga semua dokumentasi adalah teks biasa dalam repositori kontrol versi. Alat dapat membuat halaman HTML (yaitu, Docutils for RST) atau PDF atau apa pun yang tampaknya terbaik. Jangan gunakan format dokumen berpemilik (mis. MS-Word). Mereka mungkin tidak bermain dengan baik dengan beberapa sistem kontrol kode sumber.

5. Hal-hal pertama yang perlu Anda tulis adalah sebagai berikut.

   • Cara membuat lingkungan pengembangan kerja. Jika ragu, buat mesin virtual dan lakukan seluruh operasi pada mesin virtual itu. Pastikan langkah-langkahnya benar-benar berfungsi dan dokumentasinya jelas . Baris aktual diketik pada jenis baris perintah yang sebenarnya kejelasan.

   • Cara menjalankan unit test suite. Lagi. Pastikan bahwa instruksinya bekerja dan tidak perlu berpikir. "Ketikkan ini:" "Konfirmasikan bahwa:" jenis barang. Bukannya anggota tim Anda bodoh. Itu karena Anda tidak ingat apa yang Anda asumsikan kecuali Anda menuliskan semuanya.

   • Cara menjalankan suite tes integrasi.

   Jangan buang banyak waktu untuk mendeskripsikan arsitektur atau prinsip desain. Anda perlu membuat seseorang bangkit dan berlari dulu. Anda bisa menjelaskannya nanti.

6. Hal-hal selanjutnya yang perlu didokumentasikan adalah kisah pengguna. Dan uji kasus yang mendukung cerita-cerita itu. Dan perlengkapan data diperlukan untuk kasus uji yang mendukung cerita pengguna tersebut.

   Anda akan membagikan ini. Itu berjalan di bawah kendali kode sumber.

7. Akhirnya, Anda dapat mendokumentasikan tampilan 4 lainnya.

   • Pandangan logis adalah hal yang bermanfaat untuk didokumentasikan. Gambar dapat diterima di sini. Ini cenderung berkembang dengan cepat, jadi jangan habiskan waktu untuk menangkap informasi warisan. Temukan cara untuk bekerja sama dengan anggota tim Anda.

   • Tampilan proses seringkali membantu. Tergantung pada keseluruhan aplikasi seberapa penting hal ini.

   • Tampilan pengembangan - modul, perpustakaan, kerangka kerja, dll. - sering dijelaskan secara informal. Sebuah gambar mungkin membantu, tetapi sangat sulit untuk membuat ini cukup lengkap sehingga seseorang dapat mengambil dokumen dan membuat kepala atau ekornya. Bahkan proyek yang sudah lama berdiri, sangat umum memiliki dokumentasi perpustakaan yang diabaikan begitu saja. (Menuju banyak pertanyaan Stack Overflow.)

     Selain dapat diterima sebagai informal, ini cenderung berubah dengan cepat.

   • Informasi penyebaran. Server. Alamat IP. Kredensial basis data. Semua itu harus ditulis. Akhirnya.

Alat dan metodologi

Apa yang dibutuhkan untuk berkolaborasi dengan sukses dan menjadi produktif?

• Identifikasi bagian / komponen proyek Anda: Membedakan dengan jelas antara bagian yang berbeda (database, lapisan akses data, situs web, layanan, API, proyek pengujian, skrip pembuatan, ...) dan lingkungan (dev, staging, produksi), dan menamai mereka secara konsisten berdampak pada komunikasi lisan dan tertulis Anda (dokumentasi, nama proyek, ...)
• Gunakan sistem manajemen kode sumber (kalau-kalau Anda belum). Pikirkan tentang bagaimana menggunakan percabangan dengan proyek dan pengaturan Anda.
• Otomatiskan build Anda - buat semudah mungkin untuk mengatur lingkungan dari repositori sumber Anda.
• Proyek uji adalah keharusan pada proyek besar, setidaknya untuk proyek yang lebih kompleks.
• Gunakan lingkungan pementasan tempat proyek Anda siap digunakan. Juga, buat dan kelola data sampel untuk pengaturan pementasan otomatis.
• Gunakan sistem pelacakan bug yang dapat membantu memprioritaskan dan merencanakan pengembangan, dan juga berfungsi sebagai memori untuk bug masa lalu dan bagaimana bug tersebut diselesaikan.
• Dokumentasikan setiap bagian dari proyek Anda, beberapa lebih dari yang lain. Saya pribadi suka: Tinjauan Umum - Arsitektur - Ketergantungan - Konfigurasi - Masalah umum (dari sini ). Terkadang lebih sedikit lebih banyak - agar dokumen Anda tidak ketinggalan zaman, lebih baik ringkas dan biarkan dokumentasi menjadi bagian dari kegiatan sehari-hari Anda.

Manajemen / kerja tim

... atau apa pun di tingkat interpersonal

• Tentukan harapan Anda dari pengembang lain. Masuk akal, tidak ada yang cenderung membawa keterlibatan dan semangat yang sama dengan Anda - setidaknya tidak sejak awal. Komunikasikan apa yang Anda harapkan dan apa yang tidak, tentukan tanggung jawab Anda dan orang lain. Tidak semua orang adalah insinyur, arsitek, pengembang, dba dan sysadmin, tetapi jika itu yang Anda cari, pilih orang yang tepat atau Anda akan kecewa.
• Pada awalnya , tentukan tugas dengan tepat , dan tinjau dan diskusikan hasilnya. Secara bertahap, mulai semakin sedikit mengelola mikro. Idenya adalah untuk membangun kepercayaan dan meningkatkan tanggung jawab.
• Rencanakan proyek Anda , tetapkan tujuan untuk proyek Anda dan untuk tim Anda untuk tahun berikutnya. Tulis dan periksa nanti, ini akan memberikan perspektif . Tujuan-tujuan itu mungkin atau mungkin tidak dikomunikasikan kepada orang lain (asalkan itu adalah tujuan yang perlu Anda capai, bukan orang lain), itu bisa dengan mudah menjadi daftar periksa Anda sendiri.
• Luangkan satu hari untuk mempersiapkan dan merencanakan bulan pertama (atau dua / tiga bulan) dari pengembang baru Anda. Saya merasa sangat memotivasi ketika bekerja dengan orang-orang yang dipersiapkan dengan baik. Tak seorang pun harus mendapatkan kesan bahwa waktunya terbuang sia-sia.
• Lepaskan . Ini bayimu, itu harus menjadi milik orang lain juga. Biarkan yang lain menjadi ahli lebih baik daripada Anda, setidaknya di beberapa bagian proyek. Ini berarti sebenarnya Anda berhasil.
• Dengar - jika Anda mempekerjakannya, dia punya sesuatu untuk dikatakan. Bersiaplah untuk belajar.
• Bersiaplah untuk membagikan pengetahuan dan pengalaman Anda (dan karenanya waktu - bersabarlah).
• Kesalahan akan terjadi, begitulah cara mereka ditangani dan apa yang dipelajari semua orang tentang mereka yang penting.
• Berikan waktu untuk belajar dan bereksperimen

Referensi buku

Saya akan membuat daftar beberapa buku yang telah saya sebutkan yang sebenarnya saya baca dan saya pikir layak untuk dibaca, untuk deskripsi yang lebih rinci atau untuk lebih banyak buku Anda mungkin ingin memeriksa beberapa pertanyaan tentang SO yang menanyakan dengan tepat untuk itu, seperti ini atau ini pertanyaan.

Buku-buku itu benar-benar layak dibaca sehubungan dengan tim, organisasi, dan proyek pemrograman:

• Peopleware
• Bulan Manusia Mistis
• Estimasi Perangkat Lunak, Demistifikasi Seni Hitam

Tidak satu pun dari itu adalah panduan praktis tentang bagaimana menerapkan metodologi X (kecuali estimasi Perangkat Lunak, buku ini membantu Anda memilih proses estimasi yang sesuai). Tentu saja, buku yang lebih fokus pada pemrograman itu sendiri seperti Code Complete juga sangat memperkaya.

Saya akan berbicara dari pengalaman, tetapi perlu diingat bahwa setiap orang berbeda. Hal-hal ini tidak universal.

Satu hal adalah membiarkannya secara pribadi. Proyek ini adalah sesuatu yang Anda jalani dan hidup selama 18 bulan - Anda tentu ingin setiap perubahan seperti yang Anda lakukan. Berikan penyangga bagi kolega untuk membuat kesalahan, untuk belajar. Buat ruang untuk mereka agar bermanfaat. Dan perlu diingat itu mungkin tidak terjadi segera. Juga akan lebih bagus jika ada sesuatu, bagian dari kode yang mereka rasakan berhasil mereka kembangkan atau ciptakan, yang terasa seperti kesuksesan dalam waktu singkat. Kesabaran dan toleransi memiliki tingkat pembayaran yang baik di sini. Jangan mencoba mengelola mikro, dan jika Anda ingin mengkritik, mengatakan "Anda salah", pastikan Anda memiliki jasa, Anda dapat membuktikannya, itu bukan pertarungan "religius".

Masalah utama lainnya adalah menemukan orang yang tepat untuk Anda. Idealnya lebih baik untuk menemukan seseorang yang lebih pintar daripada dirimu sendiri. Ini subyektif dan relatif, tetapi jika Anda merasa seseorang memiliki pengetahuan dan keterampilan yang tidak Anda miliki, itu adalah yang terbaik. Ini akan menjadi kolaborasi yang saling menguntungkan.

Ada dua cara yang bisa dilakukan - kolega akan menjadi hambatan, dan Anda akhirnya akan mengulangi apa yang dia lakukan, atau keterampilan Anda berdua akan berlipat ganda, tidak hanya bertambah, dan Anda akan sangat menghargai bekerja bersama.

Pada topik "kode bersih, cepat, dapat digunakan kembali" - Saya sarankan pada sebuah wawancara, minta untuk menulis manajer mikro-kernel / layanan kecil dan / atau pelaksana pekerjaan. Lihat bagaimana komponen pluggable ditentukan dan dikonfigurasi. Tidak harus selesai, itu adalah pemikiran yang diperhitungkan. Dan juga Anda akan dengan cepat mempelajari orang-orang yang tahu benar cara melakukannya akan menginginkan uang yang layak ;-) Semoga Sukses!

Pilihan saya: Mulailah dengan mendokumentasikan arsitektur proyek internal Anda untuk seseorang ... yang tidak menyadarinya. Cobalah untuk menjelaskan asumsi mana yang ada dan kapan / di mana Anda beralih dari praktik umum dan mengapa.

Build automation: Ide bagus, boleh saya tambahkan otomatisasi konfigurasi untuk mesin dev. Yang paling mudah adalah membangun semakin banyak (jadi lebih banyak / lebih cepat menguji penyebaran).

Gagasan lain (itu sangat membantu saya sekali): Minta pengembang baru untuk melakukan beberapa pembersihan tugas skala kecil di berbagai bidang basis kode Anda, sehingga ia akan terbiasa dengan alat tata letak dll. Satu ide bagus adalah menghapus mengaburkan area yang mungkin menambah kebingungan di kemudian hari (contoh: jika Anda menggunakan emmm python untuk dua baris skrip shell di suatu tempat dan proyek Anda didasarkan pada java, minta kedua baris itu untuk ditulis ulang di java sehingga pengembang # 3 perlu tahu lebih sedikit untuk bekerja)

Saya akan fokus pada mengotomatisasi segala sesuatu yang membutuhkan pekerjaan manual, sehingga dapat dikacaukan oleh orang yang tidak berpengalaman . Yang, berdasarkan komentar singkat Anda di atas, termasuk yang berikut:

• instal kontrol versi dan ganti cadangan manual dengan yang otomatis,
• mengatur penyebaran otomatis sebanyak mungkin (sesedikit mungkin, menulis skrip untuk digunakan melalui FTP daripada melakukannya dengan tangan.

Jika Anda gagal melakukan ini, Anda akan dirantai untuk melakukan tugas-tugas ini selamanya, atau (beberapa) pria baru itu pasti akan mengacaukan sesuatu cepat atau lambat.

Tugas penting lainnya adalah, seperti dicatat oleh @dimitris, dokumentasi. @ S. Lott menambahkan lebih banyak detail tentang ini, jadi beri +1 kepadanya saja daripada diulang :-)

Berikut adalah beberapa pemikiran, sebagian berdasarkan pengalaman pribadi:

• Dokumentasikan proyek Anda. Spesifikasi desain, diagram, manual, dan komentar akan membantu karyawan baru untuk mempercepat. Menjelaskan sistem yang kompleks hanya secara verbal terbukti lambat dan membuat frustrasi. Dokumentasi sering diabaikan dalam proyek satu orang. Pastikan milik Anda adalah pengecualian.

• Pada awalnya, berkonsentrasilah pada kode tingkat API- / inti sendiri, sambil memberi karyawan baru beberapa pekerjaan "lapisan aplikasi" atau perbaikan bug untuk secara bertahap membiasakan mereka dengan kode tersebut. Umumnya, mulai dengan lebih mudah , namun bermakna dan dengan demikian menguntungkan tugas .

• Komunikasi itu penting. Responsif terhadap pertanyaan, komentar, dan ide karyawan baru. Jelaskan mengapa Anda berpikir sebuah ide tidak baik jika Anda melakukannya. Sepasang mata yang segar dapat menemukan ruang untuk peningkatan yang sangat baik. Jika karyawan baru Anda adalah karyawan yang baik, ia dapat meninjau kode Anda dan akhirnya berpartisipasi dalam keputusan arsitektur. Diskusikan, pantulkan ide satu sama lain. Itu adalah salah satu manfaat terbesar dari memiliki rekan kerja di proyek Anda.

• Tetapkan tanggung jawab dengan jelas , begitu Anda tahu tugas seperti apa yang dilakukan oleh anggota tim baru Anda. Menetapkan praktik dokumentasi dan konvensi pengkodean untuk menjaga semuanya tetap lancar.

• Gunakan sistem kontrol revisi . Pertahankan tata letak file sumber logis dan bangun disiplin .

Sedangkan untuk wawancara - Saya bukan penggemar berat dari tes koding buatan atau pertanyaan jebakan, kecuali jika Anda ingin mencoba kemampuan yang bertahan lama dari kandidat. Bahkan pemecah masalah yang paling pintar pun bisa terkunci dalam situasi seperti itu. Kualitas yang akan Anda cari, antara lain: kejujuran , kemampuan profesional , pengetahuan / wawasan teknologi , antusiasme , dan kompatibilitas satu sama lain . Suasana kerja bisa sangat berarti; tidak disarankan untuk memilih teman satu tim yang tidak Anda sukai. Tempatkan pertanyaan Anda dengan benar dan lakukan beberapa diskusi informal untuk mendapatkan gambaran yang baik tentang kandidat Anda. Semoga berhasil!

Teknologi

Jika Anda membawa orang lain sebagai pengembang, ada tiga hal utama yang saya sarankan agar sudah berjalan sebelum mereka mulai.

1. Kontrol sumber
2. Pelacakan masalah
3. Integrasi berkelanjutan

Jika ketiga hal ini berjalan dan berjalan dengan baik, Anda akan menghilangkan sekitar 75% dari masalah umum yang terjadi ketika Anda membawa anggota tim baru. Inti dari teknologi ini adalah untuk mengambil banyak dari apa yang terjadi hanya di kepala Anda dan mengeluarkannya di tempat anggota tim Anda dapat berinteraksi dengannya.

Kontrol sumber memastikan Anda berdua mengerjakan hal yang sama. Pelacakan masalah membantu Anda melacak apa yang perlu dilakukan dan akan memudahkan Anda untuk mengetahui apa yang sedang mereka kerjakan dan capai. Integrasi dan pengujian berkelanjutan akan membantu memastikan bahwa Anda memiliki proses pembangunan berulang dan bahwa peningkatan baru tidak merusak bagian lain dari kode.

Pragmatic Programmer memiliki beberapa buku bagus tentang ini. Berikut adalah beberapa yang saya rekomendasikan. Mereka memiliki judul serupa lainnya berdasarkan bahasa pemrograman apa yang Anda gunakan atau kontrol versi apa yang ingin Anda gunakan:

http://www.pragprog.com/titles/tpp/the-pragmatic-programmer http://www.pragprog.com/titles/tsgit/pragmatic-version-control-using-git http: //www.pragprog. com / title / auto / pragmatic-project-automation

Pribadi

Sering kali kesulitan yang akan Anda hadapi kurang di sisi teknis hal dan lebih pada belajar untuk melepaskan sisi. Mungkin sulit untuk memberi orang lain kontrol atas aspek-aspek proyek - terutama jika Anda terbiasa melakukan semuanya sendiri dan membuat setiap keputusan. Anda akan menyelamatkan diri dari kesedihan jika Anda dapat menemukan area di mana Anda dapat membuat orang baru itu bekerja dengan kebebasan yang wajar di awal sehingga Anda dapat mengembangkan fondasi kepercayaan. Jika Anda mempekerjakan orang yang baik, hal utama yang mungkin akan Anda pelajari adalah bagaimana memercayai orang lain untuk melakukan pekerjaan dengan baik bahkan jika semua keputusan individu mereka tidak sama dengan apa yang akan Anda buat.

Anda ingin memberi karyawan baru Anda kebebasan untuk menyelesaikan masalah dengan cara yang bekerja untuk mereka sambil menjaga perlindungan agar Anda dapat menangkap masalah sejak dini.

Poin-poin ini paling penting menurut saya:

1. Baca kembali bagian-bagian penting dari kode Anda dan pastikan mudah dimengerti. Gunakan komentar atau fungsi intuitif dan nama variabel.
2. Permudah orang baru mengirim kode.
3. Jika tidak sepele, buat file README yang menjelaskan semua langkah yang diperlukan untuk pengembang baru tentang cara mengatur lingkungan pengembangan. Atau sangat membantu dalam menyiapkan lingkungan ini.
4. Berikan pengembang baru tugas yang sangat jelas saat mengerjakan proyek baru ini. Menurut pendapat saya tugas-tugas ini harus melibatkan fungsi baru tetapi sederhana. Menurut saya, tugas pembersihan tidak masuk akal karena pengembang baru terlebih dahulu harus terbiasa dengan gaya pengkodean Anda dan kebiasaan-kebiasaan itu, bahkan jika itu buruk. Membersihkan atau bahkan refactoring adalah pekerjaan yang perlu dilakukan oleh orang yang mengetahui kode.
5. Buat jelas apa proses untuk mengirimkan kode. (Misalnya, serahkan hanya barang yang dikompilasi.) Tapi jangan terlalu ketat, ini bisa membuat frustasi pada awalnya.
6. Siapkan dokumen dengan konvensi pengkodean. Sangat frustasi jika menebak konvensi pengkodean yang lain.
7. Jika aplikasinya kompleks, siapkan beberapa dokumentasi yang menjelaskan arsitekturnya. Atau jelaskan arsitekturnya kepada orang baru menggunakan diagram alur atau yang serupa. Anda tidak ingin terlalu banyak membuang waktu pengembang baru di rekayasa balik proyek Anda.
8. Jika pengembang baru seharusnya melakukan penggelaran sendiri, siapkan daftar periksa yang siap menjelaskan semua langkah yang diperlukan untuk digunakan.

Dan yang tak kalah pentingnya: dapatkan sistem kontrol versi. Subversi baik-baik saja. Tetapi pastikan untuk tidak menambahkan file Eclipse (atau apa pun) yang khusus untuk pengguna dan karenanya terus-menerus berubah. Mereka membuat Anda membuang waktu. Jangan ragu untuk bertanya tentang Stackoverflow jika Anda memiliki masalah dengannya.