Apakah benar-benar ada hubungan antara jumlah orang yang ditugaskan untuk suatu proyek dan jumlah cacat?

12

Berikut adalah kutipan dari manual pelatihan di tempat kerja mengenai estimasi SLIM dan perangkat lunak:

Perhatikan juga, ada korelasi antara Upaya dan Cacat. Ini berarti, semakin banyak orang di sana ditugaskan untuk proyek dengan ukuran tertentu, semakin banyak Cacat akan ada.

Upaya adalah waktu orang (orang-tahun, orang-bulan) untuk proyek. Cacat adalah jumlah cacat yang terdeteksi pada titik mana pun dalam siklus hidup. Ukuran didefinisikan sebagai use case, titik fungsi, atau SLOC yang menyusun proyek.

Ini tampaknya berlawanan dengan intuisi, mengasumsikan proses yang bagus dan insinyur yang cakap. Misalnya, memiliki lebih banyak orang berarti lebih banyak mata pada semua artefak (spesifikasi kebutuhan, desain, kode, tes). Selain memiliki lebih banyak mata, intuisi saya menunjukkan bahwa ada sedikit hubungan antara upaya dan cacat pada proyek yang menggunakan teknik kualitas yang tepat.

Saya belum dapat menemukan dokumen apa pun, selain dari mereka tentang Model Putnam (yang digunakan oleh SLIM), yang menyarankan segala jenis hubungan yang diketahui antara cacat dan upaya atau cacat dan jumlah orang dalam suatu proyek. Apakah ini hubungan yang dikenal, dan apakah pernyataan bahwa "lebih banyak orang = lebih banyak cacat" valid?

— Thomas Owens
sumber

10

"menambahkan tenaga kerja ke proyek perangkat lunak yang terlambat membuatnya nanti" - Fred Brooks

— Oded

2

@Oded Menambahkan orang terlambat tidak disebutkan sama sekali. Juga, hukum Brooks tidak mengatakan apa pun tentang cacat, tetapi peningkatan saluran komunikasi untuk membuat keputusan dan membuat orang mendapat informasi. Saya menduga bahwa, seperti yang disarankan Karl Bielefeldt, kesulitan komunikasi mungkin mengarah pada cacat.

— Thomas Owens

@ThomasOwens - Ya, kutipannya memang tentang peningkatan saluran komunikasi (dan karenanya kesulitan), dengan asumsi bahwa ini akan menyebabkan cacat.

— Oded

Saya masih akan mengatakan bahwa ketika banyak pengembang dilemparkan pada suatu proyek, itu sering merupakan indikasi dari mars kematian.

— Morgan Herlocker

@ironcode Jumlah pengembang pada suatu proyek harus ditentukan oleh ukuran dan ruang lingkup proyek, dan cara mengelolanya. Memiliki terlalu banyak pengembang atau menambahkan terlalu banyak pengembang kemudian adalah tanda-tanda manajemen yang buruk, mungkin pawai kematian.

— Thomas Owens

14

Intuisi saya seperti ini:

Semakin banyak orang yang ditugaskan untuk proyek dengan ukuran tertentu, semakin besar overhead komunikasi
=> semakin tinggi kemungkinan kesalahpahaman dan segala macam masalah komunikasi
=> semakin tinggi jumlah cacat yang dihasilkan.

Dan

Pengembang yang baik lebih jarang, sehingga lebih sulit untuk menemukan dan mempekerjakan, daripada yang biasa-biasa saja / buruk
=> semakin banyak orang yang ditugaskan untuk proyek dengan ukuran yang diberikan, semakin rendah tingkat rata-rata kompetensi mereka
>> semakin tinggi jumlah cacat yang dihasilkan.

Tapi ini mungkin hanya alasan saya, saya tidak punya bukti pendukung.

Sebagai catatan tambahan, asumsi Anda yang ditekankan di bawah ini adalah IMHO (sayangnya) cukup kuat, dengan mempertimbangkan keadaan profesi kami:

Ini tampaknya berlawanan dengan intuisi, mengasumsikan proses yang bagus dan insinyur yang cakap . [...] intuisi saya menunjukkan bahwa ada sedikit hubungan antara upaya dan cacat pada proyek yang memanfaatkan teknik kualitas yang tepat .

— Péter Török
sumber

Saya menghubungkan grafik Thrashing / Proses / Produktivitas McConnell untuk menyelesaikannya. Jika Anda tidak memperkenalkan orang baru, Anda terbiasa dengan overhead komunikasi yang terlibat dalam proyek lebih awal dan mempertahankan komunikasi yang sesuai menjadi lebih mudah dan lebih alami. Ini rusak di bawah Hukum Brooks, ketika Anda menambahkan orang ke proyek terlambat, yang akan sama dengan memperkenalkan proses terlambat ke proyek - peningkatan saluran komunikasi berarti peningkatan meronta-ronta dan gangguan komunikasi yang mengarah ke cacat. Tapi aku mungkin tidak paham soal itu. Alasan Anda mungkin valid.

— Thomas Owens

Tetapi dengan lebih sedikit orang, Anda cenderung tidak akan membiarkan mereka bertahan pada kekuatan mereka. Apakah lebih mudah untuk mempekerjakan beberapa pengembang yang baik yang mungkin sebenarnya lebih baik jika mereka dapat fokus pada suatu bidang daripada hanya satu guru yang dapat melakukan segalanya?

— JeffO

@ Jeff O, Anda ada benarnya. OTOH jika masing-masing pengembang hanya berfokus pada bidangnya sendiri yang kuat, komunikasi di antara mereka mungkin semakin menyusahkan.

— Péter Török

1

Apakah komunikasi lebih merepotkan atau hanya menjadi diperlukan?

— JeffO

@ Jeff O, IMO semakin sedikit mereka mengerti tentang daerah masing-masing, semakin banyak komunikasi yang dibutuhkan, dan semakin tinggi kemungkinan kesalahpahaman dan asumsi salah.

— Péter Török

5

Itu bisa saja sebuah korelasi. Manajemen cenderung menugaskan lebih banyak orang untuk membantu proyek-proyek yang mereka anggap lebih kompleks, atau proyek-proyek yang tertinggal karena banyak bug yang tidak transparan, atau proyek-proyek yang membutuhkan banyak penggandaan di antara berbagai komponen. Jika Anda dapat mengambil keputusan manajemen dari campuran, saya curiga bahwa korelasi setidaknya akan berkurang, jika tidak terbalik.

— Karl Bielefeldt
sumber

Satu-satunya masalah dengan ini adalah bahwa perubahan (khususnya peningkatan) dalam kepegawaian dari waktu ke waktu tidak disebutkan. Itu hanya mengatakan bahwa jika Anda memiliki proyek dengan n orang, Anda akan memiliki cacat. Menambahkan orang memang menimbulkan overhead dan masalah komunikasi, tetapi itu (dari apa yang bisa saya katakan) berada di luar ruang lingkup hubungan sederhana antara orang yang cacat. Saya setuju bahwa efek samping dari menambahkan orang yang terlambat tidak hanya peningkatan saluran komunikasi dan kebutuhan untuk melatih orang dan mempercepat mereka (Hukum Brooks), tetapi juga potensi peningkatan cacat. Tapi itu di luar jangkauan.

— Thomas Owens

Menambahkan orang terlambat hanya satu faktor yang saya sebutkan. Manajemen masih memiliki kecenderungan untuk menugaskan lebih banyak orang di depan untuk proyek-proyek yang mereka perkirakan lebih berisiko atau kompleks.

— Karl Bielefeldt

Maksud SLIM (dan alat estimasi lainnya, bila digunakan dengan benar) adalah untuk membantu dengan estimasi jumlah orang yang dibutuhkan, biaya proyek, waktu yang dibutuhkan, dan sebagainya. Namun, itu memang membutuhkan alat untuk dipahami dan digunakan dengan benar.

— Thomas Owens

3

Mengingat definisi ukuran dan upaya yang baru-baru ini diperbarui, saya akan menyarankan bahwa mungkin hasilnya disebabkan oleh fakta bahwa Usaha (total jam kerja) sebenarnya merupakan penaksir yang lebih baik untuk ukuran proyek yang sebenarnya daripada ukuran yang digunakan sumber (Upaya akan menjadi ukuran sempurna jika semua tim dan sumber daya tim setara).

Karena itu apa yang sebenarnya terjadi adalah bahwa proyek yang lebih besar memiliki lebih banyak cacat, yang sama sekali tidak mengejutkan.

— psr
sumber

2

Ini tampaknya berlawanan dengan intuisi, mengasumsikan proses yang bagus dan insinyur yang cakap.

Saya tidak berpikir Anda dapat menganggap salah satu dari ini di dunia nyata. Semakin banyak orang dalam suatu proyek, semakin besar kemungkinan Anda memiliki apel buruk yang tidak dapat mengikuti dan akan memperlambat pengembang terbaik. Sekalipun Anda menggunakan asumsi, ada beberapa hal lain yang memperlambat proyek dan menyebabkan lebih banyak cacat saat Anda menambah jumlah orang:

overhead komunikasi
membaca kode di atas kepala (maksud saya bahkan pengembang terbaik pun membutuhkan lebih banyak waktu untuk membaca dan menggunakan kode orang lain daripada milik mereka sendiri)
pengujian harus lebih teliti (Kita semua memotret untuk cakupan uji 100%, tapi itu jarang terjadi di dunia nyata. Semakin banyak orang yang Anda masukkan dalam suatu proyek, refactoring yang lebih menakutkan didapat tanpa pengujian otomatis yang sangat teliti, karena Anda hanya berharap perubahan Anda tidak akan memiliki efek samping. Tidak semua tes bahkan dapat diotomatisasi dengan cara yang masuk akal, yang bahkan membutuhkan waktu lebih lama.)

Dalam pengalaman saya, efek negatif dari proyek dimuat dengan pengembang turun ketika proyek sangat modular dan Anda hanya memiliki 1 atau 2 orang per tier. Saya tidak peduli sistem kontrol versi apa yang kebetulan Anda gunakan, memiliki 4 pengembang semua checkin penggabungan otomatis ke file yang sama sekaligus mungkin akan menjadi ide yang buruk.

— Morgan Herlocker
sumber

Jika satu-satunya cara untuk mencegah 4 pengembang mengerjakan file yang sama adalah membatasi ukuran tim menjadi 3, Anda mendapat masalah yang lebih besar.

— JeffO

2

Ada perbedaan antara korelasi dan sebab-akibat; kutipan tampaknya mengatakan bahwa jumlah total cacat cenderung lebih tinggi untuk proyek-proyek di mana sejumlah besar insinyur dialokasikan. Ini masuk akal bagi saya, saya yakin MS Windows memiliki lebih banyak cacat daripada aplikasi yang saya buat, tetapi itu tidak berarti bahwa aplikasi saya berkualitas unggul.

Untuk memberikan contoh lain yang lebih abstrak - jika kita mengambil jumlah total kematian per negara dan mengaitkannya dengan jumlah total dokter di negara tersebut, saya yakin kita dapat mengatakan "negara dengan lebih banyak dokter memiliki lebih banyak kematian". Ini bukan karena dokter yang menyebabkan kematian, tetapi lebih banyak dokter yang menunjukkan populasi yang besar.

— Daniel B
sumber

Sebagai contoh Anda dengan Windows, saya yakin bahwa Windows juga memiliki lebih banyak peluang untuk cacat hanya karena lebih besar. Jika satu pengembang menulis sistem yang 10 SLOC dan sistem yang 10.000 SLOC, sistem dengan 10.000 SLOC akan memiliki peluang lebih besar untuk memiliki cacat (yang termasuk kesalahan ketik yang mencegah kompilasi, kehilangan titik koma, kesalahan titik koma, kesalahan logika, dan sebagainya) . Biasanya, proyek yang lebih besar akan memiliki lebih banyak insinyur, tetapi hubungannya bukan antara jumlah orang dan cacat, tetapi ukuran dan cacat.

— Thomas Owens

@ Thomas Owens - ya, itu maksud saya sebenarnya.

— Daniel B

Mengapa kesalahan tidak dibandingkan dengan ukuran dan kompleksitas proyek?

— JeffO

@ JeffO - Mengukurnya dengan cara yang relatif sama sekali tidak sepele (bagaimana tepatnya Anda melakukannya?). Mungkin pernyataan asli dikeluarkan dari konteks, tetapi penulis jarang merujuk pada hasil yang kompleks dan dihitung hanya sebagai "cacat". Dalam kasus seperti itu, saya akan mengharapkan kata lain seperti "kualitas" (yang menyiratkan bahwa beberapa perhitungan telah dilakukan), atau frasa yang lebih panjang seperti "cacat per insinyur yang ditugaskan". Mungkin saya bersikap sedikit sinis terhadap penulis di sini :)

— Daniel B

@ Jeff, Mereka akan. Tetapi Anda akan membandingkan cacat dengan ukuran dan kompleksitas, bukan dengan jumlah orang. Ketika ukuran dan kompleksitas meningkat, cacat meningkat dan jumlah orang bertambah. Jadi ya, meskipun jumlah orang memang bertambah, peningkatan orang itu tidak menambah jumlah cacat.

— Thomas Owens

1

Mari kita kesampingkan pernyataan tentang jumlah orang sejenak.

Melihat jumlah cacat yang disuntikkan sebagai fungsi upaya mungkin masuk akal selama Anda berasumsi bahwa peningkatan upaya tentu membutuhkan peningkatan ukuran, karena ada korelasi yang kuat antara jumlah cacat dan ukuran perangkat lunak.

Jadi jika Anda menganggap bahwa semakin banyak upaya yang dimasukkan ke dalam proyek, semakin banyak baris kode yang ditulis, maka Anda mungkin bisa menggunakan upaya sebagai proksi untuk ukuran untuk memprediksi jumlah cacat. Korelasi antara ukuran (misalnya LOC) dan jumlah cacat telah ditunjukkan berulang kali dalam pengerjaan oleh Watts Humphrey, Capers Jones, dan lainnya.

Saya tidak melihat bagaimana jumlah orang cocok, selain lebih banyak orang menyiratkan lebih banyak usaha.

Sebagai catatan, jangan bingung korelasi dengan kausalitas. Meskipun ada korelasi antara ukuran dan jumlah cacat yang disuntikkan, ukuran bukanlah penyebabnya. Penyebabnya biasanya berasal dari, seperti yang Anda tunjukkan, orang dan proses masalah. Yang mengatakan, cacat sebagai fungsi ukuran adalah metrik yang bagus untuk memahami jika ada masalah dan untuk mengukur efektivitas perubahan.

— Michael
sumber

0

Saya berasumsi ini terbatas pada anggota tim pemrograman inti dan bukan situasi di mana ada spesialis seperti: UI, UX, DBA, dll.

Saya pikir itu perlu dikelola dengan baik, tetapi itu tidak mudah. Tim kecil yang terdiri dari pengembang berkualitas dapat mengelola diri mereka sendiri. Itu lebih mungkin untuk menghindari bagian besar kode yang dibuat seseorang dengan bakat yang lebih sedikit.

Memiliki lebih banyak anggota tim dapat mempermudah pembagian tugas. Tempatkan para penyembah yang lebih baik atau lebih berpengalaman di tempat-tempat yang sulit. Singkirkan beberapa tugas biasa atau non-pemrograman dari pengembang yang lebih baik dan biarkan para junior menangani interupsi. Ini akan membutuhkan lebih banyak perencanaan dan pemikiran, tetapi memberikan kesempatan untuk meningkatkan bakat Anda.

Ada anggapan bahwa lebih baik memiliki pengembang hebat yang perlu mempelajari keterampilan baru daripada pengembang yang di bawah rata-rata yang sudah mengetahuinya. Ini bagus jika Anda punya waktu. Mungkin alasan mengapa lebih banyak develpers ditugaskan untuk suatu proyek adalah karena jumlah pekerjaan yang diperlukan dan batas waktu. Anda mungkin memiliki seseorang yang dapat fokus pada bidang tertentu dan menjadi lebih terampil. Sangat menyenangkan memiliki pengetahuan yang menyeluruh, tetapi kadang-kadang dengan sedikit arahan, dev yang lebih rendah dapat mengambil beberapa instruksi dan menjalankannya.

Kenyataannya adalah, tidak banyak orang yang pernah mengelola tim besar pada proyek yang sukses. Bahkan jika mereka semua berbakat, sulit bagi tim besar untuk mengelola sendiri. Apakah ego menghalangi?

— JeffO
sumber