Haruskah saya menggunakan scrum untuk proyek besar? [Tutup]

8

Saya telah bekerja sebagai programmer pada proyek yang dirancang untuk perangkat lunak generik untuk pompa bensin (untuk didistribusikan kembali untuk banyak pelanggan) selama 18 bulan. Proyeknya besar. Hari ini kami memiliki sekitar 150 meja. Kami belum menggunakan pendekatan tertentu, itu tidak dikelola dengan baik.

Tabel orang saat ini memiliki sekitar 70 kolom, tetapi 15 bulan lalu memiliki sekitar 30 kolom. Bidang baru ini muncul untuk berintegrasi dengan modul lain seperti penjualan, keuangan dan akuntansi. Juga banyak bidang dibuat kemudian dihapus.

Akibatnya, kami memiliki banyak refactoring dan pengerjaan ulang. Proyek tidak pernah bersiap karena selalu ada persyaratan baru yang muncul.

Inilah keraguan saya: jika kami menggunakan pendekatan spesifikasi yang biasa, kami akan melakukan wawancara, dokumen persyaratan, aktivitas, urutan dan diagram kelas, jadi kami akan tahu sejak awal bahwa tabel "orang" akan membutuhkan 70 bidang, maka kami telah menghindari banyak refactoring.

Bisakah scrum membantu dalam proyek ini? Saya merasa bahwa dalam kasus ini scrum akan berakhir dengan banyak refactoring juga.

Saya hanya seorang programmer, bukan manajer proyek. Saya bertanya-tanya bagaimana seharusnya dilakukan: dengan scrum atau dengan desain besar di depan.

Edit

Sekadar melengkapi akhir cerita ini. Delapan bulan kemudian saya mengajukan pertanyaan ini, setelah menempatkan proyek dalam produksi di beberapa "pelanggan uji" proyek gagal resmi. Pemilik produk memutuskan untuk meninggalkan proyek. Itu jadi sulit untuk memperbaiki masalah dan banyak masalah kinerja terjadi.

scrum requirements-management

— Murilo
sumber

8

Di Scrum, diasumsikan dan diterima bahwa Anda tidak dapat mengetahui semuanya di muka dan bahwa Anda akan tetap melakukan banyak refactoring.

— Bart van Ingen Schenau

2

Refactoring sering dianggap sebagai bagian inti dari setiap proses tangkas, sehingga kemungkinan Scrum akan menghasilkan jumlah refactoring yang sama atau lebih. Saya kira pertanyaannya adalah, mengapa menurut Anda ini masalah? Apa yang tangkas coba atasi adalah bahwa persyaratan dan desain di muka tidak sempurna, dan Anda lebih baik memberikan nilai kepada pelanggan secara bertahap untuk menemukan persyaratan yang sebenarnya. Jika Anda bisa menjamin rencana yang sempurna di depan Anda mungkin bisa melakukannya dengan cara itu, dan masih memberikan nilai secara bertahap. Tetapi apakah tangkapan persyaratan awal sudah sempurna?

— Robin

3

Saya tidak yakin judulnya mencerminkan pertanyaan yang Anda ajukan.

— gbjbaanb

6

@LightnessRacesinOrbit: dia jelas berbicara tentang beberapa jenis aplikasi database inhouse, dengan skema DB dengan 150 tabel. Beberapa orang tampaknya menganggap tidak ada jenis perangkat lunak lain. Saya merekomendasikan mereka untuk membaca Five Worlds karya Joel Spolsky .

— Doc Brown

2

@Murilo "Beberapa perubahan memengaruhi hal-hal yang berfungsi." Ini adalah masalah umum dan yang diharapkan dengan setiap perubahan dalam sistem perangkat lunak, untuk membantu mengurangi masalah ini. Unit Test dapat dikembangkan (bersama pengembangan primer) untuk memberikan wawasan tentang apa efek refactoring terhadap sistem yang ada.

— YoungJohn

18

Sepertinya Anda telah mengaduk-aduk jalan Anda dalam proses pengembangan yang tidak terkendali untuk membuat sistem pengembangan yang tidak pernah berakhir. Ini terjadi dalam sistem yang gesit juga.

Masalah root adalah kurangnya persyaratan, dan sementara solusi Anda tampaknya menggunakan metodologi tangkas untuk memperbaiki ini (karena tangkas dirancang di sekitar perubahan persyaratan) itu tidak akan menyelesaikan masalah.

Bahkan metode gesit membutuhkan titik awal yang cukup kuat. Mereka merespons dengan baik terhadap perubahan persyaratan, tetapi sama tidak bergunanya dengan metodologi lain jika Anda memulai tanpa persyaratan. Anda masih harus memiliki rencana yang Anda tuju sebelum mulai. Agile membantu ketika tujuan itu melayang, itu tidak membantu Anda menentukan tujuan itu.

Sekarang memang benar bahwa desain muka tetap terlalu kaku jika Anda tidak tahu persis apa yang Anda sedang membangun.

Jadi, saya pikir Anda harus beralih dari metodologi 'kekacauan' Anda saat ini ke sesuatu yang lebih terorganisir dan harus menerapkan desain dan perencanaan yang adil. Anda dapat mencoba melakukan ini dalam sekali pakai dengan metodologi yang berat, atau Anda bisa lebih fleksibel dengan yang gesit. Yang tidak bisa Anda lakukan adalah mengharapkan metodologi apa pun untuk memperbaiki kekurangan Anda pada perencanaan awal.

Kebetulan, suara Kanban lebih cocok untuk kebutuhan Anda. Scrum bekerja paling baik dengan tim dan proyek kecil. Kanban dapat bekerja dengan proyek yang lebih besar tetapi juga bekerja dengan pendekatan kerja throughput, sehingga perubahan desain terus menerus dan tidak terpotong menjadi sprint. Saya pikir Anda akan lebih sukses dengan itu.

— gbjbaanb
sumber

Anda melakukan beberapa pernyataan yang sangat bagus. Ini benar-benar kekacauan. Saya tidak cukup jelas: Saya tidak ingin memperbaikinya, karena saya hanya seorang pengembang proyek, jadi saya tidak punya cara untuk mengubahnya sekarang, tetapi saya bertanya-tanya bagaimana itu akan dilakukan dengan benar. Terima kasih banyak atas jawaban baik Anda. P. Kami menggunakan papan Kanban di sini untuk mencoba bantuan.

— Murilo

2

Jawaban Anda tidak buruk, tetapi "Masalah root adalah kurangnya persyaratan" ??? Jujur saja, bagiku itu terdengar sebaliknya. OP sudah memiliki lebih banyak persyaratan di atas meja daripada dia memproses dan mengelola dengan serius.

— Doc Brown

@DocBrown Ya, cukup adil - bukan kurangnya persyaratan tetapi salah satu persyaratan yang dikelola dan / atau dirancang dengan baik - yaitu terlalu banyak "lakukan saja ini" dan tidak cukup "inilah spesifikasi pemikiran Anda" - yang seharusnya mengurangi refactoring. berbicara tentang. Mungkin saya salah dan menafsirkan pertanyaan itu dengan buruk.

— gbjbaanb

@Murilo Berdasarkan pengalaman saya, jika Anda bertanya-tanya "bagaimana hal itu akan dilakukan dengan benar," jawabannya tidak banyak berkaitan dengan teknik yang diterapkan, dan semuanya terkait dengan orang-orang yang menerapkan teknik dan mengelola proyek.

— Cort Ammon

2

"Agile membantu ketika tujuan itu melayang, itu tidak membantu Anda menentukan tujuan itu." : Ini adalah penjumlahan yang luar biasa dari tangkas:

— Bryan Oakley

12

18 bulan, 150 meja dan masih belum di produksi? Kedengarannya seperti pawai maut bagiku. Satu-satunya cara Anda dapat memperbaiki ini, jika ada kesempatan untuk menyimpan ini sekarang, adalah dengan mempersempit ruang lingkup proyek Anda secara dramatis - setidaknya untuk rilis produksi pertama Anda. Yang Anda butuhkan adalah perencanaan rilis yang tepat, tujuan kecil, dapat dicapai, dan mendapatkan sistem kepada pengguna akhir secepat mungkin.

Dan ketika Anda memiliki rilis pertama Anda di produksi, dengan hanya sepersepuluh dari persyaratan yang diterapkan, Anda harus memperpanjang langkah demi langkah dengan blok persyaratan berikutnya, yang akan menyebabkan "refactoring". Anda juga akan mendapatkan umpan balik, yang berarti perbaikan bug dan perubahan persyaratan, yang juga akan menyebabkan refactoring.

Sekarang untuk pertanyaan Anda - apakah Scrum akan membantu? Mungkin tidak. Scrum adalah alat untuk mendukung pengembangan berulang dan mengubah persyaratan, dan memfokuskan pada hal-hal penting terlebih dahulu. Metode "Agile" lain melakukan ini juga, dan proses yang tidak terlalu formal mungkin juga mengatasinya. Tetapi selama Anda mencoba membawa monster seperti ini dalam satu "big bang" ke dalam produksi, tidak masalah jika Anda menggunakan pengembangan "lincah" atau "muka", keduanya akan gagal.

Jadi sebelum berpikir tentang Scrum, pikirkan kembali tujuan Anda dan strategi rilis Anda, dan kemudian periksa apakah Scrum adalah alat yang tepat untuk itu, bukan sebaliknya.

— Doc Brown
sumber

1

Saya akan berpendapat bahwa "membawa monster seperti ini sekaligus ke dalam produksi" tidak tangkas sama sekali. Karena OP mengklaim menggunakan kanban , fokus pada produk minimal yang layak tampaknya telah benar-benar hilang sejak awal proyek.

@MichaelT: Saya setuju, masih bisa diperdebatkan jika yang disebut "pengembangan gesit" tanpa memberikan sesuatu yang dapat digunakan dapat benar-benar disebut "gesit":

— Doc Brown

Saya setuju dengan jawaban ini. Anda harus mulai dari suatu tempat, mulai menerbitkan kode Anda, mendapatkan umpan balik, membangun umpan balik, hanya siklus yang tidak pernah berakhir. Setidaknya pada saat itu Anda memiliki seseorang yang menggunakan alat ini.

— JonH

1

@MichaelT tempat saya bekerja, tim proyek gesit, tetapi infrastruktur pendukungnya jelas tidak. Jadi kami sebagai tim memberikan sesuatu yang dapat digunakan setiap beberapa minggu, tetapi kami hanya memiliki satu penyebaran produksi setiap 3-4 bulan terbaik yang merupakan keadaan dari apa yang siap untuk produksi pada waktu itu. Organisasi dalam fluks, semoga. Butuh waktu 3 bulan untuk memberi kami server uji misalnya. Jadi kami hanya puas dengan laptop sebagai server uji internal proyek sampai saat itu ...

— jwenting

8

Jika Anda tidak dapat mengelola persyaratan dan tidak memiliki orang yang mampu menerapkan persyaratan dengan benar, SCRUM tidak akan banyak membantu Anda, dan itu tampaknya menjadi masalah nyata yang Anda hadapi.
SCRUM dapat membantu Anda menghadapi perubahan persyaratan dengan lebih baik daripada sistem manajemen proyek yang lebih statis, tetapi bukan grail suci yang secara ajaib akan membuat semuanya berfungsi. Faktanya, kecuali jika orang-orang Anda ada di dalamnya, bersedia dan mampu bekerja dengan SCRUM, dan begitu juga dengan organisasi lainnya, hal itu mungkin akan memperburuk keadaan.

Jika Anda memiliki tabel yang tumbuh sangat banyak sehingga sesuai dengan hal-hal untuk dihubungkan dengan sistem lain, saya mendalilkan desain database Anda benar-benar cacat misalnya. SCRUM dalam jumlah apa pun tidak akan memperbaiki desain basis data Anda tanpa Anda termasuk orang-orang yang pandai merancang basis data di tim Anda dan tidak takut akan perubahan desain tersebut dan perubahan yang akan mereka timbulkan ke seluruh sistem Anda.

— jwenting
sumber

2

Harap perhatikan bahwa ketika saya menulis jawaban ini, saya tidak menyadari bahwa sistemnya belum diproduksi.

Mereka seperti Anda menggambarkan produk Anda, saya tidak berpikir bahwa masalah langsung Anda adalah mengelola persyaratan, atau proses pengembangan Anda. Ini adalah arsitektur sistem Anda.

Anda telah berhasil membuat monolit - dan yang agak besar. 150 tabel banyak untuk satu sistem *. Secara khusus, Anda menyebutkan bahwa Anda memiliki 40 bidang baru selama 15 bulan terakhir hanya untuk diintegrasikan ke sistem eksternal. Saya akan dengan serius mempertimbangkan memecah sistem Anda menjadi beberapa layanan otonom, mungkin dimulai dengan layanan untuk diintegrasikan ke sistem eksternal - tetapi kemudian mengidentifikasi area bisnis terpisah yang diterapkan dalam monolit Anda, dan kemudian mungkin memecah masalah tersebut menjadi layanan terpisah.

Jika Anda berhasil membagi monolit ini menjadi basis kode yang dapat dipelihara secara terpisah, Anda juga dapat membagi pengembang Anda menjadi tim yang lebih kecil dengan tanggung jawab yang jelas dalam bidang spesifik bisnis Anda, dan Anda dapat memiliki banyak tim lincah yang lebih kecil yang mempertahankan basis kode mereka sendiri, alih-alih semua peretasan dalam basis kode yang sama.

Mengenai mengapa Anda sampai pada arsitektur seperti itu, penyebab utama masalah Anda, mungkin ada banyak jawaban. Mungkin itu berakar pada proses pengembangan Anda, mungkin semua pengembang Anda hanya berpengalaman dengan perangkat lunak yang konsisten transaksional, atau mungkin itu adalah konsekuensi dari bagaimana struktur organisasi Anda (Anda adalah korban Hukum Conway ). Saya pikir ada peluang bagus itu adalah kombinasi dari dua yang terakhir.

Saya tidak berpikir bahwa menerapkan scrum, atau menjadi lebih baik dalam mengelola persyaratan akan membantu menyelesaikan masalah langsung Anda, atau akar permasalahannya. Menyesuaikan arsitektur untuk kompleksitas sistem Anda akan, dan mengatasi akar penyebab mengapa Anda membangun sistem seperti itu.

* Beberapa mungkin akan berpendapat bahwa mereka dapat mempertahankan sistem dengan 150 tabel - atau mereka telah mempertahankan sistem yang jauh lebih besar, tetapi saya percaya bahwa sebagian besar pengembang akan menganggap ini sejumlah besar tabel untuk satu sistem.

— Pete
sumber

1

Bagi saya ini kedengarannya seperti saran teknis untuk masalah organisasi - yang menurut pengalaman saya jarang berhasil. Arsitektur sistem dengan 150 tabel untuk satu sistem dapat menjadi masalah - permulaannya adalah ketika Anda mencoba mengembangkan dan menggunakan sistem tersebut dalam satu "big bang".

— Doc Brown

@DocBrown - Saya setuju dengan Anda. Pada saat saya menulis jawaban ini, tidak jelas bahwa proyek tersebut belum diproduksi. Saya kemudian salah menebak bahwa itu.

— Pete