Saya baru saja memulai pekerjaan dengan Scrum dan sepertinya ada sesuatu yang hilang. Saya baru di Scrum

23

Kode ini adalah kekacauan total dari kombinasi ASP / ASP.NET klasik. Scrum terdiri dari kita menambal kekacauan besar atau membuat tambahan untuk itu. Kita semua terlalu sibuk melakukan itu untuk memulai penulisan ulang jadi saya bertanya-tanya ..

Di mana bagian dalam Scrum di mana para pengembang dapat memiliki kekuatan untuk mengatakan bahwa cukup sudah cukup dan menuntut agar mereka diberi waktu untuk memulai penulisan ulang besar? Kami tampaknya dalam lingkaran tanpa akhir hanya menambal kode lama dengan 'Cerita'.

Jadi hal-hal dijalankan oleh orang-orang non-teknis yang tampaknya tidak memiliki keinginan untuk mendorong penulisan ulang karena mereka tidak mengerti betapa buruknya basis kode yang telah terjadi.

Jadi siapa yang bertanggung jawab untuk membuat perubahan penulisan ulang yang besar ini terjadi? Pengembang? Master Scrum?

Strategi saat ini hanya untuk menemukan waktu dan melakukannya sendiri tanpa melibatkan atasan karena mereka sebagian besar disalahkan untuk kekacauan saat ini kita berada di ... <-masukkan kata-kata kasar tentang orang-orang non-teknis memberitahu orang-orang teknis apa yang harus dilakukan di sini ->.

scrum maintenance

— punkouter
sumber

20

Sham lincah mengangkat kepalanya yang jelek lagi ... Banyak perusahaan mengatakan mereka "gesit" dan menggunakan "scrum", padahal sebenarnya mereka tidak melakukan keduanya.

— Oded

4

Anda tidak melakukan Scrum

20

pertimbangkan untuk mencetak poster besar ini dan letakkan di dinding tepat di mana orang non-teknis Anda dapat melihatnya dengan jelas: Manifesto untuk Pengembangan Perangkat Lunak Agile Setengah-Arsed ... sementara item di sebelah kiri terdengar bagus secara teori, kami sebuah perusahaan perusahaan, dan tidak mungkin kita melepaskan barang-barang di sebelah kanan

— nyamuk

12

tautan wajib ke blog Joel: joelonsoftware.com/articles/fog0000000069.html

— marco-fiset

8

"<-Masukkan kata-kata kasar kepada orang-orang non-teknologi yang memberitahu orang-orang teknologi tentang apa yang harus dilakukan di sini->" , manajemen harus 100% memberi tahu orang-orang teknologi apa yang harus dilakukan, itu sebabnya mereka adalah manajemen dan bertanggung jawab untuk bisnis , itulah yang mereka lakukan yang terbaik. Apa yang mereka 100% harus tidak lakukan adalah memberitahu mereka bagaimana melakukannya, orang tech harus memutuskan bagaimana untuk teknis mencapai apa yang mereka telah diminta untuk melakukan. Yang lainnya adalah naif lengkap !

7

Saya tidak yakin mengapa ini sangat sulit bagi orang-orang. Kasus bisnisnya ada di sini:

We seem in an endless loop of just patching old code with 'Stories'.

Waktu pengembang adalah uang. Banyak uang. Saya meninggalkan perusahaan yang berencana memperbaiki UI mereka lebih dari setahun yang lalu dan berharap bahwa mengadopsi scrum akan membantu mereka berhenti memutar roda mereka. Apa yang terjadi? Sama ol 'sama ol'. Mereka terus mengunci fitur baru dan "utang teknis" tidak memiliki kasus bisnis meskipun setengah dari kode yang kami tulis menjadi tidak berarti dengan setiap iterasi karena basis kode yang mendasari menjadi berantakan usang sepenuhnya. Tidak ada satu pun yang berubah di ujung depan mereka sejak saya pergi, dan saya dibawa untuk tujuan pembenahan sepenuhnya. Dalam dua bulan saya di sana saya tidak benar-benar menyentuh sedikit pun CSS atau JavaScript. Saya hanya bermain-main dengan HTML dan beberapa sistem templating Jawa kuno dari akhir 1990-an.

Jawabanku? Lakukan apa yang Anda bisa, tetapi jika pengembang lain sudah menyerah dan bekerja lembur untuk memenuhi tujuan sprint daripada menegaskan tenggat waktu yang lebih praktis dan bersikeras bahwa utang teknologi sebenarnya merupakan masalah pemblokiran, anggaplah yang terburuk dan mulailah mencari pekerjaan baru sekarang. Pengembang Anda tidak dapat atau tidak diizinkan untuk mengomunikasikan keprihatinan mereka atau bisnis juga! @ # $ Ing picik untuk memahami berapa banyak uang yang mereka buang.

Mengabaikan masalah-masalah ini SELALU lebih mahal dalam jangka panjang. Dan tidak sedikit lagi, tetapi BANYAK lebih. Tidak hanya itu luka dada yang menghisap di mana waktu pengembangan yang bersangkutan, tetapi juga pasti akan mengurangi tingkat bakat Anda sebagai pengembang yang lebih tahu dan memiliki pilihan lain akan menghindari perusahaan Anda seperti wabah. Bos saya saat ini adalah pengembang DAN pemilik perusahaan. Ada hal-hal yang kita tidak akan menulis ulang untuk fokus pada prioritas lain, tetapi ketika sesuatu benar-benar membutuhkan refactor karena menjadi timesink yang konsisten, itu mendapat refactor yang tepat. Dan hasilnya jelas. Memodifikasi dan menambahkan hal-hal baru menjadi lebih mudah dan lebih cepat dengan berbagai faktor. Apa yang pernah memakan waktu berjam-jam dapat mengambil menit dengan arsitektur yang tepat. Bisnis tidak suka mendengarnya, tetapi ada baiknya menunda hal itu untuk itu.

Scrum adalah kegagalan di lingkungan di mana pengembang tidak memegang kendali, IMO, karena terlalu mudah bagi jenis bisnis untuk mengabaikan pemeliharaan dan pembaruan yang mendukung poin-poin penting yang dapat mereka masukkan ke dalam daftar "inisiatif yang berhasil" ketika waktu evaluasi datang. Mereka akan selalu mendukung jangat dan potensi mereka untuk promosi demi jangka panjang, bahkan ketika itu secara konsisten menggigit mereka di pantat untuk mengabaikan masalah ini juga.

Scrum juga merupakan industri yang memotivasi keuntungan dan kemudian beberapa. Perusahaan membayar banyak uang untuk pelatihan scrum. Orang yang ingin mengadopsi harus waspada terhadap siapa yang sedang dipasarkan dan seberapa realistis itu akan benar-benar berada dalam budaya mereka.

Apapun, jika Anda benar-benar peduli tentang pengembangan, basis kode jelek, manajemen dengan lilin di telinga dan pengembang tanpa duri adalah resep untuk kesengsaraan dan lingkungan yang akan melakukan sangat sedikit untuk meningkatkan keahlian Anda dalam hal apapun yang bermanfaat. Jangan ragu untuk mulai menerapkan langkah-langkah ke GTFO sebelum Anda benar-benar mengetahui apakah upaya Anda untuk memperbaiki masalah benar-benar membuahkan hasil.

— Erik Reppen
sumber

Mengenai refactoring, saya merasa aneh bahwa orang-orang tidak dapat 'menginternalisasi' bahwa refactoring adalah bagian konstan dari semua pengembangan, bukan sesuatu yang membuat Anda bingung ketika masalahnya begitu buruk sehingga tidak banyak yang dapat Anda lakukan.

— nicodemus13

1

Atau Anda tidak memiliki tes unit. :) Salah satu manfaat utama pengujian unit adalah memungkinkan Anda melakukan refactor dengan percaya diri. Masalah terbesar dengan praktik yang baik adalah sama dengan semuanya - itu membutuhkan disiplin dan umumnya orang lebih suka malas.

— nicodemus13

2

Itu atau mereka lagi hadiah dari kerumunan pengkodean ekstrim yang dapat dengan mudah diubah menjadi alat yang memungkinkan perilaku buruk di tangan yang salah. Tes otomatis berguna pada poin-poin penting, tetapi saya lebih suka arsitektur suara dan penulisan ke antarmuka daripada tes.

— Erik Reppen

1

Saya akan mengatakan itu sama untuk apa saja, secara pribadi saya menulis tes untuk membantu mendefinisikan antarmuka.

— nicodemus13

1

Kemudian datang rasa sakit dari semua lumpur untuk dimasukkan kembali karena ada beberapa pengecualian kecil yang mungkin tidak mudah ditangkap oleh analisis awal.

— JB King

33

Jika Anda benar-benar akan melakukan Scrum, yang saya ragu, Pemilik Produk akan bertanggung jawab untuk memutuskan tentang penulisan ulang. Sebagian besar kali menulis ulang bukanlah ide yang baik, karena, tidak menghasilkan fungsi baru, hanya memperkenalkan bug baru.

http://blog.objectmentor.com/articles/2009/01/09/the-big-redesign-in-the-sky
http://www.joelonsoftware.com/articles/fog0000000069.html

Mengembangkan "menulis ulang bukanlah ide yang bagus":

Hampir selalu lebih baik untuk mencoba peningkatan bertahap. Seperti yang ditulis Jarrod Robertson dalam komentar, temukan modul yang perlu diperbaiki menjadi ahli untuk modul itu dan tulis cerita untuk sprint berikutnya untuk meningkatkan modul itu. Jelaskan kepada pemilik produk mengapa modul itu perlu bekerja.

— EricSchaefer
sumber

8

Jika Anda memiliki pengalaman dan kebijaksanaan sebanyak yang Anda klaim, maju dan jadilah orang yang menemukan modul yang gagal itu, jadilah ahli dalam hal itu dan perbaiki, dan kemudian kumpulkan sebuah kasus bisnis untuk menulis ulang, karena dengan demikian Anda akan menjadi ahli dalam modul itu.

3

Beberapa kekacauan perlu dibersihkan. Mengutip artikel Joel dan menyatakan bahwa penulisan ulang jarang berhasil tanpa statistik yang meragukan (karena siapa yang membual tentang penulisan ulang yang berhasil?) Tidak mengubah itu.

— Erik Reppen

3

@ErikReppen Jadi ketika ruang tamu Anda berantakan, Anda merobohkan rumah dan membangun yang baru?

— EricSchaefer

4

Jika Anda membaca komentarnya, dia tidak berbicara tentang ruang tamu. Mungkin sulit untuk mengatakan di mana satu ruangan dimulai dan yang lainnya berakhir. Dan seluruh rumah terbakar.

— Erik Reppen

5

Whoa di sana, koboi. Sebelum kita hanya membuat pernyataan menyeluruh tentang "menulis ulang bukanlah ide yang baik", saya pikir kita perlu memenuhi syarat bahwa dengan kebenaran bahwa pindah ke teknologi baru dan beradaptasi dengan zaman sangat penting untuk kelangsungan hidup TI bisnis Anda. Jika Anda tidak mengadopsi teknologi yang lebih baru (semoga lebih baik) dan keuntungan yang diberikannya, pesaing Anda akan melakukannya. Ini berlaku untuk teknologi secara umum. Model-T adalah kendaraan yang sangat baik, tetapi berkat kompetisi dan adopsi teknologi baru, mobil telah "ditulis ulang" berkali-kali menjadi kendaraan yang jauh lebih baik yang kita kendarai saat ini.

— blesh

18

Aku akan benar-benar tumpul ...

Apakah Anda bertanggung jawab atas pengembang dalam pekerjaan ini?
Apakah Anda pemimpin proyek?
Berapa "taruhan" yang dimiliki pengembang dalam proyek?
Apa justifikasi bisnis Anda untuk menulis ulang?
Ada apa dengan basis kode yang membuatnya sama sekali tidak berguna dan tidak dapat dipulihkan?

Anda telah menyatakan bahwa Anda baru saja memulai pekerjaan, namun Anda tampaknya sudah menguasai situasi di sana. Mungkin saya telah salah mengerti maksud pertanyaan Anda, tetapi saya mendapat kesan bahwa Anda telah memasuki pekerjaan di mana Anda melihat sejumlah masalah, dan Anda telah melompat ke kesimpulan termudah di mana kode rusak dan satu-satunya jalan ke depan adalah menulis ulang, tetapi apakah Anda benar-benar mempertimbangkan biaya untuk majikan Anda untuk melakukannya?

Dengan basis kode yang ada - tidak peduli seberapa buruk keadaannya - pemilik biasanya akan memiliki investasi yang cukup besar dalam produk yang diwakili oleh kode tersebut. Ada biaya langsung dan tidak langsung yang terkait dengan basis kode, dan penulisan ulang sering kali merupakan hal terakhir yang ingin Anda lakukan sebagai pengembang perangkat lunak, karena Anda berisiko mendevaluasi aset kode Anda, dan karenanya mendapatkan pengembalian yang lebih rendah pada semua yang sebelumnya upaya.

Ambil sistem operasi Window sebagai contoh. Dengan setiap versi baru dibuat, ada sejumlah besar kode yang dibawa maju dari versi sebelumnya. Terkadang, seluruh pustaka dan API diseret ke depan melintasi beberapa generasi OS. Mengapa? Karena pengembang tahu bahwa elemen-elemen ini berfungsi, telah diuji, telah ditambal dan diperbaiki untuk mencegah masalah keamanan dan memori, dan karena mereka menghabiskan banyak uang untuk masuk ke keadaan itu. Tidak ada yang mau membuang kode kerja ketika menghasilkan uang, bahkan jika biaya perawatannya relatif tinggi, biaya untuk memulai dari awal akan selalu lebih tinggi lagi, dan di perusahaan seperti kasing Microsoft, mereka memiliki miliaran di bank yang memungkinkan mereka untuk memulai dari awal jika mereka mau, tetapi mereka tidak t karena mereka ingin memaksimalkan laba dari investasi mereka. Majikan Anda tidak berbeda dengan Microsoft, kecuali sedikit tentang memiliki miliaran uang tunai untuk dilemparkan pada suatu proyek.

Jadi kodenya berantakan, dan sepertinya ada masalah komunikasi dan batas antara berbagai bidang perusahaan. Apa yang dapat Anda atau kolega Anda lakukan tentang ini?

Salah satu pilihan adalah terus melanjutkan apa yang telah dilakukan tim, dan berharap akan keajaiban di masa depan. Mungkin bukan ide yang bagus, dan kemungkinan hanya akan menambah frustrasi dan stres Anda.

Pilihan yang lebih baik adalah dengan hanya menyerah dan melakukan pekerjaan Anda, tetapi sebagai bagian dari ini mencari peluang untuk menambahkan tes untuk mendukung area kode yang tampaknya paling rapuh, kemudian refactor mereka sampai mereka menjadi lebih stabil. Anda akan memiliki waktu yang lebih mudah untuk membuat argumen yang meyakinkan untuk meningkatkan investasi perusahaan alih-alih berdebat untuk membuangnya begitu saja.

Opsi yang lebih baik lagi adalah diorganisir sebagai sebuah tim, dan untuk memastikan Anda mendapatkan seseorang yang cukup senior sehingga mereka dapat membuat kasus yang baik untuk memungkinkan tim lebih fleksibel untuk menjadwalkan waktu untuk meningkatkan basis kode. Saya tidak peduli seberapa sibuk sebuah perusahaan, atau seberapa kaku jadwalnya, selalu ada "jeda" dalam aktivitas yang dapat digunakan untuk melakukan peningkatan atau dua peningkatan. Akan lebih baik jika perbaikan dapat dilakukan sambil menyelesaikan tugas lain. Jika itu saya, saya akan menyesuaikan diri dengan seorang manajer dan memperkenalkan mereka pada konsep-konsep dalam beberapa buku kanonik yang dibaca pengembang perangkat lunak. Kode Bersihmungkin yang paling dibutuhkan tim Anda. Tanam beberapa benih tentang cara meningkatkan kode, dan berikan beberapa contoh tentang maksud Anda. Seorang manajer yang baik akan melihat nilai penambahan peningkatan kode, terutama jika Anda dapat menggambarkan konsep Hutang Teknis . Bantu pemimpin tim atau manajer Anda untuk membuat kasus bisnis yang baik untuk meningkatkan kode, dan mereka akan memiliki motivasi yang lebih baik untuk menindaklanjutinya.

Itu juga tidak cukup untuk mengatakan "kode itu tidak rapi". Anda perlu mendorong kolega Anda untuk mempraktikkan pengkodean bersih sepanjang waktu, dan menggunakan teknik pengkodean bersih untuk mendorong sedikit merapikan saat Anda mulai. Saya memiliki poster kecil yang saya cetak dan gantung di dinding kantor setiap kali saya menerima pekerjaan baru. Itu mengatakan "Selalu berusaha untuk meninggalkan kode sedikit lebih indah daripada yang Anda temukan". Tepat di sebelahnya saya menambahkan yang lain yang mengatakan "Lili tidak perlu disepuh". Keduanya berfungsi untuk mengingatkan saya bahwa saya harus selalu berusaha meningkatkan apa yang saya temukan, tetapi menghindari hanya menyepuh emas satu masalah dengan yang lain. Penulisan ulang besar-besaran sering kali merupakan jenis "pelapisan emas" terburuk, karena sering dilakukan karena alasan yang salah. Tentu versi produk yang sama sekali baru mungkin dapat dibenarkan pada beberapa titik,

— S.Robins
sumber

Tidak, saya tidak bertanggung jawab. Saya seorang dev yang memiliki kode 12 tahun secara profesional dan 7 tahun. Saya telah menemukan banyak kontrak dan setelah beberapa saat Anda dengan cepat dapat merasakan kualitas kode. Berapa banyak 'Taruhan'? Saya tidak yakin apa yang Anda maksud dengan itu. Kita dapat terus memasang memperbaiki ASP CLASSIC lama yang sekarang sangat rapuh dan membutuhkan waktu 10x lebih lama untuk dilakukan daripada jika perubahan ini adalah bagian dari arsitektur modern yang bagus. Pembenaran bisnisnya adalah bahwa situs tersebut sekarang mengalami crash dalam produksi karena modul yang tampaknya tidak ada yang mengerti karena pergantian yang tinggi

— punkouter

Saya tidak berpikir Anda mengerti betapa buruknya basis kode ini. Selain itu, ini bukan adegan roket. Ini adalah CRUD 101. Ini menampilkan formulir, membiarkan pengguna mengisinya, memvalidasi dan kemudian membuat beberapa laporan dan PDF dari data. Itu pada dasarnya itu .. Tapi lebih dari 10 tahun kode telah terfragmentasi menjadi begitu banyak peices yang mengerikan. Saya telah menjadi bagian dari sekitar 20 proyek selama 12 tahun terakhir dan ini harus menjadi kumpulan kode terburuk yang pernah saya lihat yang sebenarnya digunakan dalam produksi ... Saya berharap saya dapat menunjukkan semuanya

— punkouter

Apa yang saya lakukan sebagai permulaan adalah menemukan orang-orang yang ada di tim yang memiliki minat dalam pengkodean dan tertarik menjadi bagian dari akhirnya mendapatkan hak ini. Tidak mudah menemukan orang-orang itu karena ... brucefwebster.com/2008/04/11/…

— punkouter

16

@punkouter: Saya tidak berpikir Anda mengerti maksud yang dibuat di sini; Basis kode menjadi "buruk" bukan kasus bisnis untuk penulisan ulang. Memiliki hasrat untuk coding dan ingin melakukan sesuatu dengan benar bukanlah kasus bisnis untuk menulis ulang. Bug dan pemadaman produksi yang mahal, dan membutuhkan waktu berbulan-bulan untuk mengimplementasikan fitur baru yang sepele tetapi penting - MEREKA menyediakan kasus bisnis untuk penulisan ulang.

— Michael Borgwardt

1

@punkouter Tautan Anda ke deskripsi fenomena "Laut Mati" juga sangat tepat. Tidak ada gunanya bagi bisnis untuk kehilangan pengetahuan melalui gesekan, dan sangat berharga untuk mengklaim kembali apa yang dapat dilakukannya. Investasi waktu Anda untuk menghindari penulisan ulang yang berpotensi mahal dan tidak perlu memiliki nilai bisnis yang lebih besar daripada kehilangan pengetahuan dan keahlian. Mendorong praktik perekrutan yang lebih baik, dan naik ke tantangan memotong masalah dan meningkatkan sistem adalah kesempatan bagi Anda untuk mendapatkan sedikit pujian dan menjadi aset berharga bagi majikan Anda.

— S.Robins

13

Berikut adalah definisi resmi Tim Pengembangan Scrum dari Panduan Scrum resmi . Saya menekankan bagian-bagian yang menarik perhatian Anda secara langsung:

Tim Pengembangan terdiri dari para profesional yang melakukan pekerjaan menghasilkan Produk “Selesai” yang berpotensi dirilis yang dapat dirilis pada akhir setiap Sprint. Hanya anggota Tim Pengembang yang membuat Peningkatan. Tim Pengembangan disusun dan diberdayakan oleh organisasi untuk mengatur dan mengelola pekerjaan mereka sendiri . Sinergi yang dihasilkan mengoptimalkan efisiensi dan efektivitas Tim Pengembangan secara keseluruhan. Tim Pengembangan memiliki karakteristik sebagai berikut:

Mereka mengatur diri sendiri. Tidak seorang pun (bahkan Master Scrum) memberi tahu Tim Pengembangan cara mengubah Product Backlog menjadi Peningkatan fungsi yang berpotensi untuk dirilis;

Tim Pengembangan bersifat lintas fungsional, dengan semua keterampilan sebagai tim yang diperlukan untuk membuat Peningkatan produk;

Scrum tidak mengenali judul untuk anggota Tim Pengembangan selain Pengembang, terlepas dari pekerjaan yang dilakukan oleh orang tersebut; tidak ada pengecualian untuk aturan ini;

Anggota Tim Pengembangan Individu mungkin memiliki keterampilan khusus dan bidang fokus, tetapi akuntabilitas menjadi milik Tim Pengembangan secara keseluruhan; dan,

Tim Pengembangan tidak mengandung sub-tim yang didedikasikan untuk domain tertentu seperti pengujian atau analisis bisnis.

Tim Pengembangan karena itu bertanggung jawab atas kekacauannya sendiri dan harus mengatasinya sendiri, tanpa harus meminta siapa pun di luar tim.

Sertakan waktu penyelesaian utang teknis di setiap estimasi masa depan Anda, dan pastikan bahwa kualitas perangkat lunak yang Anda kirimkan adalah yang terbaik.

Jika Anda benar-benar harus menulis ulang sepenuhnya, Anda harus mengatasi masalah di Scrum Restrospective. Pemilik Produk pada akhirnya dapat membatalkan proyek dan memulai yang baru. Pemilik Produk juga satu-satunya yang dapat membatalkan sprint.

8

Tim bertanggung jawab atas kekacauan mereka sendiri, tetapi mereka tidak bisa memilih prioritas utang teknis versus fitur baru. Pemilik produklah yang memutuskan itu. Hanya saja, setelah PO memutuskan prioritas backlog, tim dapat memutuskan bagaimana mengirimkannya. Mereka dapat mengatakan "kami tidak dapat mengirimkan fitur X tanpa refactoring Y pertama" tetapi mereka tidak dapat mengatakan "tidak, maaf, kami tidak akan menambahkan fitur baru sampai kami menulis ulang dari awal".

— Bryan Oakley

6

@BryanOakley: Menulis ulang dari awal bukan yang saya sarankan. Saya menyarankan untuk mengurangi utang teknis secara progresif saat tim pengembangan bekerja pada bidang-bidang terkait. Dan saya juga menyarankan agar mereka memperkirakannya.

1

Itu bagus tetapi bagaimana jika kita membutuhkan server baru, database baru, perangkat lunak baru agar kita dapat memiliki semua alat yang kita butuhkan untuk menulis ulang? Dan bagaimana penulisan ulang dimulai ketika satu-satunya 'Cerita' adalah tentang memperbaiki masalah saat ini dan tidak pernah tentang konsep mengizinkan penulisan ulang?

— punkouter

1

@punkouter: jika Anda harus menulis ulang, atasi masalah di scrum retrospective. Kemudian Pemilik Produk akan mengambil tanggung jawab untuk membatalkan proyek saat ini dan memulai yang baru.

5

Jangan berasumsi bahwa keputusan untuk menulis ulang adalah yang 'benar' hanya karena itu yang paling menarik bagi para devs. Terkadang ada alasan bisnis yang bagus untuk menghadirkan fitur sekarang, meskipun itu akan meningkatkan utang teknis.

— DJClayworth

8

Saat Anda menggambarkan ini, saya harus mengatakan saya tidak melihat apa pun yang ada hubungannya dengan SCRUM, atau tim pengembangan produk Anda menjadi masalah saat ini .

Ini normal

Apa yang Anda gambarkan adalah entropi normal dari basis kode. Dalam kasus Anda, tim mungkin memulai lebih jauh dari ideal, tetapi masih setiap basis kode akhirnya menjadi Bola Besar Lumpur .

Dalam skenario greenfield yang benar-benar sempurna , yang dapat Anda lakukan adalah mulai lebih jauh dari entropi absolut dan bergerak lebih lambat.

Saya setuju dengan yang lain, kekacauan basis kode adalah karena pengembang. Saya yakin itu sebelum adopsi SCRUM selama bertahun-tahun.

Ini bukan keputusan teknis atau pengembang untuk menulis ulang, ini adalah keputusan bisnis.

Anda tidak tahu mengapa pemilik produk tidak ingin menulis ulang. Anda sebagai pengembang berpikir itu diperlukan, tetapi apakah benar-benar ada kasus bisnis untuk itu?

Jika ada kasus bisnis yang sebenarnya , bukan hanya melambaikan tangan; "kode ini adalah kekacauan lama yang ingin saya mulaii greenfield karena itulah yang saya inginkan" , maka manajemen akan menanggung biaya penulisan ulang, dengan pertimbangan pengembalian investasi itu.

Anda belum memberikan satu kasus bisnis yang kuat untuk ditulis ulang, hanya kata - kata kasar tentang pendapat Anda tentang bagaimana orang lain menyebabkan kekacauan ini dan Anda tidak ingin menghadapinya.

Bukti - Keuntungan mendorong keputusan bisnis untuk membuang perangkat lunak yang berfungsi, bukan OCD kebutuhan untuk basis kode yang bersih

Jika Anda benar-benar dapat menunjukkan bukti , bukan hanya teori tetapi bukti kuat bahwa pengeluaran Xdolar untuk penulisan ulang greenfield akan dijamin menghasilkan X * Ndolar untuk bisnis dalam Ykerangka waktu (di mana Ntinggi dan Ypendek), Anda mungkin mendapatkan daya tarik dari manajemen . Ini adalah kasus yang sangat tidak mungkin Anda sajikan dan buktikan.

Kalau tidak, Anda hanya perlu menghadapinya, ini adalah kenyataan. Bertentangan dengan pernyataan Anda yang bersikeras bahwa sama sekali tidak ada jalan ke depan tanpa penulisan ulang yang hebat ini, saya berani bertaruh uang bahwa 5+ tahun dari sekarang basis kode yang Anda keluhkan masih akan bekerja dan berjalan di suatu tempat menyediakan fungsionalitas dan nilai seseorang lama setelah Anda telah meninggalkan perusahaan.

— Peter Mortensen
sumber

1

itu tidak berarti itu bukan tanggung jawab bagi pengembang untuk menggunakan beberapa sistem kontrol versi secara internal , saya akan mengatakan itu masih tanggung jawab pengembang untuk menjaga diri mereka sendiri dan kepentingan terbaik mereka terlepas. Pada pria Anda, 200 devs itu tidak melakukan apa yang perlu mereka lakukan, manajemen tidak menodongkan pistol ke kepala mereka dan melarang mereka untuk membuat sistem kontrol versi sendiri.

3

Basis kode yang berantakan tidak pernah merupakan hasil langsung dari manajemen karena manajemen tidak pernah secara langsung bertanggung jawab untuk menulis kode. Sesederhana itu. Manangement bertanggung jawab untuk memiliki dan membina lingkungan kerja yang kurang ideal bagi pengembang, tetapi tanggung jawab untuk mengatasi masalah seperti kurangnya kontrol versi selalu jatuh pada mereka yang melakukan pekerjaan yang sebenarnya.

— Peter Lange

1

Pengembang outsourcing merupakan masalah manajemen. Orang-orang di dalam lebih tahu. Manajemen suka berpura-pura menghemat uang dengan mempekerjakan 200 dev ketika mereka sebenarnya mungkin bisa melakukan yang terbaik dengan 20 yang kompeten. Sama seperti banyak implementasi Scrum yang pernah saya lihat, strategi yang diadopsi adalah produk dari ketidakmampuan dan tidak ada pengembang yang sebenarnya memiliki kendali atas karyawan perusahaan.

— Erik Reppen

2

@ Erik, tidak mengatakan manajer tidak harus bertanggung jawab atas basis kode yang buruk (atau keputusan buruk lainnya yang dibuat di departemen mereka) dan bahwa manajer tidak bertanggung jawab langsung untuk menyediakan lingkungan tempat pengembang bekerja, seperti skenario yang Anda gambarkan. Tetapi satu-satunya orang yang dapat secara langsung bertanggung jawab atas basis kode adalah orang yang menulis kode itu sendiri.

— Peter Lange

3

Saya juga ingin menambahkan bahwa itu bodoh untuk tidak membuat devs Anda mengetahui rahasia tujuan bisnis. Saya tidak pernah mengerti mengapa orang begitu ingin menyembunyikan barang-barang ini dari orang-orang yang benar-benar menentukan perilaku produk mereka. Mengetahui tujuan jangka panjang perusahaan sebenarnya bisa menginformasikan bagaimana Anda merancang aplikasi. Juga, devs, yang baik setidaknya, memecahkan masalah. Secara konstan, mereka memecahkan masalah. Beberapa dari kita mengantisipasi dan menyelesaikannya lebih dulu di kepala kita atau setidaknya membiarkan pintu kanan terbuka di kode kita.

— Erik Reppen

7

Saya biasanya skeptis ketika orang mendorong untuk "penulisan ulang besar". Ada beberapa kasus di mana itu pasti masuk akal tetapi sebagian besar waktu, bahwa kode warisan memiliki nilai (dalam hal ini sudah dalam produksi dan digunakan untuk tujuan yang menginspirasi pembuatannya). Melakukan penulisan ulang besar dalam banyak kasus adalah kebalikan dari gesit. Berapa lama waktu yang dibutuhkan untuk membawa versi baru aplikasi ke titik di mana ia dapat menggantikan aplikasi yang sudah ada.

Pendekatan yang saya inginkan adalah apa yang disebut Martin Fowler sebagai anggur mencekik . Menerapkan fungsionalitas baru (termasuk perubahan pada fungsionalitas yang ada) menggunakan pendekatan baru tetapi menggunakan aplikasi yang ada sebagai terali yang dapat ditumbuhkan oleh fungsionalitas baru. Ini memberi Anda yang terbaik dari kedua dunia, Anda tidak harus menghentikan semuanya saat penulisan ulang besar dilakukan untuk menghabisi, tetapi Anda mendapatkan manfaat dari penulisan kode baru yang memanfaatkan kerangka kerja yang diperbarui. Ini jelas merupakan pendekatan yang lebih sulit daripada mulai bersih dan mungkin tidak se-seksi, tetapi memberikan nilai lebih untuk bisnis daripada membuang semua yang ada di sana karena sudah ketinggalan zaman.

— Michael Brown
sumber

Itu bisa sulit jika basis yang ada cukup berantakan. Dia berbicara tentang beberapa sistem asp.net warisan oleh penulis yang sangat berbeda digabungkan bersama untuk situs sialan yang sama. Bentuk web sendiri adalah monster dan saya yakin itu ada dalam campuran.

— Erik Reppen

Oh saya tidak pernah mengatakan itu akan menjadi rute termudah ... tapi itu lebih cocok untuk para pemangku kepentingan. Juga, sekali saja mengalaminya, mudah-mudahan Anda akan memastikan bahwa ketika hari ini terbaru dan terhebat menjadi usang besok, lebih mudah untuk menghapusnya secara bertahap.

— Michael Brown

Saya setuju. Tapi seperti yang saya katakan (dan tidak yakin semua orang di sini). Apa yang ada sekarang adalah kumpulan sekitar 9 aplikasi web yang terpisah, setengahnya adalah ASP Klasik dan separuhnya lagi adalah bentuk yang berbeda dari ASP.NEt. Semua menggunakan cara yang sangat berbeda untuk menangani akses data dll. Jadi satu-satunya cara untuk melakukan apa yang dibicarakan adalah dengan memalsukan UI agar terlihat seperti kode baru adalah bagian dari kode lama .. jadi ya mungkin .. tapi kemudian ada database .. Satu tabel memiliki 400 bidang!

— punkouter

Saya penasaran. Apa yang diwakili tabel itu? Itu hal terburuk yang pernah saya dengar sejak saya melihat i ++; doSomething (i); diulang lebih dari selusin kali dalam beberapa kode yang keluar dari tag JSP yang rusak.

— Erik Reppen

5

Di mana saya berada dan bagaimana kami bekerja, inilah yang akan kami lakukan: Menulis cerita baru dan menyerahkannya kepada pemilik produk, yang kemudian akan memutuskan bagaimana memprioritaskannya. Contohnya adalah: "Sebagai Pengembang Produk X, saya ingin menulis ulang kode di area ini sehingga pengembangan di masa depan lebih efisien" Kriteria penerimaan kemudian harus sesuai: "Penulisan ulang / refactoring x sehingga lebih baik dengan cara ini.

Saya tidak tahu tentang situasi di mana Anda berada tetapi di sini jika kami ingin memulai kembali dari awal, itu akan menjadi masalah dengan pemilik produk dan membujuk mereka mengapa dan kemudian menulis tumpukan cerita untuk menciptakan kembali yang sudah ada fungsionalitas.

Hal-hal lain yang telah kami lakukan untuk mencoba dan menangani kode buruk dan / atau lawas adalah memasukkan tugas untuk mengerjakan ulang saat menugasi cerita pengguna.

— BennyB
sumber

Jadi para devs dapat menulis 'cerita' dan mengirimkannya? Masalahnya adalah menjelaskan alasan untuk menulis ulang terlalu teknis bagi mereka untuk menangani ... Yang bisa saya katakan adalah .. 'Kode saat ini sulit untuk dikelola dan rusak' ..

— punkouter

6

@punkouter: jika alasan ingin menulis ulang adalah murni teknis (yaitu tidak memerlukan biaya uang bisnis) maka Anda TIDAK PUNYA alasan yang cukup untuk menulis ulang.

— Michael Borgwardt

@MichaelBorgwardt: Apakah Anda mengatakan bahwa alasan teknis tidak pernah cukup untuk menulis ulang sesuatu? Itu pendekatan yang secara fundamental rusak, jika saya mengerti Anda dengan benar. Satu hal yang terus membuat saya jengkel adalah pendekatan master / slave normal yang mana 'bisnis' menentukan segala sesuatu yang 'IT', atau departemen apa pun lakukan. Itu hanya benar sampai batas tertentu. TI memiliki persyaratannya sendiri yang bersifat internal dan tidak diputuskan oleh bisnis - ini adalah satu hal yang biasanya hilang dan mengarah pada perangkat lunak yang tidak direkayasa, tidak cocok untuk tujuan.

— nicodemus13

1

@ user12355 Seperti yang saya lihat, poin Michaels adalah bahwa jika itu tidak kehilangan uang mereka, itu tidak akan menghasilkan uang, maka tidak pernah ada kasus. Jika mereka tidak kehilangan uang, penulisan ulang akan memakan biaya. Uang yang tidak dapat dipulihkan. Pengembang dapat membuat kasus "kode ini menyebalkan" tetapi kecuali jika mereka dapat membuktikan manfaat finansial bagi majikan mereka, mereka tidak akan pernah mendapatkan lampu hijau untuk menulis ulang kecuali mereka melakukannya sendiri.

— Rig

1

@ user12355: Alasan teknis pasti cukup untuk cerita pengguna. Itu tidak selalu cukup untuk membuat cerita itu dipromosikan ke puncak daftar dan ditempatkan dalam sprint.

— Adam V

4

Memutuskan penulisan ulang besar adalah keputusan bisnis. Anda dapat mencoba memengaruhi keputusan bisnis dengan menjual sudut pandang Anda kepada orang yang bertanggung jawab atas bagian bisnis.

Namun; perubahan kualitas kode dari satu iterasi ke iterasi berikutnya adalah keputusan pengembang. Jika Anda membiarkan kualitas kode menurun, Anda menambahkan utang teknis untuk memenuhi harapan pemilik produk sekarang. Yang dapat Anda lakukan adalah mulai mengambil tanggung jawab atas kode yang Anda tulis dan memastikannya meningkatkan basis kode, bukan sebaliknya. Sekarang ini berarti Anda akan kehilangan kecepatan, karena Anda terus mengurangi jumlah utang teknis, dan pemilik produk Anda pasti akan kecewa. Anda dapat mencoba menjelaskan bahwa dengan keinginan Anda, Anda membiarkan kualitas kode menurun dan Anda sekarang mengambil langkah-langkah untuk memperbaiki masalah ini.

Sekarang, saya menyadari bahwa ini adalah langkah yang menakutkan untuk diambil, dan mungkin terasa tergoda untuk menunda satu sprint lagi sehingga Anda dapat keluar fitur X sebelum tenggat waktu yang penting. Sayangnya, itu hanya akan semakin sulit semakin lama Anda menunggu.

Omong-omong, ini bukan semata-mata masalah Scrum, saya juga tidak menyarankan solusi yang khusus untuk Scrum. Ini tentang pengembang yang memiliki kode.

— Buhb
sumber

1

Benar dan ketika Anda memiliki sejarah 10 tahun turnover konstan dan satu kali oleh devs yang jelas tidak bisa kode dengan baik atau mengerti arsitektur modern maka .. Anda memiliki apa yang saya miliki sekarang ... Saya lebih khawatir daripada orang lain sejak saya Saya baru dalam pekerjaan itu dan tidak terbiasa melihat kode dengan tingkat kualitas rendah seperti itu .. Saya ingin menulis ulang bukan hanya untuk keinginan egois saya menikmati menulis kode baru yang baik .. tetapi demi orang lain juga .. bahkan jika mereka tidak mengerti situasinya seperti saya.

— punkouter

1

Saya hanya bisa mengulangi apa yang sudah dikatakan; Secara formal, Anda tidak dapat memutuskan bahwa sekarang adalah waktu untuk penulisan ulang besar. Saya kira Anda bisa mencoba menunjukkan kepada para pemangku kepentingan berapa banyak upaya yang diperlukan untuk mengubah basis kode Anda menjadi sedikit lebih menyakitkan, dan membandingkannya dengan upaya yang diperlukan untuk melakukan penulisan ulang yang lengkap.

— Buhb

3

Pengembang bertanggung jawab untuk memberi tahu dunia tentang kondisi basis kode saat ini. Ini dapat terjadi selama scrum harian, retrospektif atau hanya secara informal. Ini mungkin tampak jelas tetapi jika Anda tidak mengungkapkan dengan jelas betapa berantakannya dan berapa banyak waktu yang Anda buang karena itu, tidak ada yang akan memerhatikan. Scrum Master biasanya akan bertanggung jawab untuk meneruskan informasi ke PO dan orang-orang yang bertanggung jawab atas proyek dan membujuk mereka sesuatu yang perlu dilakukan, dan kemudian memfasilitasi implementasi solusi oleh tim.

Sebagai catatan, penulisan ulang big bang adalah IMO belum tentu jawaban yang tepat untuk masalah seperti ini. Namun para devs sudah bosan dengan basis kode saat ini, mengambil langkah-langkah kecil terukur menuju arsitektur yang lebih bersih seringkali merupakan ide yang lebih baik karena Anda dapat melihat kemajuannya, membenarkan pekerjaan Anda dengan secara teratur menunjukkan pada PO pencapaian dan melanjutkan alur penerapan pengguna baru cerita secara paralel sebagai lawan tersesat dalam makeover tanpa akhir yang memonopoli sumber daya.

— guillaume31
sumber

Seperti yang saya sebutkan .. Tidak ada jalan ke depan dengan koleksi 6 situs ASP Klasik + 4. Net 1.1 situs yang semuanya digabungkan menjadi satu situs. Semua diberi kode oleh orang yang berbeda dengan cara yang berbeda.

— punkouter

Saya cukup yakin bahwa basis kode akan bergerak maju, untuk tahun-tahun mendatang, untuk memparafrasekan Dr. Ian Malcom dari Jurrasic Park "Saya, saya hanya mengatakan bahwa manajemen, uh ... menemukan jalan" .

Mungkin akan ada di tahun-tahun mendatang, tetapi berbagai rasa warisan. Situs internet yang digabungkan secara erat tidak akan bergerak terlalu jauh di tahun-tahun itu.

— Erik Reppen

Tentu, tetapi jika semua situs .net itu terus berfungsi, dan fungsinya terus menghasilkan pendapatan baik secara langsung maupun tidak langsung bagi perusahaan, mengapa momentum ke depan begitu penting? Ketika pendapatan secara langsung dipengaruhi oleh kualitas basis kode, Anda dapat percaya bahwa manajer tidak akan membuang waktu dalam mendesain ulang karena mereka semua memiliki hipotek untuk membayar sama seperti yang dilakukan pengembang.

— Peter Lange

Momentum maju tanpa henti umumnya adalah akar masalah di tempat pertama dalam pengalaman saya. Rasa sakit dimulai ketika ekspektasi turnaround tidak berkurang sementara mereka masih menutup telinga terhadap masalah dalam arsitektur dan berpikir Scrum akan secara ajaib mengembangkan set fitur lengkap baru setiap dua minggu tanpa semakin memperburuk masalah. Saya tidak mengatakan kita tidak harus waspada dengan keinginan untuk merobek hal-hal jika kita tidak dapat menemukan alternatif yang memecahkan waktu yang kita hadapi, tetapi saya telah melihat setidaknya dua kasus yang sangat bagus untuk jurusan perbaikan dalam karir saya.

— Erik Reppen

2

Kamu bertanya:

Di mana bagian dalam Scrum di mana para pengembang dapat memiliki kekuatan untuk mengatakan bahwa cukup sudah cukup dan menuntut agar mereka diberi waktu untuk memulai penulisan ulang besar? Kami tampaknya dalam lingkaran tanpa akhir hanya menambal kode lama dengan 'Cerita'. Jadi hal-hal sedang dijalankan oleh orang-orang non-teknis yang tampaknya tidak memiliki keinginan untuk mendorong penulisan ulang karena mereka tidak mengerti betapa buruknya basis kode.

Sebagai seseorang yang merupakan manajer dan pengembang, jawaban paling sederhana untuk pertanyaan Anda adalah tidak ada bagian dalam Scrum, atau metodologi lain, atau dalam skenario bisnis apa pun, di mana pengembang memiliki kekuatan untuk mengatakan cukup sudah cukup dan menuntut menulis kembali. Banyak orang di sini telah membuat argumen yang baik, valid, untuk menjelaskan mengapa menulis ulang sering kali merupakan ide yang buruk, dan untuk menjelaskan bagaimana perubahan dapat dan harus dilakukan dengan cara yang bertahap dan gesit. Dan saya setuju dengan mereka semua.

Tetapi intinya bahkan lebih sederhana. Anda tidak bisa membuat keputusan itu, PERNAH. Anda adalah karyawannya, dan satu-satunya keputusan yang benar-benar Anda ambil adalah "akankah saya terus bekerja untuk para bajingan ini atau mencari pekerjaan baru yang takut akan keterampilan gila saya?" Pekerjaan baru Anda tidak akan memungkinkan Anda untuk membuat keputusan itu juga, tetapi setidaknya Anda akan merasa seperti Anda mengendalikan nasib Anda saat Anda melompat dari satu pekerjaan ke pekerjaan lain.

— Peter Lange
sumber

1

Jika saya membaca yang tersirat di sini dengan benar, sepertinya Anda agak pahit tentang ketidakmampuan Anda untuk mempertahankan karyawan baru. Jika saya tidak salah, pernahkah Anda menganggap bahwa karyawan baru yang keahliannya sebenarnya cukup banyak menuntut mereka untuk berjalan ketika mereka tidak suka bekerja di perusahaan Anda adalah satu-satunya yang tidak tetap dalam persamaan?

— Erik Reppen

1

Bahkan tidak dekat. Sebenarnya karyawan di departemen saya telah bersama saya selama beberapa tahun sekarang. Saya hampir tidak memiliki turn over. Yang ingin saya sampaikan adalah bahwa pada akhirnya, di perusahaan mana pun, di industri apa pun, pekerjaan yang dilakukan karyawan sepenuhnya tergantung pada orang yang menandatangani gaji dan bukan karyawan. Satu-satunya keputusan yang harus diambil karyawan, termasuk saya ketika bos saya mengajukan permintaan, adalah untuk bertahan atau tidak bertahan dengan hubungan karyawan. Poster asli bertanya kapan dia, sebagai karyawan, bisa mendikte pengembangan. Jawabannya tidak pernah.

— Peter Lange

Lalu ada apa dengan karakterisasi "takutkan skilku gila"? Orang ini adalah dev yang berpengalaman. Dan saya dapat memberi tahu Anda dari pengalaman saya dengan situasi yang serupa bahwa masalah yang ia bicarakan bukan hanya masalah menginginkan hal-hal seperti itu tetapi sebenarnya merupakan bencana yang sedang berlangsung yang membuat semua orang sengsara dan membuat majikannya menjadi lebih mahal dalam dev yang sia-sia. retensi waktu dan bakat daripada yang mungkin mereka sadari.

— Erik Reppen

1

Karena saya mengilustrasikan kekeliruan dari argumen dasar, yang berakar pada ego (dalam pengertian psikologis). Ini bukan pertanyaan tentang seberapa terampil dia. Ini bukan pertanyaan tentang seberapa kacau kode ini. Ini bukan pertanyaan tentang apa yang bisa dilakukan metodologi pengembangan untuknya. Ini adalah pertanyaan tentang kekuasaan. Kekuatan untuk mengambil keputusan dalam hubungan karyawan berada di tangan majikan. Satu-satunya kekuatan memutuskan yang dimiliki karyawan adalah untuk membatalkan hubungan ketika itu menjadi terlalu berat untuk ditanggung.

— Peter Lange

1

Saya setuju, scrum buruk untuk berurusan dengan utang teknologi. Tetapi saya tidak setuju tentang dasar dari pertanyaan awal. Dia sebenarnya menanyakan pertanyaan hubungan majikan / karyawan, tetapi hanya menyebutkan scrum dalam pertanyaan itu. Rasanya seperti saya bertanya, "Sebagai seorang Kristen, bagaimana cara terbaik untuk membuat Enchillada?". Ini sebenarnya bukan pertanyaan teologis; itu pertanyaan tentang memasak bahkan jika saya membuat kesalahan dengan berpikir preferensi agama saya relevan.

— Peter Lange

1

Saya merasakan sakit Anda, tetapi tidak yakin apa hubungannya dengan Scrum. Keputusan untuk menulis ulang kode tidak tergantung pada proses pengembangan.

— Nemanja Trifunovic
sumber

Sebuah proses pengembangan yang menjanjikan hal-hal akan diselesaikan setiap dua minggu dapat melakukan banyak hal untuk menghalangi refactoring skala besar yang diperlukan yang telah diabaikan selama bertahun-tahun. Hal pertama yang saya perhatikan dalam pelatihan scrum adalah cara mereka menyelimuti topik utang teknologi. Tidaklah menarik untuk menyatakan bahwa aplikasi Anda sekarang lebih ramping dan jahat dan Anda dapat melakukan banyak hal dengan lebih cepat. Jenis bisnis menginginkan nilai tambah yang dapat ditampilkan kepada teman dan investor.

— Erik Reppen

1

Tunggu apa?

Anda menambal ? Anda harus refactoring . Menempel nilai-nilai lincah. Gunakan TDD dan praktik yang sesuai dan situasinya pada akhirnya akan menjadi lebih baik.

— Elang
sumber