Mengapa kita tidak bisa menyelesaikan sesuatu?

Saya bekerja di tim kecil, di perusahaan menengah, yang sebagian besar tidak terlibat dalam pengembangan perangkat lunak. Saya adalah pengembang terbaru dan paling tidak berpengalaman dan tidak memiliki latar belakang profesional atau akademis dalam perangkat lunak sebelum memulai, tetapi saya cukup senang dengan betapa terhormatnya input saya dan saya bersyukur karena dianggap serius pada tahap awal karir saya.

Namun, saya merasa harus melakukan lebih banyak dengan jumlah airtime yang murah hati ini. Sebagai tim, kami sepertinya kesulitan menyelesaikan sesuatu. Saya ingin dapat menyarankan sesuatu untuk memperbaiki situasi, dan saya pikir saya akan didengarkan jika itu adalah ide yang baik, tetapi saya bingung apa yang harus disarankan.

Hal-hal yang dapat saya identifikasi sebagai masalah meliputi:

• Spesifikasi tugas yang dihadapi jarang. Ini sebagian karena manajemen adalah hambatan dan kami tidak memiliki uang atau orang untuk berkomitmen untuk mengerjakan persyaratan terperinci sebanyak yang kami inginkan. Ini juga sebagian karena perangkat lunak yang kami kembangkan bersifat investigatif dan metode yang tepat tidak jelas sampai diperlihatkan dan digunakan untuk menentukan efektivitasnya.
• The Dev Dev sangat menyukai apa yang dia sebut 'prototyping' sampai-sampai dia baru-baru ini mulai bersikeras bahwa semuanya 'prototyped', yang bagi kita semua seperti menulis kode yang buruk dan memberikannya kepada pemodel untuk bermain. Tidak jelas apa yang dia harapkan dari latihan ini dalam banyak kasus. Implementasi 'aktual' kemudian menderita karena desakannya bahwa praktik yang baik membutuhkan waktu terlalu lama dari pembuatan prototipe. Saya bahkan belum mulai bisa mengurai logika bengkok ini dan saya tidak yakin saya ingin mencoba.
• Para pemodel diharapkan memberi tahu kami segala sesuatu tentang metodologi yang diinginkan secara terperinci, dan sangat percaya bahwa apa yang mereka hasilkan secara teoritis tanpa cacat. Ini hampir tidak pernah benar, tetapi tidak ada tindakan yang diambil untuk memperbaiki situasi ini. Tidak ada seorangpun di sisi pemodelan yang mengajukan kekhawatiran dengan cara terstruktur yang kemungkinan akan ditindaklanjuti, juga tidak mencari bimbingan dalam menerapkan praktik terbaik. Tidak ada yang dilakukan tentang kepasifan mereka juga.
• Saya sudah mencoba untuk mendorong TDD di tim sebelumnya, tetapi merasa sulit karena ini baru bagi saya dan sementara mereka yang mengawasi pekerjaan saya mau menerimanya, tidak ada antusiasme yang muncul dari orang lain. Saya tidak dapat membenarkan jumlah waktu yang saya habiskan untuk berkubang dan tidak menyelesaikan fitur, jadi ide itu - untuk saat ini - telah ditinggalkan. Saya khawatir itu tidak akan dijemput lagi, karena tidak ada yang suka diberitahu bagaimana melakukan pekerjaan mereka.
• Kami sekarang memiliki server integrasi berkelanjutan, tetapi sebagian besar hanya digunakan untuk menjalankan tes regresi beberapa jam. Sudah dibiarkan terbuka bahwa itu harus menjalankan unit cakupan penuh dan tes integrasi juga, tetapi saat ini tidak ada yang menulisnya.
• Setiap kali saya mengangkat masalah kualitas dengan pemimpin dev, saya mendapatkan jawaban atas efek 'Fitur pengujian A sangat mudah, fitur B jauh lebih penting bagi pengguna tetapi terlalu sulit untuk diuji, oleh karena itu kita tidak boleh menguji fitur SEBUAH'. Sekali lagi saya tidak membuat kemajuan dalam mencoba mengurai logika ini.

.... Fiuh. Ketika saya mengucapkannya seperti itu, itu terlihat jauh lebih buruk dari yang saya kira. Saya kira, ternyata, ini adalah teriakan minta tolong.

Biarkan saya bermain sebagai pendukung iblis sejenak:

Spesifikasi tugas yang dihadapi jarang ... The Dev Dev sangat menyukai apa yang ia sebut 'prototyping'

Pemimpin dev gemar prototyping karena spesifikasinya jarang. Ini mungkin hal yang baik; ini adalah cara kerja toko berulang.

Para pemodel diharapkan memberi tahu kami segala sesuatu tentang metodologi yang diinginkan secara terperinci

Ini tidak akan berfungsi di toko berulang. Sifat dasar dari pengembangan berulang adalah bahwa persyaratan seringkali tidak lengkap. Iterasi adalah apa yang dibutuhkan untuk menyempurnakan persyaratan.

Saya sudah mencoba untuk mendorong TDD di tim sebelumnya, tetapi merasa sulit karena ini baru bagi saya

Ini tidak akan berhasil; Anda perlu memahami teknologinya sebelum dapat menginjili. Lebih jauh, di toko iteratif dengan persyaratan minim, TDD mungkin terlalu mahal. Lebih baik untuk mendorong cakupan pengujian unit yang memadai.

Kami sekarang memiliki server integrasi berkelanjutan, tetapi sebagian besar hanya digunakan untuk menjalankan tes regresi beberapa jam.

Itu mungkin cocok di toko kecil yang iteratif.

Setiap kali saya mengangkat masalah kualitas dengan pemimpin dev, saya mendapatkan jawaban atas efek 'Fitur pengujian A sangat mudah, fitur B jauh lebih penting bagi pengguna tetapi terlalu sulit untuk diuji, oleh karena itu kita tidak boleh menguji fitur SEBUAH'

Sepertinya toko Anda memiliki batasan waktu yang cukup ketat; suka atau tidak, Anda terikat oleh kendala itu.

Sepertinya Anda berasal dari bagian industri perangkat lunak yang menghargai melakukan hal-hal "dengan cara yang benar" daripada membawa barang ke pasar terlebih dahulu. Tidak ada yang salah dengan itu (sebenarnya mengagumkan), kecuali bahwa orang pertama yang memasarkan dengan perangkat lunak kereta seringkali adalah pemenangnya. Itu tidak adil, tapi memang begitu.

Saya akan fokus pada prototyping di sini

masalah utama dengan prototipe adalah bahwa mereka dimaksudkan sebagai bukti konsep

namun jika Anda tidak dapat membangun lebih jauh pada prototipe dan perlu membangun kembali produk akhir dari awal, Anda mungkin juga tidak membangun prototipe dan Anda membuang-buang waktu untuk membangunnya

saran saya kepada tim Anda adalah untuk mendapatkan kualitas dan fleksibilitas dalam prototipe tersebut. Saya tahu itu tidak mungkin untuk membuat hal-hal yang sempurna pertama kali tetapi mencoba untuk tetap dapat dikembangkan untuk kebutuhan di masa depan

Ini adalah jawaban yang bagus. Saya hanya dapat menambahkan bahwa "berusaha berkomunikasi" adalah yang terbaik. Perubahan cara kerja organisasi tidak terjadi dengan cepat. Ketika itu terjadi seringkali seperti gelombang, di mana momentum terbentuk dari bawah dan dari atas. Jadi Anda akan lebih bahagia jika harapan Anda tetap rendah dan menunggu kesempatan Anda untuk mengatakan bagaimana hal-hal akan dilakukan atau berharap untuk bekerja dengan organisasi lain.

Sudahkah Anda mengidentifikasi seseorang di perusahaan yang "mendapatkannya" jika demikian, mengunci orang ini dan belajar sebanyak mungkin darinya. Jika tidak, tundalah waktu Anda, mulailah belajar dan tumbuh sendiri (bergabunglah dengan proyek Open Source atau mulai proyek Anda sendiri), dan cari tempat yang dapat mendorong pertumbuhan Anda.

Hal terburuk yang dapat terjadi adalah Anda tetap di sana dan belajar melakukan hal-hal dengan cara yang salah. Ya, harus ada pragmatisme yang diambil, tetapi tim yang benar-benar terampil dapat melakukan hal-hal dengan cara yang benar dan masih tepat waktu dengan produk yang berkualitas. Sepertinya tim Anda saat ini tidak memiliki apa yang diperlukan dan Anda harus mulai mencari yang baru.