Apakah Scrum masuk akal ketika menerapkan backend kompiler baru?

Saya memiliki bahasa yang sudah ada yang perlu saya porting ke platform baru. Saya mungkin akan mencoba ini dengan mengubah backend dari kompiler yang ada.

Ini adalah sejumlah besar pekerjaan untuk menulis ulang backend. Saya tidak bisa melihat cara memecah ini menjadi cerita yang masuk akal tanpa melanggar kriteria INVEST.

Saya tidak dapat melihat bagaimana setiap cerita dapat dinegosiasikan - semuanya diperlukan untuk kompiler yang bekerja. Semua cerita memiliki prioritas yang sama dan tidak masalah urutan apa yang saya berikan. Saya perlu melakukan semuanya.

Ada beberapa bagian dari perangkat lunak yang saya implementasikan yang memiliki prioritas lebih rendah daripada yang lain dan saya dapat melihat bahwa kami dapat memberikannya secara bertahap. Namun, ada inti penting yang Harus Dimiliki .

Saya berencana untuk mencoba mengikuti Scrum, tetapi apakah saya hanya akan bergerak?

Apakah ada praktik yang direkomendasikan untuk proyek semacam ini?

Ingatlah bahwa alasan utama proses Agile dibuat adalah untuk mengatasi persyaratan pemindahan gigi. Jika persyaratan ditetapkan (persyaratan yang benar-benar ditetapkan jarang terjadi tetapi saya akan menepati janji Anda di sini!) Maka beberapa praktik terbaik untuk menangani perubahan persyaratan - misalnya cerita yang dapat dinegosiasikan - menjadi agak tidak relevan. Yang mengatakan, mengikuti alur kerja Scrum masih memiliki banyak nilai potensial dalam hal penjadwalan dan memberikan hasil. Meskipun kiriman Anda tidak akan menjadi produk yang sepenuhnya dapat digunakan untuk sementara waktu, masih ada sesuatu yang bisa dikatakan untuk bisa menunjukkan kemajuan kepada pelanggan Anda (dan tim!).

Pertimbangkan bahwa semua cerita 'must have' itu terdiri dari sebuah epik tunggal: "Mampu mengkompilasi di platform X". Dalam hal ini keseluruhan epik perlu diselesaikan sebelum nilai apa pun dikirimkan kepada pengguna, tetapi ini sering terjadi pada awal proyek besar. Mulailah dengan cerita untuk menyusun program yang paling sederhana, kemudian buat cerita lebih lanjut untuk mendukung lebih banyak fitur bahasa.

Di atas segalanya, jangan terlalu terpaku pada upaya untuk memaksa setiap situasi agar cocok dengan pendekatan yang sangat umum. Agile seharusnya bekerja untuk Anda, bukan sebaliknya!

Tentu saja Scrum bermanfaat. Ini adalah metodologi yang melakukan dua hal untuk Anda:

1. Ini memungkinkan proyek Anda untuk beradaptasi dengan perubahan dan
2. Ini memungkinkan Anda untuk melacak kemajuan, dan mendapatkan ide kapan itu akan selesai

Jadi, ada beberapa nilai dalam menggunakannya.

Saya pikir beberapa prasyarat Anda tidak benar dan di situlah Anda tersesat.

Saya tidak dapat melihat bagaimana setiap cerita dapat dinegosiasikan - semuanya diperlukan untuk kompiler yang bekerja

Ini tidak benar. Anda dapat mendukung subset bahasa dan masih memiliki kompiler yang berfungsi dalam kondisi tertentu. Tentunya kurang berharga dibandingkan kompiler penuh, tetapi tetap bernilai.

Selain itu, Anda salah memahami apa yang dimaksud dengan "Negosiasi": itu tidak selalu berarti "Opsional" dan tidak ada persyaratan bahwa cerita adalah opsional dalam INVEST. Sebuah cerita adalah tujuan yang berharga dan negosiasi tentang bagaimana mencapai tujuan itu. Tentunya akan ada lebih dari cara menerapkan backend dari setiap fitur bahasa. Di situlah Anda membutuhkan negosiasi.

Semua cerita memiliki prioritas yang sama dan tidak masalah urutan apa yang saya berikan.

Ini tidak benar, seperti yang Anda katakan di bawah ini bahwa beberapa cerita tidak "harus dimiliki", jadi tentu saja ada yang kurang berharga. Tetapi bahkan dalam kategori "harus memiliki": beberapa fitur bahasa jauh lebih mendasar daripada yang lain, dan terukur demikian.

Salah satu cara untuk mengukur ini adalah "berapa banyak lagi baris kode yang dapat kita kompilasi pada basis kode yang ada" atau "berapa banyak tes yang lulus" jika Anda memiliki serangkaian tes yang telah ditentukan.

Ada juga opsi lain. Jika Anda mengkompilasi bahasa mirip-C, secara tegas Anda hanya perlu a ifdan gotoloop untuk memiliki (hampir) bahasa fungsional dan Anda dapat mengimplementasikan while, fordan repeatsebagai makro. Dengan asumsi cukup mudah untuk menulis menggunakan precompiler, Anda dapat memiliki solusi sementara murah (hei, apakah kita sedang bernegosiasi? :-)

Mengenai, kemampuan beradaptasi, mendukung bahasa adalah serangkaian persyaratan yang cukup statis, tetapi bahasa juga berubah dan juga pengetahuan Anda tentang perubahan kebutuhan Anda . Apakah Anda perlu mengimplementasikan semuanya? Adakah hal-hal yang tidak Anda butuhkan secara spesifik untuk tujuan Anda? Salah satu penyewa dasar tangkas adalah pengetahuan memiliki pengetahuan yang tidak lengkap, dapatkah Anda memanfaatkannya?

Sebagai kesimpulan, untuk menjawab pertanyaan Anda secara lebih langsung: apakah Anda membutuhkan proses yang gesit ketika persyaratan Anda tidak dapat diubah? Tentu saja tidak! Apakah bisa digunakan? Mungkin iya! Apakah mereka sepadan dengan waktu Anda? Mungkin tidak - tetapi apakah kebutuhan Anda tidak dapat diubah? Dalam pengalaman saya sebelumnya, "persyaratan yang tidak dapat diubah" => "pemilik produk yang malas" - bukan suatu peraturan, tetapi perlu diingat.

TL; DR

Semua kontrol manajemen proyek menambah biaya tambahan. Jangan tambahkan overhead yang tidak Anda butuhkan.

Scrum Adalah Palu yang Salah Di Sini (Don't Be a Nail)

Scrum adalah kerangka kerja manajemen proyek daripada serangkaian praktik pengembangan yang cocok untuk pengembang individu. Kecuali Anda melakukan manajemen proyek, Scrum mungkin merupakan pilihan yang salah.

Selain itu, saat Anda mengatakan:

Semua cerita memiliki prioritas yang sama dan tidak masalah urutan apa yang saya berikan. Saya perlu melakukan semuanya.

Anda menyiratkan beberapa hal:

1. Proyek ini memiliki nilai nol kecuali semua cerita 100% selesai.
2. Kisah-kisah itu tidak saling bergantung satu sama lain.

Jika kedua pernyataan ini benar, maka benar-benar tidak ada gunanya menggunakan kerangka kerja atau praktik yang dirancang untuk memprioritaskan pekerjaan berdasarkan nilai atau urutan ketergantungan.

Alternatif yang Disarankan

Setiap proyek pengembangan berpotensi mendapat manfaat dari beberapa praktik tangkas. Secara khusus, dalam kasus spesifik Anda, saya akan merekomendasikan:

1. Pastikan semua cerita Anda memiliki "definisi selesai" yang mencakup pengujian unit dan penerimaan.
2. Integrasikan dan sering refactor; jangan tinggalkan diri Anda dengan tugas integrasi raksasa di akhir proyek.

Selain itu, bahkan jika produk Anda benar-benar memiliki nilai nol kecuali semua cerita selesai, saya akan meluangkan waktu mengelompokkan cerita ke dalam tema yang dapat Anda perlakukan sebagai tonggak yang sudah selesai. Mampu mengatakan "Saya telah menyelesaikan fitur foo" seringkali lebih berguna daripada mengatakan "Saya telah menyelesaikan 23/117 cerita acak." YMMV.

Saya memahami kekhawatiran Anda, tetapi saya yakin masih ada nilai bagi Anda dalam menggunakan scrum.

Memang, cerita pengguna jauh lebih pasti daripada dalam aplikasi yang dihadapi konsumen. Sehingga aspek scrum akan memberikan nilai lebih sedikit.

Di mana saya pikir Anda akan mendapatkan nilai adalah dari rilis berulang dan sering . Memiliki produk yang berpotensi dirilis di akhir setiap sprint memaksa Anda untuk menjaga kualitas kode tinggi dan utang teknis rendah. Ini juga merupakan cara yang bagus untuk menemukan cacat sejak dini.

Saya pikir Anda juga akan mendapat manfaat dari mengetahui kecepatan Anda . Setelah beberapa sprint, Anda dapat melihat berapa banyak poin upaya tim Anda menyelesaikan setiap sprint. Ini memberi Anda metrik objektif untuk membantu menentukan tanggal pengiriman Anda.

Yang terpenting, ingat bahwa lincah adalah kata sifat . Pada akhir setiap sprint, Anda harus mengadakan pertemuan retrospektif dan kemudian menyesuaikan proses Anda dengan kebutuhan Anda. Jika ada bagian dari proses scrum yang tidak berlaku untuk pengembangan kompiler, hapus. Jika ada beberapa elemen proses lain yang akan menguntungkan Anda, tambahkan saja. Bagian terpenting dari gesit menurut saya adalah untuk menyadari proses Anda dan terus-menerus memperbaiki situasi spesifik Anda.

(Harap dicatat, saya tidak pernah melakukan scrum pada proyek penyusun; ikuti saran saya dengan sebutir garam.)

Ya, tentu saja, selama Anda ingat bahwa Scrum bukanlah seperangkat aturan ketat yang harus diikuti. Anda dapat menyesuaikannya dengan proyek Anda. Sprint, standup, scrum mingguan masih akan berguna untuk menumbuhkan komunikasi yang lebih baik antara anggota tim dan memastikan proyek berlanjut ke arah yang dimaksudkan.

Semua cerita mungkin memiliki prioritas yang sama, tetapi Anda harus memperhitungkan kesulitan relatif untuk mengimplementasikannya. Anda tidak ingin menyimpan barang tersulit Anda sampai akhir proyek. Anda akan ingin mulai mengerjakannya sesegera mungkin.