Di dunia yang ideal lebih disukai untuk memenuhi tenggat waktu dengan bug yang lebih sedikit. Tapi dari pengalaman Anda yang lebih disukai / diterima:

1. Memenuhi tenggat waktu tetapi memiliki sejumlah bug karena pengembang terburu-buru dalam hal-hal
2. Lebih sedikit bug tetapi tidak cukup memenuhi tenggat waktu karena pengembang sangat ketat dalam menulis kode

Jawaban untuk pertanyaan ini sangat tergantung pada tujuan bisnis, serta klien.

Perusahaan :

Jika Anda melakukan bisnis dengan klien tingkat perusahaan yang mapan di pasar, mereka kurang fleksibel dan tidak dapat beradaptasi dengan perubahan dengan cepat. Karena itu, stabilitas merupakan syarat mutlak dalam banyak kasus. Ada pengecualian untuk penelitian dan pengembangan dan memasukkan vertikal baru. Lebih cepat selesai lebih dulu dalam beberapa kasus.

Klien jenis ini umumnya memahami bahwa perangkat lunak yang baik membutuhkan waktu untuk berkembang, dan akan bekerja dengan Anda untuk mencoba dan memenuhi tujuan.

Startup :

Untuk startup baru, aturannya sangat berbeda. Sebagai startup, Anda harus segera mengetahui apakah produk yang Anda bangun memang akan memenuhi kebutuhan sesuai prediksi riset pemasaran Anda. Untuk pemula, mengeluarkan prototipe di pasar secepat mungkin dapat mengumpulkan banyak umpan balik yang berharga tentang arah produk yang harus dituju.

Itu juga dapat menjadikan Anda sebagai pemimpin pasar, membantu Anda mendapatkan pangsa pasar yang berharga dalam vertikal baru sebelum menjadi jenuh dengan persaingan.

Karena startup kecil, fleksibel, dan dapat dengan cepat beradaptasi dengan perubahan, model ini paling cocok untuk mereka.

Singkatnya, ada faktor-faktor lain yang perlu dipertimbangkan, tetapi gagasan utamanya adalah bahwa setiap proyek berbeda dan akan memiliki kualitas dan waktu yang berbeda untuk sasaran pasar. Terserah kepemimpinan eksekutif untuk menentukan strategi bisnis yang efektif yang mencakup analisis menyeluruh tentang biaya peluang dalam memilih satu metode di atas yang lain.

atau ... 3. Potong fungsi yang tidak penting

Kadang-kadang, karena permen teknis atau fitur permen yang diminta oleh klien, tenggat waktu sulit dipenuhi dan secara inheren jumlah bug yang lebih besar muncul. Ini adalah prinsip KISS dan YAGNI yang diterapkan.

Mengutip dari buku ini , "Rework", esensi / inti / pusat gempa dari perangkat lunak Anda adalah apa yang dibutuhkan bisnis untuk berfungsi, seperti halnya hot dog dapat menjadi hot dog tanpa topping apa pun, yang tidak dapat Anda hentikan adalah hot dog.

Renegosiasi ulang

Salah satu hal tersulit untuk dipelajari adalah bagaimana membuat klien senang, dan dalam pengalaman saya, ini bisa lebih mudah dicapai dengan iterasi produk yang lebih kecil.

Kadang-kadang tenggat waktu menuntut perangkat lunak bekerja pada tingkat produksi yang berat sejak hari pertama. Manajer / klien tidak selalu tahu (yang sebagian besar waktu) apa yang sebenarnya mereka butuhkan untuk perangkat lunak. Jadi cobalah untuk memotong fungsionalitas yang tidak penting dan menjaga kualitas. Pada akhirnya itu tergantung pada seberapa kritis lingkungan produksi akan, tetapi cobalah untuk memotong fitur tambahan dan memberikan kualitas. Mengutip lagi dari "Rework":

Melakukan kemudian juga berarti melakukan yang lebih baik

... dan juga memenuhi tenggat waktu dengan bug yang lebih sedikit

Nah, Anda dapat membingkainya dengan cara ini: apakah Anda ingin membayar untuk kualitas sekarang atau nanti? Luangkan waktu untuk melakukannya dengan baik di tempat pertama, atau habiskan waktu kemudian memperbaiki semua masalah. Saya berpendapat bahwa fase perbaikan bug pasca-fitur-pengembangan ini mungkin lebih mahal karena juga bisa lebih berisiko dan lebih rentan terhadap solusi peretasan karena kode yang ada sudah ada dan mungkin kualitasnya tidak cukup tinggi.

Memenuhi tenggat waktu, dan menyajikan daftar masalah yang Diketahui .

Orang-orang BENCI menemukan bug, tetapi jika mereka diberitahu di depan, mereka cenderung jauh lebih lunak.

Ini sepenuhnya tergantung pada situasi ....

Ada banyak faktor yang perlu dipertimbangkan:

1. Seberapa mudah untuk meluncurkan tambalan?
2. Apakah mungkin untuk merilis versi dasar, strip-down dan kemudian menambal fungsionalitas baru (tepi kasus) di waktu ke waktu?
3. Apa budaya umum dari industri klien untuk produk seperti itu? Apakah mereka mengharapkan rilis sempurna satu kali, atau apakah mereka terbiasa dengan gagasan sistem yang berkembang yang mungkin bermasalah ketika pertama kali dirilis?
4. Seberapa besar risiko terhadap bisnis yang ditimbulkan oleh versi awal buggy, yang bertentangan dengan penghancuran tenggat waktu?

Singkatnya, tidak ada jawaban hitam dan putih untuk ini. Misalnya: Untuk sesuatu seperti sistem tertanam yang sulit dan mahal untuk diluncurkan ke perangkat di lapangan, mungkin yang terbaik adalah mencoba menunggu (renegosiasikan tenggat waktu jika memungkinkan) dan keluarkan sebagai bebas bug. Di sisi lain, untuk sesuatu seperti sistem portal web besar (ditulis sebagai aplikasi web) yang dapat dengan mudah ditingkatkan kapan saja dengan meluncurkan perbaikan saat keluar, mungkin lebih masuk akal untuk merilis versi yang awalnya cerdik, dan kemudian tambal masalah (dan fungsi tepi kasus) saat Anda mendapatkannya.

Tetapi pada akhirnya, menurut pengalaman saya, ini lebih merupakan keputusan bisnis daripada keputusan teknologi. Jika Anda berada dalam situasi di mana tidak ada tenggat waktu adalah masalah besar, sementara versi awal kereta tidak (atau sebaliknya) - Anda harus mempertimbangkan hal-hal ini saat mengambil keputusan.

CATATAN: Sebagai seorang programmer, tentu saja saya lebih suka ide memoles produk sebanyak mungkin sebelum melepaskannya (heck, saya lebih suka tidak ada tenggat waktu sama sekali;)). Tetapi secara realistis, ini tidak mungkin dalam kehidupan nyata. Seringkali, rilis awal yang dilucuti adalah solusi jalan tengah yang baik.

Saya telah melihat banyak PM takut memberitahu klien bahwa kami tidak dapat memenuhi jadwal dan bersikeras kami mengirim dengan bug yang diketahui. Saya dapat memberi tahu Anda bahwa setiap kali mereka memberi tahu klien, ia biasanya jauh lebih tertarik pada lebih sedikit bug dan tenggat waktu yang dipindahkan. Saya jamin mereka akan mengingat bug lebih dari tenggat waktu yang terlewat kecuali jika tenggat waktu benar-benar tidak dapat digerakkan (seperti dimulainya musim pengajuan pajak ketika Anda melakukan perangkat lunak pajak) atau akan memengaruhi beberapa hal lain yang akan sangat mahal untuk dipindahkan (IMHO 98% dari semua tenggat waktu tidak memenuhi kriteria ini).

Saya pikir itu tergantung pada bug. Apakah Anda ingin menunda rilis untuk memperbaiki bug saat aplikasi mogok saat diluncurkan di komputer mana pun? Iya tentu saja. Apakah Anda perlu memperbaiki bug yang terjadi hanya pada Windows ME saat ada bulan purnama? Itu mungkin bisa menunggu.

Jika itu adalah bug yang kritis, lebih baik untuk melakukan yang kedua tangan ke bawah. Alasannya adalah karena biaya lebih mahal untuk memperbaiki jika Anda harus mendorong perbaikan itu dalam pembaruan.

Untuk pembaruan yang kurang penting, Anda dapat merilis pembaruan yang dibundel yang mengurangi biaya tersebut hingga tingkat tertentu.

Jika ragu, saya katakan Anda memilih # 2, tapi saya tidak akan terkejut mendapatkan pushback dari manajemen dengan pendekatan itu. Saya menduga bahwa manajer cenderung lebih banyak dinilai oleh seberapa baik mereka memenuhi tenggat waktu daripada tidak menyebabkan pembaruan penting yang tidak perlu.

Tidak juga. Mengapa tidak membuat kualitas dengan kode Anda? Mampu memenuhi tenggat waktu dengan kode kualitas? Anda mungkin mendorong lebih sedikit fitur, tetapi jika kualitas dimasukkan ke dalam proses Anda dapat mencapai keduanya.

Apa yang terjadi sekarang adalah Anda akan memerlukan pemimpin tim atau manajer pengembangan yang dapat memberikan dorongan bisnis kembali dan melakukan percakapan seputar 2 hal:

1. Kualitas dimasukkan ke dalam kode = 2 lebih sedikit fitur per build
2. Memprioritaskan fitur yang paling dibutuhkan dari para pemangku kepentingan untuk apa yang BENAR-BENAR mereka butuhkan.

Kemudian Anda dapat fokus pada fitur bernilai tinggi dan mendorong mereka keluar dengan keunggulan.

Sejauh menyangkut pengujian itu tidak pernah selesai. itu sudah berakhir tetapi tidak pernah selesai.

Pergi untuk peluncuran dengan bug dengan tingkat keparahan dan lebih banyak prioritas diurus.

Memenuhi tenggat waktu dengan banyak bug membuat Anda miskin di industri ini, dan pelanggan tidak akan mendatangi Anda lagi. Anda dapat berbicara dengan pelanggan untuk mendapatkan penundaan selama dua atau tiga hari.

Jika Anda melihat ini dari pengguna akhir, saya akan sangat kesal jika seseorang berjanji untuk melakukan sesuatu untuk hari Senin dan ketika saya mencoba menggunakannya tidak berfungsi, atau semuanya buggy.

Tetapi jika Anda melihat sisi "prosedural", itu berarti bahwa aplikasi tersebut membutuhkan lebih banyak pengujian dan bagian dari kehidupan alami perangkat lunak.

Pendekatan terbaik saya adalah mencoba membuat segala sesuatunya berfungsi sebagaimana mestinya (jika ini adalah modul utama, jangan memperhatikan detail, masuk dalam bentuk harus masuk tetapi siapa pun akan terhapus jika Anda tidak menampilkan pemberitahuan setelah itu).

Ini adalah pertanyaan yang hanya bisa Anda jawab. Itu tergantung pada jenis produk, siapa pelanggannya, apa yang dituntut pelanggan, dll. Tidak ada cara bagi kita untuk memberikan jawaban sederhana 'a atau b'. Ini sepenuhnya tergantung pada situasi.

Tetapi saya akan mengingatkan Anda bahwa biaya untuk memperbaiki bug setelah rilis jauh lebih tinggi daripada memperbaiki sebelum rilis. Jadi faktor bahwa ketika memutuskan apakah akan menunggu atau tidak sampai rilis rilis untuk memperbaiki bug, karena Anda akan menghabiskan lebih banyak waktu / usaha / uang di atasnya.