Pemrograman dengan sekelompok orang yang belum pernah saya temui

Saya telah ditugaskan proyek kelompok dari kelas ilmu komputer AP saya, dan saya diminta untuk bekerja dengan tiga orang lainnya. Saya belum pernah berbicara dengan mereka sebelumnya, saya tidak tahu tingkat keahlian mereka, dan yang saya miliki hanyalah alamat email mereka. Tugasnya, diringkas, adalah ini:

"Sebagai tim, kamu akan menyelesaikan minimal tiga Modul ke Kelas ...."

Saya akan mencoba dan menjadi "Kapten tim" karena tidak ada dari mereka yang mencoba menghubungi satu sama lain tetapi saya ingin tahu: bagaimana caranya? Saya sudah mengirim email kepada mereka dan bertanya apakah ada metode komunikasi yang mereka sukai daripada saling mengirim email, tetapi begitu kita benar-benar memulai proyek, saya harus mencari tahu siapa yang melakukan apa.

Apa yang harus saya lakukan? Bagaimana saya "mengambil alih" dan memimpin tiga orang yang belum pernah saya temui?

Berikut adalah kutipan dari tugas yang sebenarnya:

Karena itu, Anda perlu mendiskusikan berbagai peran yang akan diambil setiap anggota tim dalam proyek ini di awal minggu. Anda dapat berkomunikasi melalui Pronto (atau Blackboard IM), email, wiki, grup google, blog atau metode lain yang Anda suka. Jika seorang anggota kelompok tidak terlibat dengan kelompok pada akhir minggu, beri tahu instruktur Anda dan mereka akan memberikan panduan tambahan.
...
Juga karena pada akhir proyek akan menjadi evaluasi tim di mana Anda akan menilai kontribusi setiap anggota tim untuk penyelesaian proyek ini bersama dengan nilai yang disarankan.

Sunting: Banyak orang menyarankan agar saya bertemu mereka di kedai kopi, atau semacamnya. Satu-satunya masalah adalah, kita semua berada di negara yang berbeda. Saya juga menemukan salah satu dari mereka tidak diperbolehkan menggunakan Facebook / Skype / twitter, jadi saya harus mengirim pesan kepada mereka melalui yahoo messenger dan email.

Pemimpin proyek ini adalah orang yang maju dan bertanggung jawab di awal.

Ini berlaku untuk sebagian besar hal dalam hidup - bukan hanya pengembangan perangkat lunak. Ketika semua orang berlarian seperti ayam tanpa kepala, orang yang memikirkan semuanya, melangkah maju dan berkata, " Inilah yang akan kita lakukan dan bagaimana kita akan melakukannya ." biasanya orang tersebut dipandang sebagai pemimpin untuk sisa proyek. Ingatlah bahwa dengan melakukan ini, Anda bertanggung jawab atas keberhasilan atau kegagalan utama proyek.

Anda ingin memimpin proyek ini? Berikut adalah beberapa hal yang dapat Anda lakukan segera untuk membuat dampak besar.

1. Gunakan alat manajemen proyek seperti Trello dan kirim undangan ke semua orang dan mulailah menugaskan sebagian proyek kepada orang-orang.
2. Hasilkan database bug dan mulai menambahkan tugas dan bug - lagi, mulailah menetapkan.
3. Siapkan repositori kontrol versi dan periksa sepotong kode awal yang baik yang dapat digunakan semua orang. Menolak berurusan dengan segala bentuk kontrol kode lainnya.
4. Tawarkan untuk membantu orang-orang memulai pengembangan dengan menunjukkan kepada mereka cara menggunakan sistem kontrol versi dan basis data bug.
5. Kirimkan email mingguan yang merinci status proyek dan kemajuan minggu sebelumnya.

Tidak satu pun dari langkah-langkah ini yang sangat sulit, atau memakan waktu, tetapi mereka akan menghemat waktu . Selanjutnya, itu akan membuat tim Anda berbicara satu sama lain, dan membuat mereka terbiasa melihat Anda yang bertanggung jawab.

Jawaban Jarrod Nettles meringkas banyak hal tentang apa yang akan saya sarankan, jadi saya akan memasukkan beberapa yang berhasil dalam pengalaman saya baru-baru ini dalam situasi yang sama.

Saya menyarankan mencari cara untuk berbicara dengan mereka secara vokal, bukan melalui email. Jika Anda tidak berada di area yang sama, dapatkan semuanya di Skype. Jika Anda berada di area tersebut, temui mereka di kedai kopi atau sesuatu. Berbicara langsung dalam pertemuan awal akan membuat Anda benar-benar membuat keputusan dan menyelesaikan pekerjaan saat itu juga; utas email memungkinkan mereka yang pemalu atau sering tidak di komputer mereka untuk menahan proses - kita semua tahu betapa malasnya siswa!

Dalam pertemuan pertama Anda, saya akan mencoba untuk mengenal grup Anda lebih dari mencoba untuk melanjutkan proyek - tetapi jangan abaikan proyek! 10 atau 20 menit menghabiskan ice breaking mungkin cukup di antara 4 orang.

Ketika berbicara tentang proyek, saya sarankan menjalankan apa yang menurut Anda melibatkan proyek. Saya pikir ini penting untuk Anda jelaskan ini adalah pemahaman Anda, dan bukan kasus Anda yang memberi tahu mereka apa yang harus dilakukan. Semua orang harus dapat melemparkan pemikiran dan ide-ide mereka ke ring jika mereka punya, dan Anda harus pergi dari pertemuan awal itu dengan pemahaman yang cukup layak tentang apa yang Anda, sebagai kelompok, rasakan dari proyek tersebut.

Dalam pertemuan (reguler) yang akan datang, Anda dapat mulai melihat berbagai bagian proyek secara lebih rinci; lihat apa yang perlu dilakukan dengan tepat, sumber daya apa dan berapa banyak waktu yang dibutuhkan dan siapa yang bisa melakukan apa. Bagi potongan lebih lanjut jika perlu. Mungkin mencoba menetapkan tenggat waktu yang lunak?

Apakah ada di antara Anda yang memiliki pengalaman bekerja dengan sekelompok orang yang belum pernah Anda temui online, dan Anda tidak bisa bertemu langsung dengan mereka tetapi harus menyelesaikan proyek bersama?

Tambahkan tenggat underbudgeting, konyol dan dijual di sungai dengan pemasaran dan ini terdengar seperti sekitar 65% dari proyek pengembangan perangkat lunak di dunia nyata.

Anda mungkin lebih baik dilayani dengan membuat orang-orang menjadi sukarelawan untuk bagian-bagian yang akan mereka sukai daripada mengambil alih secara sepihak dan menugaskan tugas. Mereka semua mungkin duduk di sana memikirkan bagaimana mereka harus bertanggung jawab. Atau bagaimana mereka bisa mendapatkan tanah miskin yang terlalu peduli untuk melakukan semua pekerjaan kelompok sehingga mereka bisa naik kelas.

Hal pertama yang harus dilakukan dalam kasus seperti ini adalah membuat pelacak masalah dan mempelajari cara menggunakannya.

Untuk pengantar yang lebih mendasar tentang cara menangani pengembangan seperti yang Anda jelaskan, referensi favorit saya berlaku untuk artikel Martin Fowler Menggunakan Proses Perangkat Lunak yang Agile dengan Pengembangan Lepas Pantai . Artikel ini menguraikan dasar-dasar dan konsep-konsep lanjutan tentang pengaturan komunikasi tim terdistribusi:

Use Continuous Integration to Avoid Integration Headaches
Have Each Site Send Ambassadors to the Other Sites
Use Contact Visits to build trust
Don't Underestimate the Culture Change
Use wikis to contain common information
Use Test Scripts to Help Understand the Requirements
Use Regular Builds to Get Feedback on Functionality
Use Regular Short Status Meetings
Use Short Iterations
Use an Iteration Planning Meeting that's Tailored for Remote Sites
When Moving a Code Base, Bug Fixing Makes a Good Start
Separate teams by functionality not activity
Expect to need more documents.
Get multiple communication modes working early

Untuk proyek Anda, Anda yakin tidak akan dapat mengikuti semua tips dan trik yang disebutkan di sana (mis. Kemungkinan tidak ada Duta Besar atau Kunjungan Kontak untuk Anda :) tetapi tetap perlu dipelajari.

• Untuk banyak tim yang memiliki semua hal di atas tentu saja merupakan pembunuhan yang berlebihan. Namun, saya merasa sangat membantu untuk memiliki daftar periksa yang komprehensif seperti itu - sehingga bahkan barang yang dilompati diperiksa dan telah mendokumentasikan dengan jelas alasan penolakan - hanya untuk memastikan tidak ada hal penting yang terlewatkan.

Anda belum memberi tahu kami berapa banyak waktu yang Anda miliki untuk ini, atau bahasa tempat Anda bekerja (saya akan mengatakan satu kelas sangat kecil, tapi mungkin dalam bahasa Anda jauh lebih baik).

Pertama-tama, miliki produk yang berfungsi dengan biaya berapa pun.

Jika proyek berlangsung selama dua minggu atau kurang, anggaplah Anda akan menjadi satu-satunya yang melakukan sesuatu dan sangat senang dengan bantuan yang Anda dapatkan. Cobalah untuk menjadwalkan hal-hal untuk semua orang, tetapi pastikan bahwa jika tidak ada yang melakukan sesuatu, Anda masih akan memiliki produk yang berfungsi. Bahkan jika seseorang melakukan sesuatu, jangan bergantung pada mereka untuk melanjutkan: bersiaplah bagi siapa saja untuk keluar kapan saja.

Jika Anda memiliki lebih dari satu minggu, pertimbangkan untuk menjadwalkan satu hari dalam seminggu ketika produk tersebut harus ditandai sebagai tonggak sejarah dan berpegang teguh pada itu sebanyak mungkin. Pastikan Anda memiliki sesuatu yang dapat ditendang dan periksa kekurangan: jika yang terburuk menjadi yang terburuk, ini akan menjadi apa yang Anda serahkan. Masing-masing yang Anda buat, Anda akan melihat seberapa banyak Anda dapat meningkatkan hal-hal, yang akan memotivasi Anda untuk pergi di. Jangan merencanakan terlalu jauh ke depan: tentu saja, Anda harus memiliki gagasan tentang apa yang akan Anda dapatkan, tetapi simpan rencana jangka pendek Anda yang paling spesifik.

Perhatikan bahwa keduanya tumpang tindih sedikit: ini disengaja, karena menurut saya dua minggu sedikit area abu-abu di mana dua iterasi dilakukan sulit, tetapi hanya bekerja dalam satu iterasi yang berisiko.

Saya mengasumsikan kasus terburuk, di mana Anda akan bekerja dengan orang-orang yang sangat baru dalam pemrograman. Saran umum saya adalah:

• Simpan daftar fitur yang ingin Anda terapkan segera, dan siapa yang akan mengerjakannya. Jarrod menyarankan Trello, dan aku sepenuhnya mendukung itu: jika teman satu timmu tidak terlalu berpengalaman, itu akan banyak membantu. Anda dapat mencoba menyimpan bug di sana juga.
• Dalam tim empat, Anda perlu kontrol versi. Mungkin membuat orang lain lebih enggan untuk berkontribusi jika mereka tidak tahu bagaimana cara melakukannya, tetapi itu sepadan.
• Setiap dependensi eksternal dapat menakuti pemula. Jika Anda menulis unit test, beri tahu orang-orang bahwa mereka tidak perlu khawatir untuk memecahkannya. Beri tahu orang-orang bahwa mereka tidak perlu khawatir melanggar bangunan, terutama pada awalnya. Jauh lebih sulit untuk mengoreksi orang yang tidak melakukan kode apa pun daripada mereka yang melakukan kode kereta.
• Periksa apakah hal-hal yang disarankan di sini benar-benar berlaku untuk Anda. "Integrasi berkelanjutan" adalah istilah umum - untuk program kecil, yang mungkin berarti "program ini berjalan dan semua fitur dapat digunakan". Apakah Anda punya situs? Apakah membagi menjadi beberapa tim membantu Anda?
• YAGNI, seratus kali lipat. Jika Anda benar-benar harus, tuliskan terlebih dahulu untuk fitur yang akan Anda buat sendiri. Buat itu berfungsi, kemudian refactor, atau Anda tidak akan bisa membuatnya bekerja.
• Refactor. Setelah berhasil, luangkan waktu untuk memperbaikinya. Jangan lupa rekan tim Anda harus membaca kode Anda juga: satu hari dihabiskan untuk memperbaiki bagian-bagian yang jelek dan mengganti solusi sederhana dengan yang berkinerja lebih baik bukanlah hari yang sia-sia.
• Awasi semua bagian. Melacak changelogs dan sesekali membaca kode orang lain membantu memastikan bahwa semuanya sesuai dengan standar kualitas yang Anda rasa harus Anda tegakkan dan pastikan tidak sulit untuk menyelam jika orang tersebut keluar.
• Jangan ragu untuk mengerjakan hal yang paling penting, yang bertentangan dengan hal yang Anda tentukan. Jika seseorang terlambat, buat catatan tertulis di suatu tempat dan lakukan sendiri. Tanyakan kepada mereka terlebih dahulu, tetapi lanjutkan jika mereka tidak menjawab, atau jika Anda bertanya sekali atau dua kali dan kemudian merasa mereka masih tidak akan melakukannya.
• Fokus pada membuat sesuatu yang Anda banggakan. Bahkan jika itu menyimpang dari penugasan. Bahkan jika Anda harus memotong fitur-fitur besar demi membuat apa yang Anda miliki menjadi lebih lancar. Setiap iterasi berpikir "Apakah saya bangga dengan ini?", Dan pada iterasi berikutnya, cobalah untuk memperbaiki hal-hal itu.

Saya punya proyek yang gagal baru-baru ini; Anda dapat membaca pikiran saya tentang mengapa itu gagal jika Anda mau, tetapi ini merangkum bagaimana saya akan melakukan sesuatu seperti ini jika saya punya kesempatan lain.

Jawaban Jarrod Nettles bagus. Saya akan menambahkan ini:

1. Berharap bahwa setidaknya satu dari tiga orang lainnya akan sama sekali tidak berguna.
2. Hanya menerima bahwa Anda akan merasa seperti Anda melakukan sebagian besar (atau semua) pekerjaan, tetapi semua orang akan mendapatkan kredit yang sama. Upaya apa pun untuk membuat hal-hal "adil" hanya akan menyebabkan konflik yang tidak perlu dan memperlambat Anda.
3. Tetap berkomunikasi dengan anggota tim yang baik. Orang-orang seperti itu sulit ditemukan, dan Anda akan ingin bekerja dengan mereka lagi.

Saya telah berada di posisi yang sama beberapa kali karena saya yakin memiliki banyak orang. Namun hal utama adalah melakukan yang terbaik untuk membuat semua orang puas dan bahagia, jadi saya pikir itu baik bahwa Anda ingin mengambil tugas pemimpin tim, namun seperti seseorang yang disebutkan di atas - ini perlu didekati dengan hati-hati seperti orang lain mungkin merasa mereka harus melakukan pekerjaan itu sebagai gantinya.

Saya tahu Anda mengatakan bahwa tidak ada seorang pun yang mengambil tindakan untuk menghubungi satu sama lain, tetapi kadang-kadang situasi ini bisa menyulitkan orang, seperti Anda mengatakan Anda bekerja dengan orang yang belum pernah Anda temui dan mungkin sulit untuk berkomunikasi, dll.

Saya akan mulai dengan email yang hanya ditujukan kepada semua orang dan memberi tahu mereka siapa Anda tentang bagaimana perasaan Anda terhadap proyek yang harus ditangani dan memberitahukan bahwa Anda ingin memimpin proyek yang bertanggung jawab untuk menetapkan peran, tujuan, tenggat waktu, waktu komunikasi, pertemuan ( jika diinginkan / diinginkan) dan pembaruan proyek.

Meskipun Anda tidak dapat sepenuhnya memengaruhi orang lain, Anda dapat melacak siapa yang melakukan apa dan siapa yang tidak. Mendelegasikan pekerjaan memungkinkan pekerjaan dibagi secara merata atau sesuai kepada orang-orang dengan keahlian atau level yang berbeda.

Dengan cara ini jika pekerjaan tertentu tidak dilakukan, Anda dapat mengambilnya sendiri untuk membagi pekerjaan antara orang-orang yang benar-benar ingin mengerjakannya. Dengan cara ini Anda tidak akan berakhir dengan proyek yang gagal di akhir dan Anda akan memiliki catatan mencoba untuk mengkomunikasikan tanggal, waktu dan semua informasi yang relevan yang dapat Anda tunjukkan di akhir jika ada yang salah. Banyak hal yang membuat Anda tetap benar jika beberapa orang tidak menarik berat badannya.

Dalam hal kiat:

Saya pribadi menyukai lingkungan kerja kolaboratif yang ditemukan di sini: https://docs.google.com/

Ini memungkinkan Anda untuk berbagi dokumen kata, spreadsheet, dll. Ini adalah cara hebat untuk bekerja sama. Saya tidak bisa menekankan betapa bermanfaatnya hal ini terkadang. Saya menggunakannya dengan beberapa orang yang bekerja dengan saya yang tidak ada di negara saat ini.

Semoga ini bisa membantu seseorang, ada begitu banyak aspek dalam memimpin sebuah proyek yang bisa kita jalani selamanya tetapi itu tergantung pada banyak hal. Setidaknya ini sedikit membantu.