Mengatasi proyek tanpa akhir yang tidak dapat diperbaiki

Kami memiliki situs web besar (1200+ jam) yang memiliki banyak hutang teknis. Ini terutama disebabkan oleh alasan (biasa) berikut ini.

1. Banyak programmer yang datang dan pergi selama pengembangan.
2. Perubahan spesifikasi selama pengembangan.
3. Banyak fungsi ditambahkan ditambahkan (dalam waktu singkat).

Pelanggan menginginkan banyak fungsi baru, dan yang pada dasarnya datang untuk mengerjakan proyek ini setiap minggu selama 10+ jam.

Karena hutang teknis, kami menghabiskan BANYAK jam untuk memperbaiki atau menyelidiki masalah, yang biasanya menemukan sumbernya di salah satu dari yang berikut:

1. Bug yang tidak tahu malu dan konyol yang membuat orang menangis.
2. Fitur baru menghasilkan hal di atas karena kami belum melihat semua tempat yang akan dipengaruhi oleh fitur baru.
3. Beberapa masalah lain yang kami hadapi (migrasi server, peningkatan)

Kami memiliki masalah setiap hari dan kami telah mencoba mengikuti beberapa hal untuk menghentikan ini:

1. Membuat dokumentasi teknis mengenai impor, pembayaran dan kerja umum situs web.
2. Adakan pertemuan pada awal minggu - membahas masalah atau perbaikan saat ini dan bagaimana mereka harus ditangani.
3. Memiliki rencana uji. Programmer A tes B, B tes C dan C tes A. Kemudian Manajer Proyek kami akan melakukan beberapa tes. Mengenai dampak dari fitur tersebut, kami melemparkannya ke lingkungan pementasan dan membiarkan pelanggan memeriksa sendiri.

Masalahnya adalah bahwa masalah terus terjadi ... dan entah bagaimana kita tidak bisa mengatasinya. Fitur baru masih menyebabkan bug, dan bug lama terus menyapa. Entah bagaimana - mungkin karena ukuran proyek - kita sepertinya tidak bisa menguasai proyek ini.

Saya berasumsi ada banyak programmer yang bekerja pada proyek yang lebih besar maka ini. Itu sebabnya saya sampai pada pertanyaan saya:

Apa yang bisa kami lakukan, atau apa yang Anda lakukan untuk menghindari masalah ini pada proyek besar?

Edit minor, info tambahan:

1. Kami menggunakan kontrol versi (SVN).
2. Kami memiliki proses pengembangan DTAP.

Saya akan berperan sebagai penasihat iblis, setelah terlalu sering melihat bagaimana ini terjadi: Anda tidak bisa mengatasinya. Saya jamin Anda satu-satunya yang benar-benar melihat masalah nyata dengan sistem seperti itu, atau Anda tidak perlu bertanya bagaimana cara mengatasinya karena budaya perusahaan akan menjadi satu untuk memberantas bug dan memperbaiki kode sedapat mungkin yaitu mengoperasikan cara kerja profesional sejati.

Saya yakin terlalu besar untuk mulai menulis tes unit, karena tidak ada orang yang tahu bagaimana melakukan tes sebelum Anda (dan dengan keberuntungan orang lain di tim Anda) dan tidak mungkin untuk mengetahui dari mana harus memulai, dan mungkin bahkan tidak mungkin untuk uji karena bergantung pada implementasi yang tepat dan data konkret, sehingga akan terlalu lama untuk menghapus semua itu untuk antarmuka, tiruan, bertopik dan sejenisnya untuk dapat mengujinya di tempat pertama. Saya juga yakin Anda tidak bisa hanya pergi dan refactor apa yang perlu di refactored karena terlalu erat digabungkan dan, karena tidak ada tes, siapa yang tahu apa yang akan rusak dengan memperbaiki kode yang buruk. Singkatnya, itu mungkin menjadi terlalu kanker untuk diperbaiki secara serius, tetapi tentu saja itu tidak bisa dihentikan begitu saja dan mulai segar.

Anda bertempur dalam kekalahan, temanku. Entah Anda akan kelelahan karena frustrasi dan akhirnya berhenti atau menjadi gila, atau jika Anda mengeluh tentang hal itu cukup lama untuk membuat orang lain menyadari masalah tersebut, mereka akan berpikir satu-satunya masalah adalah Anda dan Anda akan ditunjukkan pintu.

Hal-hal yang menguji unit adalah titik awal yang baik jika Anda tidak melakukannya. Paling tidak mereka akan melindungi Anda dari menambahkan bug baru ketika memperbaiki bug lama.

Kontrol sumber juga membantu, kecuali jika Anda tidak menggunakannya. Fitur menyalahkan dan mencatat, khususnya, sangat bagus untuk mengetahui bagaimana / mengapa sepotong kode kereta pernah dikomit.

Di sisi pelanggan, saya menemukan bahwa membahas harga dan penundaan (lama) segera setelah perubahan / fitur tambahan diminta bekerja dengan cukup baik, seperti halnya pengisian untuk waktu yang Anda habiskan untuk mendiskusikan / mendesainnya. Seringkali, pelanggan akan memutuskan bahwa pada pemikiran kedua mereka bisa menunggu.

(Sebaliknya, jika Anda segera menggali spesifikasi dan ide implementasi dengannya, mereka biasanya akan mengatur Anda untuk "oh, saya pikir kami telah setuju Anda akan tetap melakukan ini" atau (lebih buruk, setelah beberapa hari kembali dan sebagainya pada spesifik) "tapi lihat, itu sudah dirancang dan kita apa yang kita diskusikan tidak terdengar sulit!".)

Terakhir, saya menemukan bahwa di muka saya hanya membaca email sekali sehari (setelah tiba di tempat kerja), dan saya memiliki telepon untuk hal yang lebih mendesak, mengarah pada peningkatan produktivitas yang luar biasa.

Saya sarankan Anda menambahkan beberapa pengujian berbasis CI, terutama pada area yang paling sering rusak. Itu akan membantu Anda meningkatkan kualitas saat pekerjaan sedang dilakukan pada proyek.

Ini juga menjadi lebih jelas area / fungsi mana yang lebih sering rusak dan dengan demikian lebih mudah untuk memutuskan bagian mana yang perlu di-refactoring, atau setidaknya peningkatan pengujian.

Menambahkan lebih banyak risiko pengujian manual jika proyek salah jalan dalam hal $$$ & waktu yang dibutuhkan per fitur ditambahkan.

Beberapa ulasan kode bagus, tapi mungkin itu bagian dari skema pengujian A-> B-> C-> A. (Mungkin ulasan kode di arah lain?)

Biarkan saya melempar dongeng kepada Anda. Anda berjalan-jalan dengan seseorang sebelumnya di jalan dan Anda mencapai tujuan. Orang yang Anda ajak jalan bersama dengan cepat mengetahui bahwa ia kehilangan cincinnya di suatu tempat di sepanjang jalan sehingga Anda berdua memutuskan untuk mundur dan pergi mencarinya. Orang yang Anda ajak berjalan dengan cepat berhenti di tiang lampu dan mulai terlihat panik. Anda berkata, "Mengapa kamu melihat di sana di tiang lampu ketika saya pikir kamu mungkin kehilangan itu ketika kita memotong lorong?". Dia menjawab, "Saya tahu tetapi cahayanya lebih baik di sini."

Saya telah berada dalam situasi ini lebih dari beberapa kali dan saya telah memperhatikan beberapa kesamaan. Jenis-jenis proyek mimpi buruk pemeliharaan ini biasanya dijalankan dalam lingkungan proses yang berat dengan pengawasan berat dan peningkatan proses yang diberlakukan oleh manajemen. Saya tidak mengatakan perbaikan proses adalah hal yang buruk tetapi lebih sering daripada tidak jenis perbaikan proses yang biasanya ingin diberlakukan Manajemen memiliki dua poin utama.

1) Mereka umumnya tidak mengganggu politik kantor dan keseimbangan kekuasaan. 2) Mereka berhasil menciptakan ilusi kontrol oleh manajemen daripada menyerang inti masalah.

"Cahaya lebih baik di sini" yang biasanya dipikirkan manajemen dengan mengatakan, "Setiap fitur baru harus memiliki spesifikasi teknologi terperinci", atau "Mari kita rapat status setiap jam setiap hari untuk membahas masalah dan cara mengatasinya."

Tidak satu pun dari hal-hal ini yang benar-benar menyentuh inti permasalahan dan mereka mungkin hanya menurunkan produktivitas tetapi mereka jelas memvalidasi ilusi kontrol oleh manajemen.

Satu-satunya perubahan nyata yang dapat Anda dorong adalah perubahan yang mengguncang segalanya. Saya menduga meskipun bahwa keganjilan situs web Anda mungkin tidak dapat diperbaiki pada saat ini dan Anda akan lebih jauh ke depan untuk mendesain ulang dan menulis ulang. Namun untuk masa depan, Anda dapat mengingat pentingnya metodologi Agile, Integrasi Berkelanjutan, Pengembangan Berbasis Tes, Tinjauan Kode, dan spesifikasi persyaratan bisnis yang diatur dalam prosedur Kontrol Perubahan yang ketat untuk membantu meminimalkan creep lingkup tanpa penyesuaian jadwal.

Perubahan seperti ini benar-benar membutuhkan perubahan cara berpikir di tingkat manajemen dan dalam seluruh pengalaman profesional saya, saya tidak pernah mengalami hal ini terjadi tanpa semacam perombakan tingkat manajemen menengah. Saya harap itu tidak terlalu mengecilkan hati karena Anda harus mencoba apa yang benar terlepas dari apakah Anda sedang berjuang keras, karena Anda mungkin akan menghadapi perlawanan sengit oleh orang-orang yang menyukai status-quo.

Saya sudah berada di tempat yang sama beberapa waktu lalu. Saya tidak lagi berkat dua aturan sederhana:

• Setiap minggu satu, atau dua hari dihabiskan untuk memperbaiki / menulis ulang sebagian besar aplikasi berbulu. Tidak ada pencarian bug, tidak ada pengembangan fitur baru.
• Sementara menerapkan fitur-fitur baru, kami berusaha keras untuk memperbaikinya bahkan ketika kami menghabiskan lebih banyak waktu dari yang diharapkan pelanggan.

Satu-satunya masalah adalah membuat orang lain menghormati mereka. Bagian yang mudah ternyata adalah pelanggan. Tidak dapat menjelaskan mengapa, tetapi entah bagaimana kami telah meyakinkannya, bahwa ketika kami mengerjakan fitur sedikit lebih lama, itu lebih baik untuk semua orang. Menghormati aturan pertama ternyata lebih bermasalah, tetapi kami juga merasa ini sangat membantu kami. Ini menjamin kemajuan yang stabil karena berbagai bagian aplikasi menjadi lebih baik.

Ulasan kode. Tes unit. Pengujian QA nyata. Spesifikasi proses pengumpulan dan pengembangan tambahan - ini adalah beberapa hal yang harus menyelesaikan sebagian besar masalah Anda.

Juga jangan biarkan pelanggan melakukan ping langsung ke pengembang Anda - Ini biasanya cara paling tidak produktif untuk menyelesaikan masalah. Pekerjakan manajer Program yang baik yang akan membentuk antarmuka antara pelanggan dan pengembang Anda. Tugasnya adalah untuk mengetahui produk ujung ke ujung, status saat ini, arah masa depan dan sebagainya. Setiap kali pelanggan menginginkan fitur baru lainnya, ia harus dapat memberikan daftar barang saat ini dan menunjukkan kepada pelanggan apa yang akan terbentur jika permintaan baru ini diambil.

Proses buruk ketika digunakan terlalu sedikit atau terlalu banyak. Saya pikir Anda berada di negara bagian sebelumnya.

Seperti yang disebutkan Deni, jika Anda dapat menambahkan pengujian unit ke proyek, maka ini akan membantu Anda. Lakukan tes yang mencakup bagian dari sistem yang akan Anda ubah / perbaiki, dan saat kode refactoring Anda, gunakan tes itu sebagai panduan untuk memastikan Anda tidak melanggar apa pun.

Juga, triase bagian kode yang paling rusak. Cobalah untuk menempatkan mereka yang terkena dampak terburuk ke dalam daftar risiko dan mengelola risiko-risiko itu secara mandiri. Cobalah untuk mendapatkan gambaran tentang seberapa banyak kode yang rusak di basis kode dengan menanyakan di mana bug paling sering terjadi. Anda kemudian dapat mencantumkan area yang terpengaruh oleh jumlah bug (atau masalah yang dilaporkan, apa pun yang sesuai untuk Anda.).

Menambal dan membersihkan kode akan memakan waktu, tetapi jika masing-masing pengembang di tim dapat meninggalkan kode sedikit lebih bersih maka itu sebelum mereka memalsukannya, maka seiring waktu basis kode akan meningkat. Jika Anda mencari yang cepat, gaya tentara, dapatkan solusi sekarang diurutkan, saya ragu bahwa ada sesuatu yang praktis (atau disarankan) yang akan membantu.

Bersulang. Jas.

Tulis spesifikasi fungsional yang jelas; pedantic jadi jika Anda tahan dan tinjau fungsionalitas terhadap spesifikasi tersebut secara teratur. Semakin sedikit ide yang dimiliki seorang dev tentang apa yang seharusnya ia kembangkan, semakin sedikit kesempatan untuk mengembangkannya.

Sebelum Anda mulai menulis kode, lakukan beberapa pekerjaan desain di muka; ini tidak harus sempurna, atau besar, atau mengandung UML, tetapi harus menguraikan solusi yang cukup solid untuk masalah yang perlu dipecahkan. Sejauh yang saya tahu, semakin sedikit perangkat lunak yang direncanakan, semakin buruk. Diskusikan desainnya sebelum Anda mulai mengerjakannya.

Ketika Anda mulai bekerja pada area kode yang jelas-jelas buruk dan benar-benar menghambat kemajuan Anda; berhenti menambahkannya, mundurlah dari masalahnya, cari tahu bagaimana Anda bisa mendesain ulang arsitektur sehingga hambatan tidak ada dan sehingga akan lebih mudah beradaptasi di masa depan. Semakin lama Anda meninggalkannya sebelum Anda mengatasi hutang teknis semakin sulit untuk mengatasinya tanpa penulisan ulang penuh. Saya akan mengatakan itu adalah hal yang eksponensial.

Tes desain yang menguji perilaku dan jangan berpasangan dengan arsitektur Anda. Ini tidak terlalu modis, tetapi saya akan mengatakan jangan mulai menguji sampai tujuan sebenarnya dari kode Anda jelas. Secara khusus jangan mulai pengujian sampai Anda tahu apa yang benar-benar ingin Anda uji; IMO tes yang dipikirkan dengan buruk lebih buruk daripada tidak ada tes. Dan semakin banyak tes yang Anda miliki semakin sulit untuk mengubah kode Anda secara internal. Perlakukan kode tes Anda seperti halnya kode produksi; itu perlu direncanakan dan ditulis dengan baik.

Lakukan tinjauan kode harian / reguler: ini lebih lanjut tentang pemeriksaan kewarasan untuk memastikan dev tidak pergi terlalu jauh. Gunakan sesi ini untuk merencanakan pekerjaan hari berikutnya. Mungkin ada hari-hari ketika ini memakan waktu 5 menit, atau 1 jam; intinya adalah menjaga dialog tetap terbuka dan memberi pengembang kesempatan untuk mendiskusikan pekerjaan mereka dengan pengembang lain dan mencari saran. Lakukan beberapa sesi berpasangan pada bagian yang sulit dari kode, atau untuk membuat prototipe ide, tetapi biarkan orang-orang memiliki waktu sendiri untuk bekerja.

Buat mudah untuk membangun dan menggunakan kode Anda. Usahakan agar waktu build tetap pendek. Semakin mudah membangun semakin banyak dibangun, semakin cepat semakin banyak dibangun.

Mengadopsi standar pengkodean dan menegakkannya dengan kaku. Ini harus mencakup semuanya, mulai dari di mana proyek harus hidup dalam sistem file hingga casing pribadi const. Ini mungkin tampak tidak berguna dan menjengkelkan, tetapi kebiasaan baik adalah landasan dari proses pengembangan.

Pada dasarnya saya tidak berpikir bahwa proses yang Anda gunakan terlalu banyak, mode datang dan pergi. Yang benar-benar penting adalah bahwa Anda profesional tentang cara mengembangkan perangkat lunak dan disiplin dalam praktik Anda.

Saya akan mulai dengan merancang dan mengotomatisasi tes asap, dan melemparkannya ke lingkungan CI. Itu harus fungsional. Ketika pelanggan memberi tahu Anda bahwa ada sesuatu yang harus dilakukan begitu-dan-begitu, mintalah untuk menuliskannya, sehingga Anda dapat merujuknya nanti. Ketika Anda melihat solusi tertentu dalam perangkat lunak, ajukan pertanyaan, dan segera setelah Anda menerima jawaban, masukkan mereka ke dalam basis pengetahuan, dan buat mereka dapat dilacak.

Yakinkan, bahwa fungsi dasar untuk case positif berfungsi. Kemudian mulailah membangun pengujian bertahap untuk penanganan data yang salah, menempatkan cacat jika dianggap perlu. Lakukan diskusi panjang dan mendalam tentang prioritas, dan minta manajer tes menyadarinya, sehingga ia dapat menetapkan waktu pengujian yang sesuai. Jangan mencoba mengotomatisasi semuanya, tetapi segera, karena beberapa testcas masuk akal untuk diotomatisasi - jangan ragu.

Secara umum, gunakan pengujian untuk meningkatkan kepercayaan pada produk, dan bukan sebagai alat yang secara instan akan meningkatkan kualitas. Tenang, namun asertif :). Mungkin upaya menjadi gesit, tetapi hanya jika Anda benar-benar positif dapat menggunakan PM bersertifikat. Memperkenalkan Agile oleh seseorang yang tidak tahu Agile, kemungkinan besar akan membunuh proyek.