Aturan sembilan puluh sembilan dalam praktek

24

90 persen pertama dari kode menyumbang 90 persen pertama dari waktu pengembangan. Sisanya 10 persen dari kode menyumbang 90 persen lainnya dari waktu pengembangan.

- Tom Cargill, Bell Labs

Apa yang sebenarnya dimaksud dalam praktik? Programer itu melakukan banyak pekerjaan dan mereka memberi 180% dari diri mereka sendiri atau?

programming-practices theory

— Josip Ivic
sumber

2

Kita semua tahu bahwa 100% didefinisikan ulang dengan melampauinya, atau 1,8 kali jumlah yang diketahui. Dalam hal ini, bagaimanapun, saya akan mengatakan itu mungkin hiperbola. Sembilan puluh persen kedua ada di sana untuk membuatnya mudah diingat, dan menambahkan kalimat pembuka di akhir kutipan.

— AJFaraday

1

Taksiran untuk waktu pengembangan berubah di tengah kalimat.

— milleniumbug

180% adalah jumlah waktu dan anggaran yang diakibatkan oleh biaya proyek.

— Agent_L

1

Saya pikir sangat jelas apa yang ditanyakan pertanyaan ini meskipun ada kalimat terakhir yang aneh.

— Matthew James Briggs

2

Kutipan ini seharusnya dibaca sebagai lelucon, dalam konteks itu masuk akal. Dikatakan 10% terakhir akan memakan waktu lebih lama dari yang Anda bayangkan

— Richard Tingle

40

Bayangkan seperti ini: Ketika Anda mulai bekerja pada perangkat lunak Anda dapat menulis kode dalam jumlah besar dalam waktu yang relatif singkat. Kode baru ini dapat menambahkan sejumlah besar fungsi baru. Masalahnya adalah, seringkali, fungsi itu jauh dari "selesai", mungkin ada bug, perubahan kecil (kecil dalam bisnis kecil) dan sebagainya. Jadi perangkat lunak mungkin merasa hampir selesai (90% selesai), karena mendukung sebagian besar kasus penggunaan. Tetapi perangkat lunak masih perlu bekerja. Poin dari aturan ini adalah bahwa meskipun perangkat lunak merasa hampir selesai, jumlah pekerjaan untuk membawa perangkat lunak itu ke dalam kondisi kerja yang benar adalah sebesar mencapai kondisi "hampir selesai". Itu karena memperbaiki bug sering memakan waktu tetapi tidak menghasilkan banyak kode.

Masalahnya adalah bahwa sebagian besar pengembang memperkirakan mendapatkan perangkat lunak dalam keadaan "hampir selesai", karena itu relatif sederhana dibandingkan dengan benar-benar memperkirakan upaya total perangkat lunak akan mengambil.

— Euforia
sumber

3

Sebagian besar alasan ilusi 90-90 adalah bahwa insinyur perangkat lunak sering memvisualisasikan jalur keberhasilan - menyerahkan kasus kesalahan & pengecualian adalah renungan. Jika desain asli tidak memperhitungkan kasus kesalahan probabilitas rendah, kemungkinan akan perlu revisi sebelum perangkat lunak dapat disebut selesai.

— Rumbleweed

1

+1 tetapi saya merasa paragraf kedua membutuhkan beberapa teks tebal karena itulah bagian yang sangat penting dari pelajaran :)

— Bob Tway

20

Ini adalah referensi ke skenario umum, yang sayangnya masih terjadi hari ini:

Tim diminta untuk memperkirakan (yaitu menebak) jumlah pekerjaan yang dibutuhkan untuk menulis semua kode,
Proyek berlanjut dengan berbagai tekanan internal dan eksternal untuk "tetap tepat waktu dan anggaran",
Jadi untuk persentase yang signifikan dari proyek, "sesuai target" dilaporkan. Ini sering diperparah dengan memilih tugas-tugas mudah terlebih dahulu untuk memastikan kemajuan yang baik dibuat.
Kemudian pada tahap tertentu, titik kritis tercapai di mana kenyataan harus diterima: proyek tidak akan selesai tepat waktu dan tanggal rilis akan didorong kembali (sering berkali-kali).

"90%" adalah angka yang sewenang-wenang, tetapi itu membuat titik dengan baik: perkiraan adalah dugaan dan kemungkinan akan salah (sering sangat salah) dan sifat manusia memastikan kita hampir selalu di bawah perkiraan, jadi semuanya dibanjiri.

— David Arno
sumber

14

Apa yang disebut "gesit" tidak melakukan apa pun untuk menyelesaikan masalah; itu hanya mendistribusikannya di antara barang-barang yang lebih kecil, di mana rasio yang persis sama terjadi pada skala absolut yang lebih kecil, bahkan jika Cargill sedang bercanda. Intinya adalah bahwa setiap proyek memiliki beberapa hal kecil yang memakan banyak waktu pengembangan.

— Blrfl

3

@ Blrfl Jawabannya tidak menyiratkan bahwa gesit menyelesaikan masalah estimasi menjadi sulit, tetapi ia mengurangi konsekuensinya dengan membuat estimasi yang lebih kecil.

— Eric

Saya kira ini bukan hanya masalah manajemen sumber daya. Sangat mudah untuk membuat prototipe 90% proyek dengan cepat & kotor, tetapi 10% sisanya akan membutuhkan BANYAK waktu, karena sering kali di sini kita peduli untuk sepenuhnya memenuhi persyaratan awal. Saya menggunakan embedded system dan saya dapat memberikan demo suatu produk kepada salesman berbulan-bulan sebelum rilis produk, dan dia akan melihat hampir tidak ada perbedaan antara demo dan produk akhir, tetapi yang pasti demo tersebut tidak dapat dikirim. Bug, pengoptimalan, fitur canggih, konsumsi daya, itulahother 90%

— Tim

Percayalah padaku bahkan dengan Agile sial menghantam kipas dan meledak!

— JonH

2

Menghapus pemikiran tentang kelincahan karena hal itu jelas mengalihkan perhatian orang dari poin utama jawabannya.

— David Arno

7

Saya telah mendengar versi lain dari ini (juga disebut "aturan 90-90") yang berbunyi seperti ini:

Setelah saya menerapkan 90% fungsionalitas, saya masih harus mengimplementasikan 90% lainnya .

Kedua versi mengacu pada kesulitan dalam memperkirakan upaya untuk mengembangkan produk perangkat lunak dan perangkap umum yang cenderung membuat orang jatuh ke dalam:

melempar statistik di luar sana ketika estimasi diperlukan dan pada dasarnya menebak ("Saya 80% selesai")
fokus pada kompleksitas algoritmik dari kode yang akan ditulis, dengan merugikan volume pekerjaan (meremehkan upaya yang diperlukan untuk tugas-tugas umum)
langkah yang hilang ("tidak terlihat, keluar dari pikiran")
meremehkan upaya untuk mempertahankan dan mengubah kode yang ada
upaya meremehkan yang diperlukan untuk kode boilerplate / "lem"

— utnapistim
sumber

6

Aturan ini melengkapi aturan 80-20. Sekarang, ada banyak interpretasi berbeda dari aturan 80-20, tetapi dua yang paling saya sukai adalah:

Pengembangan produk 80% pertama membutuhkan 20% usaha.
80% kesalahan ada di 20% dari kode.

Dalam praktiknya, ini berarti yang berikut: pengembangan akan mulai dan berlanjut hingga titik tertentu kapan penundaan pertama akan diperhatikan. Penundaan dapat dari berbagai sifat:

Kontrol kualitas yang buruk, menghasilkan bug
Persyaratan tambahan yang diajukan oleh pelanggan di sepanjang jalan (dan alasannya juga bisa beragam)
Persyaratan yang tidak jelas sejak awal, yang mengakibatkan menjatuhkan bagian dari pengembangan sebelumnya (yang mungkin juga menghasilkan bug regresi)
Perkiraan awal karena ruang lingkup tidak jelas, kesalahan manusia atau keadaan yang tidak terduga. Keadaan yang tidak terduga ini dapat berupa dedaunan yang sakit, pengunduran diri, kegagalan perangkat keras, atau, dalam kasus ekstrim, letusan gunung berapi (begitu kami harus menunda proyek karena kami tidak dapat terbang di lokasi karena letusan gunung berapi di Islandia).

Intinya adalah bahwa lebih mudah mendekati sasaran daripada benar-benar mencapainya.

— Vladimir Stokic
sumber

1

Aturan 80-20 juga dikenal sebagai en.wikipedia.org/wiki/Pareto_principle

— Peter M. - singkatan dari Monica

4

Saya menemukan penjelasan Wikipedia cukup mencerahkan:

Ini menambahkan hingga 180% dalam kiasan masam akan kemasyhuran proyek pengembangan perangkat lunak secara signifikan melebihi jadwal mereka (lihat estimasi upaya pengembangan perangkat lunak). Ini mengungkapkan baik alokasi waktu yang kasar untuk bagian proyek pemrograman yang mudah maupun yang sulit dan penyebab keterlambatan banyak proyek sebagai kegagalan untuk mengantisipasi bagian-bagian yang sulit. Dengan kata lain, dibutuhkan lebih banyak waktu dan lebih banyak pengkodean daripada yang diharapkan untuk membuat suatu proyek berhasil.

— Nadir Sampaoli
sumber

1

Apa yang sebenarnya dimaksud dalam praktik? Programer itu melakukan banyak pekerjaan dan mereka memberi 180% dari diri mereka sendiri atau?

Tidak, programmer selalu melakukan jumlah pekerjaan yang sama per unit waktu. Kutipan tentang biaya yang di bawah perkiraan dan overruns. 180% adalah jumlah waktu dan uang yang diakibatkan oleh biaya proyek.

Ini kira-kira berarti "Ini akan membawa Anda dua kali lebih lama dari yang Anda pikirkan" dan "Anda akan berpikir Anda baik-baik saja sampai sudah terlambat (batas waktu sudah dekat)".

— Agent_L
sumber

1

Apa artinya ini dalam praktik adalah bahwa orang membohongi diri mereka sendiri.

Jika seorang programmer mengatakan "kita sudah selesai 90%" itu berarti 90% dari upaya untuk membangun fitur telah dikeluarkan.

Jika seorang manajer proyek mengatakan "kita sudah selesai 90%, saya hanya perlu seseorang untuk menyelesaikannya" itu berarti mereka 90% melalui anggaran (dan mungkin 50% selesai). Ini adalah klien tanpa uang, harapan tinggi, dan sikap buruk.

Perbedaannya adalah dibutuhkan lebih banyak usaha daripada fitur pengkodean untuk menyelesaikan suatu proyek: qa, perbaikan bug, salin pengeditan, penyebaran.

Hal-hal itu perlu dikelola dalam proyek, dan merupakan tanggung jawab manajer proyek. Ini sering mengejutkan PM baru yang meluncurkan "90% fitur selesai" hanya untuk menyadari bahwa mereka hanya setengah jalan ke "proyek selesai".

— Michael Cole
sumber