Bagaimana agile dapat diterapkan pada aplikasi yang melibatkan pemrosesan kompleks?

12

Sebagian besar literatur tentang gesit tampaknya bias terhadap aplikasi bisnis tipe CRUD di mana pengguna cukup sadar akan apa yang terjadi di balik layar. (Tidak apa-apa karena sebagian besar kode yang sedang ditulis mungkin milik kelas ini.)

Untuk jenis aplikasi ini, hubungan antara cerita pengguna (persyaratan) dan tugas pengembangan sebagian besar bersifat langsung: Cukup bagi cerita pengguna menjadi beberapa tugas.

Tetapi ada jenis aplikasi lain di mana sebagian besar kode harus berurusan dengan pemrosesan kompleks yang tidak langsung terlihat oleh pengguna. Contohnya adalah:

Kompiler
Sistem analisis gambar mobil yang bisa mengemudi sendiri
Sistem simulasi aliran fluida

Di sini sangat sulit untuk mengaitkan tugas dan cerita pengguna. Apakah ada teknik untuk mengatasi masalah ini atau itu hanya sesuatu yang harus kita terima dan lakukan yang terbaik?

— Frank Puffer
sumber

6

Bukan downvoter, tapi saya akan menganggap itu karena pertanyaannya didasarkan pada premis yang salah. IMO sistem yang kompleks bahkan lebih cocok untuk pengembangan gaya Agile berdasarkan fakta bahwa mereka yang lebih kompleks. Semakin kompleks sistem, semakin besar kemungkinan untuk memiliki persyaratan yang muncul. Agile SwDev diciptakan untuk menangani kebutuhan yang muncul dengan lebih baik.

— RubberDuck

4

@RubberDuck: "Saya akan menganggap itu karena pertanyaannya didasarkan pada premis yang salah.": IMO, ini akan memotivasi jawaban di mana premis yang salah dijelaskan, bukan downvote.

— Giorgio

Apakah penggunaan memahami logika atau tidak sama sekali tidak relevan dengan proses tangkas. Terserah tim untuk memetakan cerita pengguna ke implementasi DAN untuk memperkirakan berapa lama waktu yang dibutuhkan. Jika rumit dan / atau banyak pekerjaan, tim dapat membagi cerita menjadi yang lebih kecil. Jenis logika tidak masalah.

— Martin Maat

2

"Sebagian besar literatur tentang gesit tampaknya bias terhadap aplikasi bisnis tipe CRUD" - Dan sebagian besar literatur di Jawa tampaknya bias terhadap pencetakan string "Hello World" pada konsol (atau komputasi alternatif nomor Fibonacci n). Itu tidak berarti bahwa satu-satunya hal yang baik untuk Java. Alasannya sama dalam kedua kasus: sulit untuk menjelaskan contoh realistis dalam posting blog atau tutorial. [Catatan: ini adalah komentar hiperbolik yang mencoba mengilustrasikan dasar untuk premis yang salah.]

— Jörg W Mittag

1

Agile tidak membutuhkan tugas dan cerita pengguna. Anda dapat menggunakan segala bentuk spesifikasi yang Anda inginkan. Intinya adalah fleksibilitas.

— Frank Hileman

9

Ini ternyata lebih lama dari yang saya rencanakan (sudah dimulai sebagai komentar), tapi saya harap panjang / rincian tambahannya membantu dan Anda menemukan mereka dibenarkan.

Agile tidak spesifik untuk aplikasi CRUD

Sebagian besar literatur tentang gesit tampaknya bias terhadap aplikasi bisnis tipe CRUD di mana pengguna cukup sadar akan apa yang terjadi di balik layar. (Tidak apa-apa karena sebagian besar kode yang sedang ditulis mungkin milik kelas ini.)

Saya pikir ini karena lebih mudah untuk membuat contoh yang mudah diikuti dari jenis ini, bukan karena metodologi yang ditujukan pada sistem semacam itu. Jika Anda membuat contoh yang tidak terlalu mudah diikuti, Anda berisiko membuat pembaca terjebak mencoba memahami contoh ketika poin Anda seharusnya mengajarkan pembaca tentang konsep-konsep tangkas.

Cerita Pengguna! = Persyaratan

Untuk jenis aplikasi ini, hubungan antara cerita pengguna (persyaratan) dan tugas pengembangan sebagian besar bersifat langsung: Cukup bagi cerita pengguna menjadi beberapa tugas.

Kisah pengguna tidak sama dengan persyaratan. Benar, mungkin ada beberapa tumpang tindih tergantung pada seberapa 'tingkat tinggi' persyaratannya, tetapi umumnya tidak sama. Saya mendapat kesan bahwa Anda mengalami perangkap yang sama, banyak mantan manajer saya jatuh ke: berpikir tentang cerita pengguna hanya sebagai sinonim untuk "persyaratan", yang mirip dengan ketika pengguna SVN mencoba untuk beralih ke Git, tetapi tetap berpikir dalam hal SVN. (Mereka kemudian mengalami masalah karena asumsi awal yang buruk.)

IMHO, perbedaan utama antara persyaratan dan cerita pengguna adalah bahwa persyaratan menentukan, secara rinci, bagaimana komponen sistem tertentu harus berperilaku; mereka spesifikasi yang mencakup input, output, asumsi / pra-kondisi, pengecualian yang mungkin timbul, dll. Mereka fokus pada apa yang dilakukan sistem .

OTOH, cerita pengguna fokus pada hasil yang diharapkan untuk pengguna akhir tanpa mencoba untuk membuat spesifikasi perilaku rinci untuk komponen sistem. Mereka fokus pada pengalaman pengguna yang diharapkan .

Apa yang biasa saya lakukan, dan ini adalah praktik yang diadopsi tim saya, adalah memecah cerita pengguna menjadi tugas. Tugas Anda bisa sespesifik atau kabur seperti yang Anda inginkan / inginkan, tetapi tugas itu dimaksudkan sebagai indikator kemajuan Anda untuk pekerjaan aktual yang dilakukan untuk membawa cerita ke kondisi selesai.

Contoh

Saya kira-kira mengingat suatu AS yang saya kerjakan bertahun-tahun lalu di mana pengguna perlu menetapkan sendiri kasus uji sehingga semua orang di tim mengetahui TC mana yang mereka kerjakan untuk menghindari upaya duplikasi; UI adalah aplikasi web (internal). Pengguna hanya melihat tombol, tetapi cerita itu dibagi menjadi beberapa tugas yang mencakup beberapa detail implementasi teknis, dll.

Visibilitas Pengguna

Tetapi ada jenis aplikasi lain di mana sebagian besar kode harus berurusan dengan pemrosesan kompleks yang tidak langsung terlihat oleh pengguna.

Apakah mungkin membuatnya terlihat oleh pengguna dengan cara tertentu?

Pertimbangkan GPS. Ketika Anda melewatkan giliran Anda, Anda tidak akan melihat proses penghitungan ulang rute yang sebenarnya, tetapi pengguna memang menerima beberapa umpan balik yang berguna (misalnya, "Menghitung Ulang ...").

Compiler dapat menampilkan peringatan atau kesalahan, atau menyertakan pengaturan / opsi baru di GUI agar pengguna dapat melihat bahwa sesuatu yang baru telah ditambahkan. Saya pikir pengguna untuk kompiler adalah programmer, bukan? Tidakkah mereka melihat dukungan untuk standar baru ditambahkan?

Meskipun mendukung standar baru kemungkinan akan berada pada level fitur dan perlu dipecah menjadi cerita pengguna, sudahkah Anda memastikan bahwa, setidaknya dalam beberapa kasus, Anda tidak mencoba menggunakan cerita ketika Anda seharusnya menggunakan fitur sebagai gantinya ?

Analisis gambar dalam sebuah mobil dapat dirumuskan dengan cara yang memungkinkan pengguna tahu bahwa kemungkinan berakhir dalam kecelakaan mobil telah berkurang. Sebagai contoh:

Sebagai penumpang dalam mobil yang bisa menyetir sendiri, saya membutuhkan kemungkinan kendaraan yang menyebabkan kecelakaan dengan menabrak benda yang tidak dikenali sedekat mungkin dengan nol, sehingga saya dapat melakukan perjalanan lebih aman.

Bahwa AS menangkap, pada level tinggi, hal-hal yang biasanya harus Anda tentukan menggunakan kombinasi persyaratan fungsional dan non-fungsional - termasuk keamanan, keselamatan, dll.

Namun, persyaratan mungkin lebih banyak tentang sistem; misalnya:

Fungsi abcdalam komponen Aharus memiliki nilai ambang toleransi menurun dalam algoritma perbandingan gambar untuk lebih mendeteksi objek bergerak lambat.

Bagi saya, ini akan dengan mudah menjadi tugas di bawah kisah pengguna yang saya sebutkan di atas, berjudul sesuatu seperti: Kurangi toleransi dalam fungsiA.abc dan kemudian sertakan detail relevan lainnya di dalamnya.

Untuk sistem simulasi fluida, Anda bahkan bisa memiliki bilah kemajuan yang memberikan umpan balik tentang tugas latar belakang yang dilakukan sistem, jika ini masuk akal. (Selalu ada cara untuk memberi tahu pengguna tentang sesuatu, meskipun Anda mungkin ingin menghindari spam.)

Saya tidak cukup tahu tentang domain tertentu yang telah Anda sebutkan untuk menghasilkan contoh yang lebih baik dan / atau lebih realistis, tetapi jika ada kesimpulan di sini adalah bahwa Anda dapat menggunakan berbagai cara untuk memberikan umpan balik pengguna tentang sesuatu yang kurang terlihat sehingga sistem mungkin sedang melakukan, yaitu mungkin ada cara untuk membuat hal-hal yang tak terlihat sedikit lebih terlihat. (Bahkan jika itu bermuara pada menulis satu set catatan rilis yang mendokumentasikan seberapa cepat kinerja sistem sekarang karena upaya Anda, dll.)

Hubungan antara Cerita dan Tugas

Di sini sangat sulit untuk mengaitkan tugas dan cerita pengguna.

Pendekatan kami adalah untuk membuat cerita pengguna tetap fokus pada apa permintaan itu, mengapa itu dibuat, dan hal-hal apa yang perlu benar untuk menganggap AS "selesai". The bagaimana selalu ditinggalkan dari Amerika Serikat dan kiri untuk pengembang (s).

Pengembang akan memecah masalah yang dijelaskan di AS menjadi serangkaian tugas yang akan mereka kerjakan.

Saya mengatakan ini sebagai seseorang yang, sebagian besar, melakukan pemrograman sisi server back-end, yang mungkin sebagai "tidak terlihat" seperti yang Anda dapatkan untuk pengguna akhir.

Bergantung pada apa yang perlu saya lakukan, saya kadang-kadang menggunakan AJAX untuk menunjukkan animasi "memuat ..." sederhana / gif sehingga pengguna tahu mereka perlu menunggu sedikit untuk menyelesaikan sesuatu, tanpa mendapatkan kesan yang salah. Terkadang sesederhana ini. Tugas untuk ini akan sesuai.

Paradigma, Praktik, dan Pengalaman yang berbeda

Apakah ada teknik untuk mengatasi masalah ini atau itu hanya sesuatu yang harus kita terima dan lakukan yang terbaik?

Selain menerima perubahan paradigma, berlatih, dan pengalaman yang masih harus dibayar, mungkin tidak banyak bicara. Saya sering melihat orang mencoba mengambil jalan pintas melalui proses. Saya akan menyarankan hal itu, terutama jika Anda memulai. Saat Anda mendapatkan lebih banyak pengalaman, Anda bisa memberikan fleksibilitas, tetapi hindari merusak diri sendiri.

Mengingat kata-kata Anda sebelumnya, Anda masih berpikir tentang cerita seolah-olah itu "persyaratan berganti nama", yang saya anggap salah asumsi. Saya pikir ini adalah gejala dari masalah yang lebih dalam mengenai perbedaan mendasar antara pendekatan Agile dan non-Agile.

Kedua, saya pikir Anda harus menerima bahwa gesit adalah perubahan paradigma dibandingkan dengan air terjun, yang berarti bahwa, meskipun prosesnya memiliki tujuan yang sama, mereka melakukannya dengan cara yang sangat berbeda. (Pikirkan SVN vs Git, jika itu membantu.)

Cobalah untuk meningkatkan pemahaman Anda saat ini tentang perbedaan konseptual antara persyaratan dan cerita pengguna dan terima itu bukan hal yang sama.

Belajar dari Sprint Anda - Retrospektif

Apa yang saya tidak bisa cukup menekankan adalah retrospektif antara Scrum Master dan Developers di akhir setiap sprint. Itu adalah tempat di mana mereka mendiskusikan hal-hal yang "berjalan dengan baik" atau "tidak berjalan dengan baik" dengan cara yang jujur / transparan, dan perubahan apa yang bisa dilakukan akan diterapkan untuk sprint berikutnya untuk membahas poin "tidak berjalan dengan baik" .

Itu memungkinkan kami untuk beradaptasi dan bahkan belajar dari pengalaman satu sama lain, dan sebelum kami menyadarinya, kami telah meningkat secara signifikan yang diukur dengan konsistensi umum kecepatan tim kami.

— code_dredd
sumber

"User Stories! = Requirements": Saya tidak bermaksud mengatakan bahwa keduanya adalah sinonim. Tidak semua persyaratan adalah cerita pengguna. Tapi saya pikir semua cerita pengguna adalah persyaratan. Saya melihat persyaratan sebagai struktur hierarki di mana cerita pengguna adalah satu tingkat detail yang spesifik. Apakah kamu setuju?

— Frank Puffer

@ Frankpuffer Saya pikir melihat cerita pengguna seolah-olah mereka berbeda tingkat dalam hierarki persyaratan pada dasarnya mencampurkan konsep yang berbeda. Di sisi Agile, hierarki lebih mirip: Tema >> Epics >> Fitur >> Cerita Pengguna >> Tugas . Persyaratan biasanya dibagi menjadi persyaratan fungsional dan non-fungsional dalam pendekatan Waterfall yang lebih tradisional, tetapi saya belum menemukan hierarki yang sebenarnya; yang mengatakan, saya tidak akan terkejut jika seseorang secara rekursif memecah persyaratan menjadi persyaratan "sub" yang lebih kecil. Bagaimanapun, Anda mencampurkan konsep yang berbeda.

— code_dredd

Sistem manajemen persyaratan seperti PTC Integrity memperlakukan persyaratan sebagai hierarki. Ini bisa menjadi keuntungan saat memetakan persyaratan ke dokumen spesifikasi.

— Frank Puffer

@ FrankPuffer Ya, itu sebabnya saya katakan saya tidak akan terkejut. Yang mengatakan, saya ingin tahu jawaban saya telah menjelaskan apa pun untuk Anda. Apakah analogi SVN vs Git bermanfaat? (Ini mengasumsikan Anda terbiasa dengan kedua sistem, yang tampaknya masuk akal dalam konteks pengembangan perangkat lunak.)

— code_dredd

Ok, saya salah membaca "tidak" seperti "akan". Dan ya, saya menemukan jawaban Anda sangat membantu dan mungkin akan menerimanya. Saya mungkin hanya perlu waktu untuk membiasakan diri dengan tidak mempertimbangkan cerita pengguna sebagai persyaratan.

— Frank Puffer

4

Prinsip tangkas tentu dapat diterapkan dalam kasus ini. Bagaimana?

Kompiler dapat memiliki fitur bahasa baru yang ditambahkan kemudian dalam cerita pengguna yang terpisah
Sistem analisis gambar dapat memiliki fitur baru yang ditambahkan sebagai klasifikasi gambar yang berbeda
Sistem simulasi aliran fluida dapat mempertimbangkan aspek model yang berbeda dalam simulasi mereka

Anda tidak harus memakan seluruh gajah dalam satu gigitan. Agile hanya meminta agar Anda menunjukkan Anda telah membersihkan piring Anda sebelum menyajikan gajah berikutnya.

— candied_orange
sumber

Namun saya masih berpikir bahwa satu atau lebih cerita pengguna akan tetap yang memerlukan banyak fungsi dasar yang disebut. Mereka akan sering tidak masuk ke dalam sprint tunggal. Bagaimana ini harus ditangani?

— Frank Puffer

1

Anda mengukur kesuksesan dengan aplikasi yang dapat dijalankan yang dapat diuji, dilihat, atau disentuh oleh pelanggan. Jika itu masalahnya, berikan mainan yang menghasilkan rasa kemajuan kepada mereka. Misalnya, Anda mungkin tidak bisa merilis mobil self-driving dalam sprint pertama, tetapi Anda dapat membuat demo tentang bagaimana algo do Anda merekrut orang. Nantinya, bagaimana cara merekonstruksi sinyal dan hewan. Nanti bagaimana mengukur jarak, ukuran, dll ... Mobil self-driving jauh, jauh di sprint terpencil yang tahu kalau itu akan terjadi.

— Laiv

2

@Laiv: Itu akan menyenangkan tetapi saya tidak yakin apakah itu berhasil. Dalam parctice, setelah beberapa sprint pertama, perangkat lunak tidak akan dapat melakukan apa pun yang dapat dihubungkan oleh pelanggan. Anda akan memiliki kemajuan teknis tetapi akan sulit, jika bukan tidak mungkin, untuk mengkomunikasikannya kepada pelanggan.

— Frank Puffer

2

Mengapa? Karena itu ditulis di atas batu oleh orang asing ke proyek Anda? Saya berharap Agile menyesuaikan diri dengan kebutuhan saya, bukan sebaliknya. Jika saya katakan saya bisa mengajari Anda bermain skate dalam 4 minggu dan sekali pada tanggal 5 Anda masih gagal berdiri, apakah itu berarti Anda tidak belajar skate? Atau hanya itu akan memakan waktu sedikit lebih lama? Manifes lincah tidak ditulis di atas batu atau aturan Scrum adalah Perintah Cenderung.

— Laiv

2

Inti dari sprint adalah menjadikan pelanggan Anda bagian dari iterasi Anda. Untuk berkomunikasi dengan mereka menggunakan kode yang dikirimkan. Bukan rencana dan janji. Ini mengharuskan Anda untuk fokus pada pemecahan masalah. Itu tidak mengharuskan bahwa hal pertama yang Anda kirimkan diatur dalam batu. Ini mengharuskan Anda membuktikan bahwa Anda layak membayar setiap sprint.

— candied_orange

1

Saya menemukan bahwa orang-orang yang secara ketat mengikuti cerita pengguna hanya akan terlibat dalam latihan yang sangat konyol untuk menghasilkan cara-cara yang jauh di mana perubahan teknis berdampak pada pengguna (tanpa sepengetahuan pengguna tentu saja karena mereka hanya naif pengguna dan Anda sedang berbicara tentang perubahan kompleks dalam garis pipa analisis data Anda atau semacamnya) atau mereka akan benar-benar kehilangan untuk "bagaimana kita mengatur pekerjaan ini!?!"

Saya pikir solusi yang jelas adalah menjadi lebih pragmatis. Jika pekerjaan itu bersifat sangat teknis dan tidak memiliki dampak yang sangat nyata pada pengguna, jangan sampai kurang tidur mencoba menjelaskan caranya. Cukup pilih cara yang jelas dan sederhana di mana itu dapat bermanfaat bagi pengguna dan kemudian mengarahkan cerita di sekitar perincian yang diperlukan bagi pengembang untuk melakukan pekerjaan mereka. Saya merasa sangat frustasi ketika PO bersikeras tidak memiliki informasi teknis dalam cerita ketika itu benar-benar diperlukan. Hanya saja bukan pandangan yang sangat menyeluruh tentang apa artefak itu (cerita) sebenarnya. Seperti mereka pikir itu ada hanya untuk mereka, dalam banyak kasus itu penting bagi para insinyur juga.

Untuk sebagian besar tugas teknis ini ada beberapa buah tergantung rendah sehubungan dengan dampak pengguna, apakah itu meningkatkan efisiensi sehingga pengiriman di masa depan akan lebih cepat, meningkatkan kinerja, keandalan dll. Mereka tidak benar-benar memikirkan apa yang orang pikirkan ketika mereka memikirkan 'cerita pengguna' tetapi jika bisnis ingin memahami mengapa Anda melakukan hutang teknis atau sesuatu seperti itu, maka penjelasan ini biasanya paling sederhana untuk diberikan.

Saya tidak membiarkan scrumnazi membuat hidup Anda lebih sulit hanya karena mereka terlalu sulit untuk beradaptasi. Menjadi adaptif adalah konsep inti lincah. Ketaatan yang ketat terhadap Scrum atau Agile biasanya terbang di wajah atau pragmatisme dan kepraktisan (apa yang sebenarnya paling berhasil).

— evanmcdonnal
sumber

Saya semua untuk menjadi fleksibel, tetapi terus terang pengguna tidak terlalu peduli tentang detail teknis, asalkan cerita mereka puas. Anda tidak harus "sangat gesit" untuk memiliki persyaratan yang baik; dan dengan persyaratan yang baik, maksud saya persyaratan yang masing-masing disertai dengan tes penerimaan yang jelas membuktikan persyaratan terpenuhi. Orang-orang yang "melakukan latihan yang sangat konyol" jelas melakukan kesalahan, tetapi itu tidak berarti mereka mengikuti gagasan "scrum ketat."

— Robert Harvey

@RobertHarvey Saya setuju rincian teknis tidak relevan bagi pengguna tetapi poin saya adalah bahwa artefak yang berisi cerita pengguna memiliki tujuan yang lebih luas daripada hanya mengkomunikasikan bagaimana hal-hal bekerja untuk pengguna (atau setidaknya mereka seharusnya). Bagaimana seseorang menegakkan persyaratan yang terkait dengan arsitektur, ekstensibilitas, kinerja, dan sebagainya jika mereka menulis cerita pengguna murni? Mengambil pendekatan 'kisah pengguna' murni memberi insentif kepada pengembang untuk menulis kode berkualitas buruk. Dan itu bukan pengguna yang membaca 'cerita pengguna' itu devs dan qa, itu bodoh untuk sengaja mengecualikan informasi yang relevan karena itu teknis.

— evanmcdonnal

0

Saya pikir masalahnya adalah memberikan kisah pengguna makna yang tidak mereka miliki. Scrum menggunakan istilah PBI, atau Product Backlog Item, yang menurut saya jauh lebih baik. PBI akan sering mengikuti format cerita pengguna, misalnya, Anda mungkin memiliki PBI seperti "Pelanggan harus dapat melihat detail langganan mereka", tetapi Anda juga mungkin dengan mudah memiliki PBI seperti "Buat prosedur tersimpan untuk mendapatkan detail pelanggan ".

Cerita pengguna adalah alat . Mereka membantu Anda membentuk deskripsi fitur dan persyaratan berdasarkan menempatkan diri Anda pada posisi pengguna. Tapi, sama seperti kunci pas tidak berguna ketika Anda perlu menggantung gambar, ada kalanya Anda mungkin tidak perlu cerita pengguna.

Yang mengatakan, banyak tim sebenarnya hanya bermain cepat dan lepas dengan bagian "pengguna". Mereka mungkin memiliki "kisah pengguna" seperti "Sebagai pengembang, saya harus dapat memanggil prosedur tersimpan untuk mendapatkan detail pelanggan", yang pada dasarnya adalah "cerita pengembang". Ini adalah opsi yang sama-sama valid, tetapi secara pribadi, saya katakan selama Anda dapat menggambarkan apa yang perlu dilakukan dan menghasilkan seperangkat kriteria penerimaan, hampir tidak masalah jika Anda memiliki kisah pengguna yang sebenarnya di belakangnya atau tidak.

— Chris Pratt
sumber

1

Saya tidak setuju dengan ini kecuali dalam kasus yang sangat aneh dan langka. Dalam Scrum, BAGAIMANA adalah lingkup tim pengembangan, bukan pemilik produk. Namun pemilik produk harus bertanggung jawab atas PBI. Jadi PBI seperti "buat prosedur tersimpan" mengambil dari tim pengembangan hak untuk memilih BAGAIMANA. PBI, apakah itu cerita pengguna atau bukan, harus menjelaskan apa nilai bisnis dalam melakukan PBI. Membuat prosedur tersimpan bukan tentang nilai bisnis, ini tentang detail implementasi.

— RibaldEddie

Itu bukan intinya. Itu hanya sebuah contoh. Anda bisa mengubah "prosedur tersimpan" menjadi sesuatu yang umum seperti "cara". Intinya adalah bahwa itu tidak harus menjadi cerita pengguna.

— Chris Pratt

Inti dari contoh adalah menjadi contoh. Jika contoh Anda "bukan intinya" lalu apa gunanya contoh itu ??

— RibaldEddie

-3

Jenis aplikasi ini adalah persis di mana keahlian yang berbeda hadir dan akan dikembangkan lebih lanjut. Anggota tim akan memiliki karena pendidikan yang berbeda, proyek hobi yang berbeda dan keterampilan kerja masa lalu yang berbeda. Lebih lanjut, jika seseorang mengembangkan potongan kode tertentu, pengembang dapat diharapkan menjadi orang yang paling mengetahui kode tersebut. Jadi mungkin masuk akal untuk memberikan tugas pengembangan lebih lanjut yang melibatkan potongan kode yang sama kepada pengembang yang sama.

Dalam proses tangkas yang paling populer, Scrum, ada poker perencanaan di mana setiap tugas diberi tingkat kesulitan. Tingkat kesulitan tidak tergantung pada orang yang melakukan tugas itu sesuai dengan proses. Kemudian selama sprint, orang dianggap homogen sehingga setiap orang diharapkan dapat memilih setiap tugas dan mengimplementasikannya. Dalam proyek-proyek seperti CRUD sederhana, asumsi ini berlaku. Tetapi dalam proyek yang sangat kompleks dan sulit, tentu saja tidak.

Saya tidak akan menggunakan proses lincah untuk proyek semacam ini. Pilihan terbaik Anda adalah menghindari proses formal dan hanya menggunakan manajemen proyek yang baik. Saat memutuskan siapa yang mengimplementasikan fitur tertentu, pertimbangkan siapa yang memiliki keterampilan terbaik yang dibutuhkan untuk fitur ini dan pengetahuan terbaik tentang kode yang ada. Tidak diperlukan proses untuk ini. Anda mungkin ingin menulis dokumen desain yang bagus untuk semua fitur dan tetap memperbaruinya. Perhatikan bahwa saya tidak mempromosikan model seperti air terjun di sini: dokumen desain tidak akan semuanya ditulis pada awal proyek; Anda malah akan menulis dokumen desain baru karena fitur baru diperlukan.

— ahli hukum agama
sumber

5

Tidak benar-benar terkait dengan pertanyaan saya, tetapi selalu membiarkan orang dengan keterampilan terbaik mengimplementasikan fitur bisa berbahaya. Ini menghambat penyebaran pengetahuan di dalam tim. Jika pemeliharaan diperlukan dan ahli telah meninggalkan tim atau untuk sementara tidak tersedia, Anda akan berada dalam masalah.

— Frank Puffer

@FrankPuffer Untuk beberapa jenis sistem yang Anda daftarkan, misalnya mobil self-driving, jika ahli meninggalkan tim Anda dalam masalah. Titik. Meskipun mungkin bukan kasus bahwa pengkodean harus terpusat, itu juga sama sekali tidak masuk akal untuk mengasumsikan "penyebaran pengetahuan" yang memadai untuk memungkinkan penggantian ahli dalam skala waktu yang cukup singkat. Mereka adalah orang-orang yang akan menghabiskan lebih dari satu dekade untuk meneliti masalah ini, dan mungkin berada di dekat bagian atas bidang mereka. Anda mungkin akan membutuhkan banyak orang seperti ini dengan keahlian berbeda. Proyek-proyek semacam itu secara inheren berisiko.

— Derek Elkins meninggalkan SE