Apa yang harus dilakukan dengan tim pengembangan yang kelaparan? [Tutup]


10

Ini menyebalkan berada di jalur kritis sebagai pengembang normal, terutama jika Anda terlambat. Ketika Anda adalah pengembang senior, yang dicari oleh tim untuk kepemimpinan, itu bahkan lebih buruk.

Ketika pekerjaan untuk sebagian besar tim terhenti menunggu bagian penting apa yang harus dilakukan oleh anggota tim lainnya? Kami memiliki akses terbatas ke bagian kritis sehingga orang lain hanya akan menunggu apa pun yang kami lakukan. Ketika yang lain mencari nasihat tentang apa yang harus dilakukan, apa jawaban yang bagus?


10
Sudahkan Anda nol utang teknis untuk dibayar? Apakah ada bagian fungsionalitas yang direncanakan untuk masa depan yang dapat Anda spike? Teknologi atau paradigma baru yang ingin Anda coba dalam fungsionalitas yang ada?
jonrsharpe

27
@StudentT yang terlihat sangat pendek, mengingat kemungkinan kesulitan dalam meningkatkan tim kembali setelah pemblokir telah dipecahkan.
jonrsharpe

8
@StudentT, bukan pemimpin, harus dipecat karena tidak merencanakan masa depan, tidak mengantisipasi hal-hal seperti ini bisa terjadi.
jwenting

13
Dev kelaparan? Satu kata: pizza.
Mason Wheeler

3
Jika OP tidak memiliki utang teknis untuk dibayar dan tidak ada tes unit / fungsional atau skrip penerapan untuk menulis / meningkatkan, dia pasti mengeluh dari Deaven (Dev Heaven) dan saya tiba-tiba sangat sedih: <
xDaizu

Jawaban:


29

Tingkatkan tes unit, tes fungsional, dokumentasi, alat, dll. Ada banyak hal yang dapat dilakukan di down-time sambil menunggu jalan kritis untuk mengejar ketinggalan.


2
Ini. Rata-rata dev (termasuk saya) terus mengeluh tentang kurangnya waktu untuk memperbaiki hal-hal. Pegang mereka untuk itu.
Traubenfuchs

4
Saya suka jenderal ini "melakukan apa pun yang Anda belum bisa". Saya akan menambahkan ulasan kode dan refactoring untuk itu. Jadikan perangkat lunak yang sangat rapi yang bekerja seperti mesin yang diminyaki dengan baik dan menyenangkan untuk dilihat. Itu memuaskan bagi para pengembang.
Peter - Pasang kembali Monica

hal-hal yang tidak cukup penting untuk dilakukan sebelumnya mungkin masih belum layak dilakukan sekarang. itu hanya membuat pekerjaan '
Ewan

16

Meskipun saya menyukai jawaban tentang peningkatan tes, dokumentasi, dll., Dan ini bagus, Anda juga dapat melihat:

  • Dengan membantu komponen jalur kritis, apakah akan berjalan lebih cepat dengan pemrograman tim / teman?
  • Merestrukturisasi komponen penting menjadi beberapa sub-komponen yang dapat dikerjakan semua orang.
  • Bersihkan komponen penting dengan sesuatu, mungkin kasar, yang pada dasarnya melakukan pekerjaan yang sama tetapi mungkin tidak cukup cepat untuk produksi.
  • Buat API untuk komponen penting, perbaiki itu kurang lebih di batu, dan bantu untuk mendapatkan fungsionalitas dasar untuk komponen itu diimplementasikan, (bisa berubah jika implementasi tetapi bukan API).
  • Lihat apakah Anda dapat mengambil versi awal, yang diketahui bermasalah, dari komponen kritis untuk bekerja pada sisa sistem di mana fungsionalitasnya "cukup baik untuk saat ini".

Ini juga merupakan ide yang baik untuk memulai fase "pembelajaran" sekarang dengan mencatat bahwa komponen-komponen penting seperti itu harus dimulai lebih awal dalam proses pengembangan, mungkin sebelum anggota tim lainnya dibentuk.


2
Saya suka alternatif "selalu ada sesuatu untuk diperbaiki". Jika cukup baik, lebih baik fokus pada masalah saat ini dan mencari solusi yang tepat.
Walfrat

15

Anda memerlukan rencana cadangan untuk pengiriman terlambat Anda

Jika potongan kritis sudah terlambat, tidak ada jaminan itu tidak akan tergelincir lagi. Lalu bagaimana? Anda hanya menunggu selamanya? Itu bukan jenis jawaban yang ingin Anda sampaikan kepada manajemen tingkat atas.

Bangun simulator

Salah satu cara untuk mengelola risiko adalah mulai bekerja pada simulator (harness, shim, stub, apa pun yang Anda ingin menyebutnya) untuk menggantikan bagian yang hilang.

Apakah memiliki antarmuka yang ditentukan? Terapkan itu.

Apakah ada dokumentasi terperinci? Tirulah sebaik mungkin.

Apakah itu hanya ide seseorang? Lihat apakah Anda bisa mendapatkan prototipe.

Kemudian, ketika mereka menyelipkan jadwal lagi ....

Dengan begitu, ketika mereka menyelipkan jadwal lagi, Anda memiliki kartu as di saku belakang Anda untuk menutup celah. Tim Anda tidak hanya akan diblokir (mereka dapat berintegrasi dengan simulator), tetapi Anda akan mendapatkan aset perangkat lunak yang berharga.

Jika jadwal mereka tergelincir lebih banyak, gunakan waktu untuk menulis tes integrasi otomatis (melawan simulator Anda, untuk saat ini). Dengan begitu, ketika mereka memberikan hal yang nyata, Anda bisa menjalankan tes Anda dan mendeteksi perbedaan perilaku antara maket dan yang disampaikan. Ini akan membuat Anda membidik titik yang harus Anda revisi. Sebagai bonus, Anda akan segera mendapatkan gagasan tentang seberapa banyak mereka memotong sudut saat waktu mereka habis.


Simulator tidak perlu lengkap atau fantastis, cukup hanya untuk memungkinkan Anda untuk membuat kemajuan.
Thorbjørn Ravn Andersen

1
Saya pikir ini sangat baik dan saran tidak segera jelas. Terutama perspektif di luar coding, yaitu tes. Mock adalah nilai ganda.
Peter - Pasang kembali Monica

4

Jika komponen kritis memiliki antarmuka yang dikenal dan jika tidak ada harapan untuk menyelesaikannya dalam waktu singkat, mengapa tidak membuat tes ganda (misalnya mock )?

Ini akan memungkinkan tim untuk melanjutkan pengkodean, meskipun hasil tes akan sedikit kurang bermakna.


2

Terlepas dari "melakukan semua hal yang tidak sempat Anda lakukan sejauh ini", sepertinya Anda dan tim Anda tidak memiliki ketenangan pikiran untuk melakukan sesuatu yang tidak terkait dengan proyek yang terlambat. Yang bisa dimengerti tetapi tidak membantu.

Jadi masalah sebenarnya mungkin santai tentang hal itu. Saya tidak mengatakan acuh tak acuh. Jadilah sadar akan tanggung jawab Anda, apa yang dapat Anda lakukan untuk membantu dan jika itu membuat Anda punya waktu, nikmati saja. Anda tidak dapat dan tidak harus selalu berada di ujung jari Anda sepanjang waktu. Jika Anda seorang pemimpin, saya akan mengatakan ini harus menjadi pesan Anda. Mentransfer kegugupan Anda ke tim tidak akan menghasilkan tim yang lebih produktif ketika penting.


0

Anda tidak mengatakan metodologi apa yang Anda gunakan yang membuatnya sulit untuk memberi saran secara tepat.

Di mana saya bekerja jika ada pemblokir, itu semua tangan ke pompa melakukan apa pun yang mereka bisa untuk mempercepat pengembangan.

Pertimbangkan apakah mungkin ada masalah yang lebih luas dengan Anda sebagai pemimpin yang mengambil terlalu banyak. Ya, orang akan mencari Anda untuk kepemimpinan teknis tetapi itu tidak berarti beberapa anggota tim Anda yang lebih mampu tidak dapat berbagi beban kerja jika mereka dibimbing.

Selain itu, apakah ada pekerjaan non-kritis lain yang bisa mereka jalani? Juga, apakah ada pekerjaan yang telah mereka selesaikan yang dapat dipoles lebih lanjut (refactored, menghapus utang teknis, dokumentasi, menambahkan tes, dll).

Jika benar-benar tidak apa-apa, memberikan sesuatu mereka - pergi melalui log, membangun, dokumen, rencana uji, desain, diagram, menulis agenda, mengatur pertemuan, mengadakan sesi tas coklat, berbagi pengetahuan dll ada selalu sesuatu untuk dilakukan. Jika orang rela hanya duduk-duduk saja tanpa melakukan apa pun pada koin perusahaan yang seharusnya ditingkatkan karena mereka jelas bukan pemain tim.

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.