Apakah KERING musuh manajemen proyek perangkat lunak?


83

Salah satu prinsip pengembangan perangkat lunak yang paling dasar dan diterima secara luas adalah KERING (jangan ulangi sendiri). Juga jelas bahwa sebagian besar proyek perangkat lunak memerlukan semacam manajemen.

Sekarang apa saja tugas yang mudah dikelola (estimasi, jadwal, kontrol)? Benar, tugas berulang, persis tugas yang harus dihindari menurut KERING.

Jadi dari perspektif manajemen proyek, itu bagus untuk menyelesaikan tugas dengan menyalin beberapa kode yang ada 100 kali dan membuat beberapa adaptasi kecil untuk setiap salinan, sesuai kebutuhan. Setiap saat, Anda tahu persis berapa banyak pekerjaan yang telah Anda lakukan dan berapa banyak yang tersisa. Semua manajer akan mencintaimu.

Jika sebaliknya, Anda menerapkan prinsip KERING dan mencoba menemukan abstraksi yang sedikit banyak menghilangkan kode duplikat, semuanya berbeda. Biasanya ada banyak kemungkinan, Anda harus membuat keputusan, melakukan penelitian, menjadi kreatif. Anda mungkin menemukan solusi yang lebih baik dalam waktu yang lebih singkat, tetapi Anda mungkin juga gagal. Sebagian besar waktu, Anda tidak dapat benar-benar mengatakan berapa banyak pekerjaan yang tersisa. Anda adalah mimpi terburuk manajer proyek.

Tentu saja saya melebih-lebihkan, tetapi jelas ada dilema. Pertanyaan saya adalah: Apa kriteria untuk memutuskan apakah seorang pengembang melakukan KERING? Bagaimana kita dapat menemukan kompromi yang bagus? Atau adakah cara untuk mengatasi dilema ini sepenuhnya, bukan hanya dengan menemukan kompromi?

Catatan: Pertanyaan ini didasarkan pada ide yang sama dengan yang saya sebelumnya, Jumlah pekerjaan rutin dalam pengembangan perangkat lunak dan pengaruhnya terhadap estimasi , tapi saya pikir itu membuat poin saya lebih jelas, jadi maaf untuk mengulangi sendiri :).


96
Beri tahu kami bagaimana perasaan manajemen proyek Anda ketika tiba saatnya untuk memburu, mengubah, dan menguji sesuatu dalam ke-100 contoh yang disalin dan ditempelkan. Dan jangan lupa waktu tambahan yang akan dihabiskan untuk mencari tahu mengapa itu akhirnya rusak karena hanya 98 dari mereka yang benar-benar berubah.
Blrfl

16
@Blrfl di sisi lain, mengeringkan kode sebelum waktunya sebelum abstraksi yang baik jelas dapat benar-benar merusak produktivitas juga, karena abstraksi bersama adalah ketergantungan bersama. Saya tidak setuju, tapi hanya menunjukkan ada keseimbangan yang bisa ditemukan.
GoatInTheMachine

16
Prinsip yang mencegah KERING keluar dari kendali adalah prinsip YAGNI (Anda tidak akan membutuhkannya) .
Philipp

88
Tidak ada dilema. Jika manajer proyek ingin Anda melakukan banyak pekerjaan manual yang berlebihan karena mudah diperkirakan, maka solusi yang jelas adalah memecat manajer proyek.
JacquesB

10
Jika Anda mengulanginya sendiri, maka Anda masih harus melakukan semua pekerjaan sulit yang diperkirakan itu , ditambah beberapa pekerjaan sia-sia tambahan. Jadi, bagaimana hal itu membantu proyek?
user253751

Jawaban:


134

Anda tampaknya menganggap tujuan utama manajemen proyek adalah untuk menghasilkan perkiraan yang tepat. Ini bukan kasusnya. Tujuan utama manajemen proyek adalah sama dengan pengembang: Untuk memberikan nilai bagi pemilik produk.

Sebuah produk yang menggunakan banyak proses manual yang lambat daripada otomasi secara teori mungkin lebih mudah untuk diperkirakan (walaupun saya ragu), tetapi itu tidak memberikan nilai-untuk-uang kepada pelanggan, jadi itu hanyalah manajemen proyek yang buruk. Tidak ada dilema.

Sudah diketahui bahwa estimasi proyek perangkat lunak itu sulit, dan banyak buku telah ditulis dan berbagai proses telah dikembangkan untuk mengelolanya.

Jika satu - satunya tujuan PM adalah menghasilkan perkiraan yang tepat, maka itu akan mudah. Cukup perkirakan perkiraan ke 10X, dan biarkan pengembang memainkan game untuk sisanya jika mereka selesai lebih awal. Ini sebenarnya akan lebih baik daripada saran Anda untuk menggunakan copy-paste busywork untuk mengisi waktu, karena bermain game tidak akan mengurangi rawatan produk.

Namun dalam kenyataannya, pemilik produk menginginkan perkiraan yang berguna dan produk berkualitas yang dikirim secepat dan semurah mungkin. Ini adalah kendala aktual yang harus dihadapi seorang PM.

Bagaimanapun, saya membantah asumsi Anda bahwa pekerjaan manual berulang lebih dapat diprediksi daripada otomatis. Semua pengalaman menunjukkan bahwa pekerjaan manual berulang lebih rentan terhadap kesalahan. Dan bagaimana jika bug ditemukan dalam kode copy paste? Tiba-tiba biaya memperbaiki bug dikalikan dengan jumlah pengulangan, yang membuat ketidakpastian meledak.


21
Saya sepenuhnya setuju dengan pernyataan Anda di sini, tetapi saya pikir perlu dicatat bahwa ada banyak manajer proyek yang buruk di luar sana yang benar-benar lebih memilih prediktabilitas daripada kecepatan atau kualitas. Kebanyakan orang yang tidak memiliki pelatihan dalam manajemen proyek mempelajari apa yang mereka ketahui tentang hal itu dari apa yang telah mereka lihat dan pengalaman saya adalah bahwa manajer proyek yang dapat menangani ketidakpastian dengan cara rasional yang tenang sangat sedikit dan jarang.
JimmyJames

5
@ FrankPuffer Saya pernah ke sana. Itu akan makan waktu berapa lama? Salah satu opsi di sini adalah untuk memberikan jangkauan. Bacalah secara khusus PERT pada estimasi 3 poin karena mereka harus sudah mengetahuinya. Persentase selesai? Ini yang paling menyebalkan. Cobalah untuk mengabaikannya tetapi jika Anda tidak dapat mengingat bahwa ini adalah waktu persentase, bukan persentase baris yang dikodekan atau apa pun. Apa yang benar-benar ingin mereka ketahui adalah Kapan itu akan selesai? Sejak awal, berikan prediksi konservatif pada setiap tugas dan sempurnakan saat Anda pergi. Menunggu sampai menit terakhir untuk mengatakan Anda lebih banyak waktu akan membuat orang gila.
JimmyJames

11
Itu akan makan waktu berapa lama? Saya 60% yakin kita bisa menyelesaikannya dengan x, tetapi ada peluang 10% akan memakan waktu lima kali lebih lama.
David

18
@ David: Ini mungkin akan membuat PM gila karena dia tahu dari pengalaman bahwa 10% peluang ini terjadi 80% kali :)
Frank Puffer

7
Kenyataannya adalah banyak tempat akan senang melacak proyek ke tanah kemudian berhasil secara tak terduga. Para PM sering diberi imbalan karena memiliki proyeksi yang akurat sehingga mereka memiliki insentif buruk. Ini adalah masalah agen utama .
Kereta luncur

39

Anda benar - salin-tempel berfungsi dengan baik, dan KERING tidak ada gunanya ketika tugas Anda adalah untuk menghasilkan program yang mana templat yang disalin atau salinan tidak harus dipertahankan atau dikembangkan di masa depan. Ketika kedua komponen perangkat lunak memiliki siklus hidup yang sama sekali berbeda, kemudian menggabungkannya bersama dengan refactoring kode umum ke lib umum yang itu sendiri di bawah pengembangan yang berat memang dapat memiliki efek yang tidak terduga untuk upaya tersebut. Di sisi lain, ketika menyalin bagian kode di dalam satu program atau sistem program, semua bagian ini biasanya memiliki siklus hidup yang sama. Saya akan menggambarkan di bawah ini apa artinya ini bagi KERING dan manajemen proyek.

Serius, ada banyak program seperti itu di luar sana: misalnya, industri permainan komputer menghasilkan banyak program yang harus dipertahankan dalam waktu singkat beberapa bulan atau satu tahun maksimum, dan ketika waktu itu berakhir, salin-tempel kode lama dari gim sebelumnya yang periode pemeliharaannya sudah ditentukan, menjadi basis kode gim baru dengan baik dan mungkin mempercepatnya.

Sayangnya, siklus hidup sebagian besar program yang harus saya tangani selama beberapa tahun terakhir sangat berbeda dari itu. 98% persyaratan atau permintaan perbaikan bug yang tiba pada saya adalah permintaan perubahanuntuk program yang ada. Dan setiap kali Anda perlu mengubah sesuatu dalam perangkat lunak yang ada, "manajemen proyek" atau perencanaan bekerja paling baik ketika upaya pengujian dan debugging Anda sangat rendah - yang tidak akan terjadi jika Anda mengubah sesuatu di satu tempat, tetapi karena menyalin Logika bisnis yang dicicipi Anda dengan mudah lupa bahwa Anda perlu mengubah selusin tempat lain di basis kode juga. Dan bahkan jika Anda berhasil menemukan semua tempat itu, waktu untuk mengubah semuanya (dan menguji perubahannya) mungkin jauh lebih tinggi seolah-olah Anda hanya memiliki satu tempat untuk berubah. Jadi, bahkan Anda dapat membuat estimasi yang akurat untuk perubahan, dengan biaya selusin kali lebih tinggi dari yang seharusnya dapat dengan mudah bertabrakan dengan anggaran proyek.

TLDR - setiap kali Anda mengembangkan program di mana tidak ada keharusan atau tanggung jawab untuk perbaikan bug dan pemeliharaan asli atau salinan, jangan ragu untuk menyalin. Tetapi jika Anda, tim Anda atau perusahaan Anda atau mungkin menjadi bertanggung jawab, terapkan KERING kapan pun Anda bisa.

Contoh

Sebagai tambahan, izinkan saya menjelaskan apa artinya "perbaikan bug dan pemeliharaan", dan bagaimana ini mengarah pada ketidakpastian dalam perencanaan, terutama di dalam satu produk, dengan contoh dunia nyata. Saya memang pernah melihat hal-hal semacam ini terjadi dalam kenyataan, mungkin tidak dengan 100 instance, tetapi masalah bahkan dapat dimulai ketika Anda hanya memiliki satu instance duplikat.

Tugas: membuat 100 laporan berbeda untuk satu aplikasi, setiap laporan tampak sangat mirip, beberapa perbedaan persyaratan antara laporan, beberapa logika berbeda, tetapi semuanya, tidak banyak perbedaan.

Dev yang mendapatkan tugas ini menciptakan yang pertama (misalkan butuh 3 hari), setelah beberapa perubahan atau perbaikan bug kecil karena QA dan inspeksi pelanggan selesai, sepertinya berjalan dengan baik. Kemudian dia mulai membuat laporan berikutnya dengan menyalin dan memodifikasi semuanya, kemudian yang berikutnya, dan untuk setiap laporan baru yang dia butuhkan rata-rata ~ 1 hari. Sangat mudah ditebak, sekilas ...

Sekarang, setelah 100 laporan "siap", program berjalan ke produksi nyata, dan beberapa masalah terjadi yang diabaikan selama QA. Mungkin ada masalah kinerja, mungkin laporan macet secara teratur, mungkin hal lain tidak berfungsi sebagaimana dimaksud. Sekarang, ketika prinsip KERING telah diterapkan, 90% dari masalah tersebut dapat diselesaikan dengan mengubah basis kode di satu tempat. Tetapi karena pendekatan salin-tempel, masalahnya harus diselesaikan 100 kali, bukan sekali. Dan karena perubahan sudah diterapkan dari satu laporan ke yang lain, dev tidak dapat dengan cepat menyalin-menempelkan perbaikan untuk laporan pertama ke yang lain 99. Dia harus melihat ke dalam semua 100 laporan, membacanya, menerjemahkan perubahan ke modifikasi melaporkan, mengujinya, dan mungkin men-debug masing-masing secara individual. Untuk PM, ini mulai menjadi sangat sulit - dia tentu saja dapat meluangkan waktu untuk perbaikan bug "reguler" (katakanlah, 3 jam) dan kalikan ini dengan 100, tetapi sebenarnya, ini kemungkinan besar perkiraan yang salah, beberapa perbaikan mungkin lebih mudah dibuat daripada yang lain, orang lain mungkin lebih sulit. Dan bahkan jika estimasi ini benar, biaya debugging 100 kali lebih tinggi dari yang dibutuhkan akan membebani Anda banyak uang.

Hal yang sama akan terjadi pada saat berikutnya ketika pelanggan meminta untuk mengubah warna lambang perusahaannya di semua laporan tersebut, untuk membuat ukuran halaman dapat dikonfigurasi, atau oleh beberapa persyaratan baru lainnya yang mempengaruhi semua laporan dengan cara yang sama. Jadi jika itu terjadi, Anda dapat membuat estimasi untuk biaya dan menagih pelanggan 100 kali lipat harga yang harus ia bayar ketika kode telah KERING. Namun, coba ini beberapa kali dan kemudian pelanggan akan membatalkan proyek karena dia mungkin tidak akan mau membayar biaya pengembangan yang selangit. Dan mungkin pada saat itu seseorang akan mengajukan pertanyaan mengapa ini terjadi dan menunjuk dengan jari pada orang yang membuat keputusan untuk pemrograman copy-paste ini.

Maksud saya adalah: ketika Anda menghasilkan perangkat lunak untuk orang lain, Anda selalu setidaknya untuk waktu yang singkat tanggung jawab membuat hal itu berfungsi, memperbaiki bug, menyesuaikan program dengan perubahan persyaratan dll. Bahkan dalam proyek lapangan hijau, ini bagian-bagian dapat dengan cepat bertambah hingga jauh melebihi upaya pengembangan yang direncanakan sebelumnya. Dan terutama ketika semua kode yang Anda salin ditempelkan di dalam satu produk, periode waktu tanggung jawab untuk semua bagian sama, yang sangat berbeda dari situasi di mana Anda menyalin-menempelkan beberapa kode lama dari proyek mati yang tidak lagi dalam pemeliharaan aktif.


4
Mungkin jawaban yang bagus tetapi terlalu verbose dibandingkan dengan jawaban baik lainnya.
Vince O'Sullivan

4
Anda dapat mengabaikan KERING ketika "salinan tidak harus dipelihara atau dikembangkan di masa depan", tetapi kode yang tidak akan pernah digunakan lagi sering berakhir digunakan lagi pula.
Andy Lester

"copy-paste bekerja dengan baik ..." - tidak setuju! Sekalipun program ini satu kali dan dijamin tidak akan pernah berevolusi melebihi rilis awal, kode salin-rekat masih membuatnya lebih berfungsi dan berisiko untuk memperbaiki bug yang ditemukan selama pengembangan versi awal program. Kecuali Anda tidak pernah melakukan kesalahan, dalam hal ini Anda adalah seorang Dewa.
JacquesB

1
@ JacquesB: Anda harus membaca jawaban saya lebih hati-hati, saya tidak menulis sesuatu yang berbeda.
Doc Brown

Pemrograman komputer hanya berbeda dari membangun mesin yang identik dengan jalur perakitan. Hah. Siapa yang akan melemparkannya? Mungkin kita harus memiliki programmer yang bekerja sebagai PM. Tetapi kemudian kita akan membutuhkan programmer sebagai manajer. Programmer sebagai pemegang saham. Pemrogram sebagai pelanggan ... Tembak, ajari semua orang bagaimana memprogram dan selesai dengannya. (Dengan kata lain: non-ahli tidak akan pernah memahami perubahan yang dikenal oleh para ahli.)

19

Jadi dari perspektif manajemen proyek, itu bagus untuk menyelesaikan tugas dengan menyalin beberapa kode yang ada 100 kali dan membuat beberapa adaptasi kecil untuk setiap salinan, sesuai kebutuhan. Setiap saat, Anda tahu persis berapa banyak pekerjaan yang telah Anda lakukan dan berapa banyak yang tersisa. Semua manajer akan mencintaimu.

Pernyataan dasar Anda salah.

Hal yang membuat perangkat lunak berbeda dari profesi lain adalah Anda membuat sesuatu yang baru setiap hari. Lagi pula, tidak ada pelanggan yang akan membayar Anda untuk membangun sesuatu yang sudah dibuat orang lain. Manajer proyek mungkin menyukai prediktabilitas, tetapi bos mereka menyukai nilai . Jika Anda hanya menyalin kode tempel dengan sedikit variasi, Anda tidak memberikan banyak nilai bagi perusahaan.

Akhirnya perusahaan akan menyadari bahwa mereka dapat melakukan pekerjaan yang sama di sebagian kecil waktu dengan mempekerjakan seorang programmer yang baik. Dan jika tidak, pesaing mereka akan melakukannya.


2
Saya berpendapat sebagian besar profesi teknik adalah tentang "membuat sesuatu yang baru setiap hari"
BlueRaja - Danny Pflughoeft

12
@ BlueRaja-DannyPflughoeft: Tidak juga. Setelah bekerja sebagai insinyur elektronik / elektrik saya dapat bersaksi bahwa sebagian besar profesi teknik skala besar (proyek-proyek yang memerlukan commissioning seperti membangun kapal dan pembangkit listrik) adalah tentang memastikan orang melakukan sesuatu mencoba dan diuji melakukannya dengan benar. Itulah yang oleh bisnis dianggap sebagai "rekayasa". Membuat sesuatu yang baru adalah "R&D"
slebetman

3
@slebetman. Mungkin Anda tidak memperhatikan semua pekerjaan yang dilakukan manajemen Anda; bahkan ketika Anda melakukan hal yang sama berulang kali, lingkungan berubah setiap saat - Anda tidak memiliki templat pembangkit listrik yang dapat Anda kirimkan kepada pelanggan dan selesai dengan itu, Anda perlu melakukan survei, mencari tahu bagaimana cara memasok pabrik dengan bahan baku dan membawa kembali produk itu, mengelola semua bahan baku untuk konstruksi dan menangani masalah pasokan dan kekurangan pekerjaan dan jutaan hal lainnya. Ini terlihat seperti pekerjaan template (seperti banyak upaya software lakukan), tapi itu benar-benar tidak.
Luaan

1
@Luaan: Ya, tapi tidak ada yang membuat sesuatu yang baru. Semuanya "melakukan sesuatu yang kita tahu bagaimana melakukannya". Pengembangan perangkat lunak berbeda. Terutama karena dalam perangkat lunak, tidak seperti proyek-proyek teknik fisik, kami cenderung merangkum hal-hal yang sudah kami ketahui bagaimana melakukannya di perpustakaan sehingga kami tidak perlu secara manual "melakukan survei" dll. Kami hanya mengimpor perpustakaan untuk itu dan menggunakannya .
slebetman

2
@slebetman Hampir semua perangkat lunak yang ditulis adalah "sesuatu yang kita tahu bagaimana melakukannya". Perpustakaan juga hidup di lingkungan yang selalu berubah. Dan Anda tidak memiliki 100% pengetahuan dan pengalaman dengan seluruh perpustakaan, dan semua dependensi perpustakaan itu dan dependensi lain yang Anda miliki, dan ada banyak sistem aneh dan konfigurasi perangkat keras yang hanya menolak untuk bekerja sebagaimana seharusnya sistem yang masuk akal kerja. Enkapsulasi memang bagus, tetapi masih mahal sekali dan membutuhkan banyak survei. Dan teknik juga memiliki enkapsulasi - blok prefabrikasi, IC, dll.
Luaan

12

Pemrograman cut-and-paste akhirnya mengarah ke perangkat lunak yang ditinggalkan. Saya adalah seorang kontraktor pada sistem untuk memesan layanan wireline dari perusahaan telepon yang sangat besar. Sistem ini cut-and-paste ad nauseum karena semua pengujian adalah manual dan mereka tidak ingin mengubah kode kerja apa pun. Peningkatan terkecil dapat menghasilkan salinan baru dari ratusan baris kode. Awalnya aplikasi ini ditulis untuk menangani akun hingga dua belas garis fisik. Tentu saja batasan ini dibuat di ratusan lokasi dalam kode. Setelah sekitar empat tahun, bisnis bertanya kepada tim apa yang diperlukan untuk menangani akun yang lebih besar. Mereka memperkirakan sekitar $ 18 juta. Pada saat itu proyek dialihkan ke tim lepas pantai untuk perawatan minimal. Semua tim yang ada diberhentikan.

Organisasi yang berpikir seperti ini dihancurkan oleh perusahaan dengan teknologi yang lebih baik.


Itu pikir itu otak yang lebih baik, daripada teknologi yang lebih baik. Teknologi berasal dari otak, bukan? Apa yang terjadi dengan "Berpikir Lebih Cerdas, bukan lebih keras"?

10

Pepatah yang sering terlupakan yang berlaku di sini adalah aturan 3 . Ini menyatakan, bahwa boleh saja menyalin kode sekali saja, tetapi di luar itu harus diganti dengan kode generik.

3 mungkin tampak seperti angka arbitrer tetapi skenario umum adalah ketika data dan logika diduplikasi dalam aplikasi dan database. Contoh yang sering dikutip adalah di mana ada tabel pencarian dalam database dan sisi klien enumerasi. Perbedaan paradigma tidak memungkinkan ini untuk mudah disimpan di satu tempat dan informasi sering muncul di kedua tempat.

Sementara itu bagus untuk memiliki kode KERING, ada kalanya logika bisnis menentukan pengecualian dan jadi Anda harus membuat dua atau lebih bit kode dari sumber yang generik sebelumnya.

Jadi - apa yang harus dilakukan? Kode untuk status quo (setelah semua, YAGNI ). Sementara kode harus ditulis untuk kemudahan modifikasi, menulis seluruh rangkaian lonceng dan peluit untuk sesuatu yang mungkin tidak diperlukan hanyalah membakar uang.


6
Perhatikan bahwa ini berarti Anda harus berkomentar bahwa Anda telah menyalin kode (di kedua tempat) sehingga Anda tahu jika Anda akan menyalinnya lagi, Anda seharusnya tidak!
Mark Hurd

3
Saya sudah melakukan ini dalam kasus di mana dua kelas membutuhkan metode yang sama tetapi hampir tidak berhubungan - seperti sepupu jauh. Saya harus menambahkan dependensi ke hampir selusin kelas agar mereka benar-benar berbagi kode. Jadi saya memang suka apa yang disarankan Mark - salin-tempel metode ini dan juga meninggalkan komentar yang jelas dan besar yang menunjukkan lokasi lain untuk metode itu.
Jeutnarg

@ MarkHurd Yap - titik bagus ...
Robbie Dee

8

Dalam pertanyaan Anda, Anda hanya mencantumkan tiga fungsi manajemen proyek - perkiraan, jadwal, dan kontrol. Manajemen proyek adalah tentang mencapai tujuan dalam batasan-batasan proyek. Metode yang digunakan untuk mencapai tujuan dalam batasan suatu proyek berbeda untuk proyek perangkat lunak daripada banyak jenis proyek lainnya. Misalnya, Anda ingin proses pembuatan sangat berulang dan dipahami dengan baik. Namun, pengembangan perangkat lunak sebagian besar pekerjaan pengetahuan- Ini tidak rutin dan membutuhkan pemikiran daripada mengikuti instruksi dan prosedur yang kaku. Teknik yang digunakan untuk memulai, merencanakan, melaksanakan, memantau dan mengendalikan, dan menutup proyek perangkat lunak akan perlu menjelaskan jenis pekerjaan yang perlu dilakukan pada proyek perangkat lunak - khususnya, pekerjaan non-rutin yang tidak dapat dilakukan untuk instruksi dan prosedur khusus.

Saya pikir masalah lainnya adalah Anda menggunakan KERING, sebuah konsep yang berhubungan dengan pengulangan informasi, dan mencoba menerapkannya dalam mengelola tugas. KERING hanya mengatakan bahwa Anda hanya boleh memiliki satu representasi informasi yang otoritatif. Manajer proyek harus merangkul ini, karena itu berarti bahwa semua orang akan tahu ke mana harus mencari informasi, mengkomunikasikan perubahan akan mudah, dan perubahan dapat dikontrol dan dikelola dengan baik. KERING, melalui bagian yang dapat digunakan kembali, membantu menekan biaya jangka panjang, membantu mempertahankan jadwal jangka panjang, dan meningkatkan kualitas - tiga bagian ke Segitiga Manajemen Proyek . Perlu ada investasi waktu dan uang yang dihabiskan untuk membuat hal-hal KERING secara efektif, tetapi tugas manajer proyek adalah membuat pertukaran waktu, biaya, jadwal, dan kualitas.


Tentu, pengembangan perangkat lunak adalah pekerjaan pengetahuan. Sebenarnya saya bahkan tidak akan menganggap contoh pertama saya (copy / paste) sebagai pengembangan perangkat lunak dalam arti yang ketat. Tetap saja, mengelola jenis pekerjaan ini jauh lebih sulit, sehingga PM, bahkan jika ia memiliki latar belakang pengembangan dan mengetahui semua ini, dalam perannya sebagai PM ia cenderung mengabaikannya. (Saya tidak mengatakan bahwa ini adalah hal yang baik, itu hanya apa yang telah saya amati berkali-kali. Saya juga tidak berpikir bahwa para PM itu bodoh atau tidak kompeten. Ini lebih seperti peran yang kadang-kadang memaksa mereka untuk bertindak seperti ini. )
Frank Puffer

3
@FrankPuffer Saya tidak setuju bahwa peran manajer proyek memaksa orang tersebut untuk membuat keputusan tertentu. Ini lebih cenderung kekuatan pendidikan atau organisasi. Dari apa yang saya lihat, sebagian besar pendidikan manajemen proyek berfokus pada teknik manajemen proyek yang lebih tradisional (mungkin karena mereka lebih umum berlaku untuk lebih banyak proyek) daripada teknik manajemen proyek perangkat lunak. Ini dapat mengalir ke organisasi yang mengharapkan ini dan tidak melihat teknik lain untuk mengelola proyek kerja pengetahuan seperti pengembangan perangkat lunak.
Thomas Owens

2
@ Frankpuffer Tentu saja lebih sulit, tetapi memberikan nilai lebih. Jika bos bos Anda cukup pintar, ia akan menyingkirkan manajer yang mencoba "membuat segalanya lebih mudah untuk dirinya sendiri" dan menemukan seseorang yang benar-benar dapat melakukan pekerjaannya. Jangan salah paham, jika membuat sesuatu menjadi lebih mudah memberikan nilai, lakukanlah - tetapi dalam apa yang Anda gambarkan, ini hampir pasti merugikan nilai akhir.
Luaan

4

Menulis kode baru hanyalah sebagian kecil dari tugas

Saran Anda akan memudahkan untuk memperkirakan bagian dari awalnya menulis kode baru. Namun, untuk benar-benar membawa sesuatu yang baru (tidak peduli apakah itu sistem baru, penambahan fitur atau perubahan fungsionalitas) melakukan hal ini tidak cukup dan hanya sebagian kecil pekerjaan - perkiraan yang terlihat dalam literatur mengatakan bahwa dalam praktiknya hal ini bagian adalah sekitar 20% -40% dari total pekerjaan.

Jadi mayoritas pekerjaan (yang mencakup mengadaptasi pengembangan awal Anda dengan apa yang sebenarnya dibutuhkan, integrasi, pengujian, penulisan ulang, pengujian ulang) tidak semakin mudah untuk diperkirakan; sebaliknya, menghindari KERING hanya membuat bagian itu jauh lebih besar, lebih keras dan dengan lebih banyak perkiraan variabel - bahwa bug atau kebutuhan-untuk-perubahan yang membutuhkan perubahan semua bagian yang dikloning mungkin tidak terjadi, tetapi jika itu terjadi, maka perkiraan Anda akan benar - benar salah.

Anda tidak mendapatkan estimasi yang lebih baik dengan meningkatkan kualitas estimasi Anda untuk sebagian kecil pekerjaan tetapi memperburuknya pada sebagian besar pekerjaan; jadi itu bukan benar-benar tradeoff tetapi situasi kehilangan-kehilangan di mana Anda mendapatkan produktivitas yang lebih buruk tetapi juga perkiraan yang lebih buruk.


Itu poin yang bagus. Namun, KERING atau prinsip serupa juga berlaku untuk tugas lain seperti pengujian atau integrasi. Kebanyakan hal dapat dilakukan dengan cara mekanis, tanpa banyak berpikir atau dengan cara yang lebih cerdas. Solusi cerdas seringkali jauh lebih cepat tetapi melibatkan risiko kegagalan. Plus, Anda harus memasukkan cukup banyak pekerjaan ke dalamnya sebelum mendapatkan hasil apa pun.
Frank Puffer

Tidak ada "risiko kegagalan", ada kepastian kegagalan. Semuanya akan gagal, cepat atau lambat. Anda hanya memilih seberapa mahal mobil jenazah dan seberapa cepat Anda mengemudi.

4

KERING bermanfaat tetapi juga dinilai terlalu tinggi. Beberapa orang bisa mengambilnya terlalu jauh. Apa yang gagal disadari oleh banyak pengembang adalah bahwa kapan pun Anda menerapkan KERING untuk menggunakan metode yang sama untuk dua (sedikit) tujuan yang berbeda, Anda memperkenalkan semacam penggabungan yang sangat ketat antara berbagai penggunaan. Sekarang setiap kali Anda mengubah kode untuk kasus penggunaan pertama, Anda juga harus memeriksa apakah itu mengurangi penggunaan kasus kedua. Jika ini adalah kasus penggunaan yang luas secara independen, itu sangat dipertanyakan apakah harus benar-benar digabungkan - mungkin tidak.

Terlalu banyak menggunakan DRY juga dapat menyebabkan metode-Tuhan yang meledak dalam kerumitan untuk menangani semua kasus penggunaan yang berbeda, ketika metode atom yang lebih kecil yang mereplikasi beberapa kode akan jauh lebih dapat dipertahankan.

Namun, saya akan menyarankan bahwa pertanyaannya tidak benar-benar relevan di tingkat manajemen proyek. Seorang manajer proyek benar-benar tidak ingin memusatkan perhatian pada tingkat detail implementasi ini. Jika ya, itu mungkin pengelolaan mikro. Sungguh ... bagaimana hal-hal diimplementasikan lebih merupakan tanggung jawab pengembang dan pimpinan teknis. Manajemen proyek adalah lebih peduli dengan apa yang akan dilakukan dan ketika .

EDIT: per komentar, namun saya setuju bahwa sejauh membuatnya lebih mudah untuk memperkirakan waktu pengembangan, menghindari KERING kadang-kadang dapat mengurangi jumlah ketidakpastian. Tapi saya percaya ini adalah masalah yang tidak signifikan dalam kaitannya dengan pertanyaan yang lebih mendesak dari (1) berapa lama sampai persyaratan bisnis dipenuhi, (2) utang teknis apa yang diambil dalam proses, dan (3) risiko terhadap total biaya kepemilikan pilihan arsitektur yang dibuat - apakah akan KERING atau tidak dalam banyak kasus merupakan pilihan desain yang harus lebih didasarkan pada risiko / penghargaan terhadap faktor-faktor tersebut, daripada apakah itu membuatnya sedikit lebih mudah untuk memberikan informasi yang lebih akurat kepada manajer proyek dengan lebih akurat. .


Tentu saja manajer proyek tidak boleh berurusan dengan detail implementasi. Itu bukan poin saya. Maksud saya adalah, tergantung pada cara pengembang mengimplementasikan sesuatu, ia kurang lebih dapat memberikan informasi yang diperlukan untuk manajemen proyek.
Frank Puffer

Tidak masuk akal bagi saya untuk merusak / membatasi produk atau membangun hutang teknis hanya untuk dapat melaporkannya dengan lebih baik. Nilai laporan pastilah urutan besarnya lebih rendah dari nilai kualitas pekerjaan. Tapi YMMV
Brad Thomas

Mungkin programmer harus dibayar lebih besar daripada manajer?

2

Saya pikir Anda salah paham KERING.

Mari kita gunakan sebuah contoh:

public Class A
{
    public int Multiply(int x, int y)
    {
        return x * y;
    }
}

public Class B
{
    public int Multiply(int x, int y)
    {
        return x * y;
    }

    public int Add(int x, int y)
    {
        return x + y;
    }
}

vs.

public Class C : A
{
    public int Add(int x, int y)
    {
        return x + y;
    }
}

Dengan mengganti kelas B dengan C kami telah mengikuti prinsip KERING dan mengurangi duplikasi kode. Tetapi kami belum meningkatkan hal yang tidak diketahui atau risiko terhadap proyek (kecuali jika Anda belum pernah melakukan warisan sebelumnya).

Saya pikir apa yang Anda maksud ketika Anda berbicara tentang KERING adalah sesuatu yang lebih mirip tugas desain. Yaitu:

public Class A
{
    public int Multiply(int x, int y)
    {
        return x * y;
    }
}

!!! Persyaratan baru! Beberapa klien harus dapat menggandakan gandakan !!

// Use class B for new clients!!
public Class B
{
    public int Multiply(double x, double y)
    {
        return x * y;
    }
}

vs.

public Class A // Version 2
{
    public int Multiply(int x, int y)
    {
        return Multiply(x as double, y as double);
    }

    public int Multiply(double x, double y)
    {
        return x * y;
    }
}

Di sini (dengan asumsi itu berfungsi) kami telah merancang solusi yang dapat menangani baik persyaratan lama DAN baru, pada dasarnya mencoba membuat model matematika dari masalah kehidupan nyata atau aturan bisnis. Dalam kehidupan nyata sistem yang kami modelkan jelas akan jauh lebih rumit, model kami tentangnya tidak akan pas, dan kasus tepi dan hasil yang tidak terduga akan membutuhkan waktu untuk ditemukan dan diperbaiki.

Jadi, haruskah kita mengambil B atau A versi 2 dalam kasus ini?

  • B akan lebih spesifik untuk perubahan yang diminta sebenarnya dengan efek samping yang lebih sedikit dan lebih mudah untuk diperkirakan dan lebih cepat dilakukan.

  • Versi 2 akan menghasilkan kode keseluruhan yang lebih sedikit ke depan dan akan menjadi solusi yang lebih elegan

Sekali lagi saya akan mengatakan itu datang ke kualitas spesifikasi dan persyaratan.

Jika kita memiliki spesifikasi yang sangat jelas yang mencakup kasus tepi dan kompatibilitas ke belakang maka kita dapat yakin bahwa kita memahami sistem dengan cukup baik untuk memperbaiki model tanpa menghasilkan bug.

Jika kami memiliki permintaan darurat untuk satu pelanggan di mana satu-satunya persyaratan adalah bahwa perubahan perilaku untuk pelanggan itu tanpa mempertimbangkan sistem keseluruhan; kemudian 'meningkatkan' model dengan refactoring A membawa risiko yang cukup besar. Baik melanggar pelanggan lain atau melampaui batas waktu karena waktu tambahan yang tidak diketahui diperlukan untuk merancang dan menguji solusi.


7
Saya tidak setuju. Warisan bukanlah sesuatu yang Anda lakukan sekali dan kemudian menguasainya. Ada banyak jebakan. Ada alasan mengapa komposisi lebih disukai daripada warisan. Jadi kita harus membuat keputusan: Warisan? Komposisi? Sesuatu yang lain Keputusan ini mungkin akan sulit di dunia nyata. Dalam contoh kedua ada juga banyak alternatif. Bagaimana dengan obat generik / templat? Mungkin beberapa pendekatan fungsional menggunakan lambdas? Sekali lagi: Banyak kemungkinan yang masing-masing akan memiliki implikasi spesifik.
Frank Puffer

4
Intinya adalah pada contoh pertama Anda secara literal menghapus kode duplikat melalui metode apa pun. tetapi kode yang sama persis mengeksekusi cara baik. Jadi tidak ada perubahan fungsionalitas. Dalam contoh kedua, Anda mengubah pendekatan ke sesuatu yang Anda harapkan berfungsi eqivilant tetapi sebenarnya kode yang berbeda
Ewan

1
Saya berada dalam situasi di mana "permintaan darurat" Anda adalah norma. Perusahaan tempat saya bekerja menciptakan sistem data khusus untuk banyak pelanggan berbeda. Awalnya mereka membuat satu sistem dengan Cobol, kemudian menyalinnya untuk pelanggan berikutnya, dll, hingga mereka memiliki 100 pelanggan. Sekarang mereka memiliki pekerjaan di tangan mereka mencoba membuat perbaikan dan pembaruan yang sistematis. Saya sedang mengerjakan suatu sistem yang dapat mereplikasi perilaku sebagian besar sistem ini, menggunakan satu set kode sumber, tetapi penyesuaian disimpan dalam data konfigurasi. Kami tidak dapat melakukan segalanya, dan beberapa hal tidak dapat ditambahkan.

1

Paragraf demi paragraf

Salah satu prinsip pengembangan perangkat lunak yang paling dasar dan diterima secara luas adalah KERING (jangan ulangi sendiri). Juga jelas bahwa sebagian besar proyek perangkat lunak memerlukan semacam manajemen.

Benar.

Sekarang apa saja tugas yang mudah dikelola (estimasi, jadwal, kontrol)? Benar, tugas berulang, persis tugas yang harus dihindari menurut KERING.

Tugas berulang harus diotomatisasi, wajib . Mereka membosankan, rentan kesalahan, ketika dibuat dengan tangan.

Jadi dari perspektif manajemen proyek, itu bagus untuk menyelesaikan tugas dengan menyalin beberapa kode yang ada 100 kali dan membuat beberapa adaptasi kecil untuk setiap salinan, sesuai kebutuhan. Setiap saat, Anda tahu persis berapa banyak pekerjaan yang telah Anda lakukan dan berapa banyak yang tersisa. Semua manajer akan mencintaimu.

Saya pikir Anda dapat mengubah kata "adaptasi" dengan "konfigurasi". Anggap Anda memiliki bug dalam kode ini yang seharusnya disalin. Bug yang muncul dalam kondisi tertentu. Jika tidak diperbaiki dalam sumber aslinya, dan disalin akan ada banyak tempat untuk diperbaiki. Ini mungkin buruk, tetapi kemudian seseorang harus:

  • pertama-tama perbaiki kode di sumber aslinya;
  • perbaiki kode di setiap tempat lain;
  • pastikan itu semua tempat. Ketika Anda mengatakan ini harus dilakukan kepada manajer, dia mungkin setidaknya akan membenci seseorang.

Jika sebaliknya, Anda menerapkan prinsip KERING dan mencoba menemukan abstraksi yang sedikit banyak menghilangkan kode duplikat, semuanya berbeda. Biasanya ada banyak kemungkinan, Anda harus membuat keputusan, melakukan penelitian, menjadi kreatif. Anda mungkin menemukan solusi yang lebih baik dalam waktu yang lebih singkat, tetapi Anda mungkin juga gagal. Sebagian besar waktu, Anda tidak dapat benar-benar mengatakan berapa banyak pekerjaan yang tersisa. Anda adalah mimpi terburuk manajer proyek.

Menghapus duplikasi mengarah ke satu titik kegagalan. Jika ada yang gagal, Anda bisa yakin di mana ini terjadi. SOLID dan Pola Desain ada untuk membantu memperbaiki masalah itu. Tenggat waktu yang terlalu pendek cenderung memprovokasi "coding" gaya prosedural. Lebih banyak waktu yang diinvestasikan dalam satu proyek untuk membuat sesuatu yang dapat digunakan kembali berarti harus ada jumlah minimal waktu yang dihabiskan dalam proyek berikutnya ketika fitur tersebut akan digunakan kembali, tetapi harus dapat dikonfigurasi di tempat pertama.

Tentu saja saya melebih-lebihkan, tetapi jelas ada dilema. Pertanyaan saya adalah: Apa kriteria untuk memutuskan apakah seorang pengembang melakukan KERING? Bagaimana kita dapat menemukan kompromi yang bagus? Atau adakah cara untuk mengatasi dilema ini sepenuhnya, bukan hanya dengan menemukan kompromi?

Banyak orang menunjuk tidak ada dilema di sini. Iya dan tidak.

Jika Anda memiliki sesuatu yang sangat eksperimental yang belum pernah dilakukan sebelumnya - tidak ada dilema. Kalau tidak, jika Anda memiliki sesuatu yang harus dilakukan lagi, seperti sistem pemesanan baru Anda sudah memiliki abstraksi, hanya tergantung apa yang Anda butuhkan.

Saya pikir dilema adalah - haruskah kita mengimplementasikan sesuatu dalam fitur, jika tidak mungkin diminta. Terapkan sesuatu saat diminta. Tidak ada yang membutuhkan infrastruktur besar yang tidak akan digunakan.


Menerapkan sesuatu dengan cara yang sederhana dan cepat sekarang, karena itu diminta. Kemudian, ketika cara yang rumit diperlukan, upaya orisinal itu sia-sia, harus memulai dari awal. Manajer tidak suka ini. Seolah-olah Anda berkata, "Menghabiskan waktu mengemudi ke barat tidak berguna jika sekarang kita perlu pergi ke timur." Tapi pergi jauh-jauh keliling dunia pertama kali supaya kita bisa pergi ke timur selama ini juga membuang waktu.

1

ini sama sekali bukan tentang merancang untuk digunakan kembali di masa depan atau tentang prinsip YAGNI. Ini adalah tentang pengulangan kode dalam paket pekerjaan saat ini.

Ini benar-benar tentang desain. Mungkin tidak digunakan kembali , tetapi desain tetap.

Apa kriteria yang harus diputuskan jika pengembang melakukan KERING?

Pengalaman dan lingkungan / situasi Anda saat ini. Untuk masalah yang diberikan Anda akan mendapatkan pemahaman yang kuat tentang Prinsip Prado saat Anda mencoba tingkat KERING yang lebih besar. Kemudian tiba-tiba muncul pertimbangan manajemen. Waktu, sasaran, pelanggan, manajemen kode jangka panjang (seseorang berkata utang teknis ), dll. Akan menginformasikan rencana serangan Anda.

Bagaimana kita dapat menemukan kompromi yang bagus?

Uh ... desain? Refactoring adalah desain, memang seharusnya begitu. Ruang lingkup PENGERINGAN dapat dengan mudah berkembang seperti super nova dari loop, ke metode, ke kelas. Pernah ke sana, melakukan itu. Tapi Anda tidak bisa benar-benar tahu sampai Anda mempelajari masalahnya - ini adalah desain.

Bagaimana tidak menjadi masalah desain? Anda harus mempertimbangkan masalah lebih luas daripada kode duplikat langsung yang ada. Ini adalah aktivitas desain apakah itu kode yang ada atau lembar kosong; apakah itu "ekstrak metode" atau membuat kelas dan modul baru.

Epilog

... pertanyaan dan jawaban yang dimaksud tidak mencakup aspek manajemen proyek.

Manajemen khas, mengabaikan waktu desain. Kami akan, idealnya, mendesain pengulangan yang berlebihan sebelum pengkodean. Alih-alih, manajemen menganggap pengembangan (dan perbaikan bug) adalah satu peristiwa Olimpiade - pengkodean - padahal sebenarnya merupakan dasalomba. Dan mereka mengukur 1/1000 detik karena mereka pikir itu semua analog.

Jika sebaliknya, Anda menerapkan prinsip KERING dan mencoba menemukan abstraksi yang sedikit banyak menghilangkan kode duplikat, semuanya berbeda.

Saya memiliki pengalaman ini: "Saya menghabiskan dua hari menulis baris ini (dari formulir GUI) dan dua jam menulis sisa formulir." Maksud saya, saya meluangkan waktu untuk mengidentifikasi kelas yang dapat digunakan kembali - KERING menjadi efek samping alami - baris formulir GUI dan dengan beberapa yang lain. Setelah didebug, ini digunakan, secara individu dan dalam komposisi, di seluruh bentuk yang sekarang dikodekan sangat cepat dan pengujian sangat cepat meskipun ada kerumitan yang bertambah. Dan itu terbang melalui pengujian formal juga dengan tingkat bug yang sangat rendah.

Sebagian besar waktu, Anda tidak dapat benar-benar mengatakan berapa banyak pekerjaan yang tersisa. Anda adalah mimpi terburuk manajer proyek.

Saya juga tidak tahu, tetapi saya yakin upaya desain depan akan membuahkan hasil. Kita semua mengatakan ini tetapi manajemen khususnya tidak mempercayainya. Manajemen akan berpikir saya sedang bermain-main. "Dua hari dan kamu bahkan belum memiliki 2% dari kode itu!"

Dalam satu kasus kami terjebak di senjata kami ketika manajemen mengatakan "Anda menghabiskan terlalu banyak waktu dalam desain, mulai." Dan rekan kerja mengatakan "terlalu banyak kelas." Ya, sub-proyek yang jauh lebih kompleks seharusnya memakan waktu sekitar 1 bulan (saya pikir itu tebakan tebakan rata-rata) tetapi membutuhkan waktu 5 bulan. 3 bulan itu dalam pengujian / perbaikan karena itu adalah POS. "Tapi kami tidak punya waktu untuk mendesain!". Mereka sebenarnya mengatakan itu.

Pertanyaan saya adalah: Apa kriteria untuk memutuskan apakah seorang pengembang melakukan KERING? Bagaimana kita dapat menemukan kompromi yang bagus? Atau adakah cara untuk mengatasi dilema ini sepenuhnya, bukan hanya dengan menemukan kompromi?

Tunjukkan kepada manajemen cara kerjanya. Tangkap beberapa data. Bandingkan dengan pekerjaan lain, terutama rekan kerja Anda yang melakukan pekerjaan slap-dash rush. Tumpukan kegagalan itu tampaknya selalu kalah dalam balapan, macet saat ujian dan kemudian setelah rilis kembali berulang kali untuk memperbaiki lebih banyak bug.


"Ukur dengan mikrometer, tandai dengan kapur, potong dengan kapak."
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.