Perpaduan yang tepat antara perencanaan dan pemrograman pada proyek baru

10

Saya akan memulai proyek baru (permainan, tapi itu tidak penting). Ide dasarnya ada di kepala saya tetapi tidak semua detailnya.

Saya tidak ingin memulai pemrograman tanpa perencanaan, tetapi saya benar-benar berjuang melawan keinginan saya untuk melakukannya. Saya ingin perencanaan sebelumnya untuk mencegah refactoring seluruh aplikasi hanya karena fitur baru yang bisa saya pikirkan memerlukannya. Di sisi lain, saya tidak ingin merencanakan beberapa bulan (waktu luang) dan memulainya karena saya khawatir saya akan kehilangan motivasi saat ini.

Apa yang saya cari adalah cara menggabungkan keduanya tanpa satu mendominasi yang lain. Haruskah saya mewujudkan proyek dengan cara scrum? Haruskah saya membuat cerita pengguna dan kemudian menyadarinya? Haruskah saya mengaktifkan fitur? (Saya memiliki beberapa pengalaman dalam scrum dan cara klasik "spesifikasi untuk kode".)

Pembaruan : Bagaimana memulai dengan "klik boneka" dan mengimplementasikan fungsionalitas nanti?

project-management agile

— Warren Faith
sumber

5

Anda berada di jalur yang benar. Tidak perlu menghabiskan waktu berbulan-bulan untuk merencanakan, tetapi Anda pasti harus memiliki semacam rencana.

Perencanaan akan membantu Anda mengatur pemikiran Anda, mengidentifikasi teknologi yang mungkin Anda butuhkan, memperjelas titik-titik masalah, dan memberi Anda peta jalan untuk bekerja sehingga Anda dapat memecahnya menjadi tujuan yang terukur.

Selain itu, Anda dapat melakukan perencanaan beberapa hari hanya untuk mengetahui bahwa ini adalah buang-buang waktu Anda. Mungkin ketika merencanakan, Anda menyadari bahwa Anda jauh dari liga atau bahwa apa yang Anda coba lakukan tidak dapat dipasarkan. Lebih baik untuk mengetahui hal itu sekarang sehingga Anda dapat menginvestasikan kembali waktu Anda ke ide-ide lain yang Anda miliki, daripada pergi menyusuri jalan ini hanya untuk menjadi tersesat di hutan, dikelilingi oleh tanaman merambat kode yang ketat dan jalur logika yang keliru yang memutar otak Anda menjadi simpul.

— jmort253
sumber

Platform penargetan adalah pekerjaan harian saya, jadi saya tahu sebagian besar teknologi yang ingin saya gunakan. Saya kira saya akan menggunakan scrum sederhana dan rencana dasar. Jadi saya bisa mulai dengan beberapa simpanan dan melakukan perencanaan pada setiap iterasi.

— WarrenFaith

Anda terus salah mengeja "perencanaan". Hanya berpikir saya akan menunjukkan itu karena saya tidak dapat mengedit komentar Anda :) Tapi ya, saya pikir scrum adalah pendekatan yang hebat telah mempertahankan fleksibilitas dan memberi Anda kesempatan untuk memutuskan apakah itu sepadan dengan upaya untuk melanjutkan proyek.

— jmort253

Oo Dalam bahasa Jerman itu adalah sebaliknya: perencanaan dengan satu n dan pemrograman dengan dua m ...: D Terima kasih!

— WarrenFaith

@ WarrenFaith - Maaf! Itulah etnosentrisme saya yang keluar! Terima kasih telah menunjukkan kesalahan saya;)

— jmort253

11

Rencanakan produk minimum yang layak , dan terapkan itu. Kemudian dengarkan pengguna Anda dan rencanakan peningkatan logis berikutnya, dan terapkan itu. Ulang.

— Steven A. Lowe
sumber

3

.... dan setiap kali Anda memiliki ide untuk sesuatu yang Anda pikir akan keren, tulis saja ide itu ke dalam scrum-backlog tetapi jangan diimplementasikan sampai produk minimum yang layak dilakukan.

— k3b

pertanyaan utamanya adalah seberapa dalam saya harus merencanakannya. Jika Anda bisa memberi saya nasihat itu juga, Anda mendapat jawaban yang diterima.

— WarrenFaith

1

@ WarrenFaith: fitur - >> cerita - >> kasus uji.

— Steven A. Lowe

4

Tidak peduli berapa banyak waktu yang Anda habiskan untuk merencanakan dan merancang program Anda, Anda selalu berakhir menulis ulang bagian itu. Ini seperti gravitasi, tidak pintar menyangkal keberadaannya.

Orang harus menyadari bahwa refactoring adalah bagian normal dari perkembangan dan itu hanya masalah memutuskan kapan Anda melakukannya. Tunggu lama dan Anda berakhir dengan spaghetti dalam jumlah besar, memohon untuk menulis ulang sepenuhnya. Tidak lucu.

Saran saya adalah merencanakan sedikit tetapi memulai coding secepatnya dan refactor, refactor, refactor untuk menjaga kode dalam bentuk. Prinsip KERING (jangan ulangi diri Anda sendiri) adalah indikator yang bagus untuk itu.

— Martin Wickman
sumber

Terima kasih untuk balasan Anda. Saya tahu bahwa refactoring bukanlah hal yang biasa, tetapi saya tidak ingin mencegah refactoring yang disebabkan oleh perencanaan yang terlewat.

— WarrenFaith

@ Warren - gagal merencanakan tidak mencegah refactoring. Anda dapat membuat kode solusi di komputer, atau mencoba kode di kepala atau di atas kertas. Saya pikir keduanya tidak efektif. Mulai coding, tahu Anda akan mengubahnya nanti.

— kevin cline

@kevin cline: Ok, mari kita membuat perbedaan antara refactoring kode yang ada untuk fitur baru atau peningkatan dan menulis ulang hampir seluruh aplikasi untuk fitur baru. Saya bisa hidup dengan yang pertama, tidak benar-benar dengan yang kedua ..

— WarrenFaith

@ WarrenFaith: Selama kodenya ketat dan bugar, Anda harus bisa menghindari penulisan ulang. Satu-satunya saat saya melihat penulisan ulang adalah ketika sistem telah menjadi bola lumpur besar (tidak ada refactoring), atau perubahan teknis mendasar (perubahan platform).

— Martin Wickman

3

Ketika saya dalam posisi ini saya kadang-kadang memanfaatkan TDD (test driven development) dan mulai merencanakan beberapa tes untuk bagian paling kompleks dari sistem yang saya kembangkan. Atau saya dapat mengumpulkan beberapa kode pseudo tingkat tinggi, sekali lagi untuk area yang paling kompleks. Saya menemukan proses ini memberi saya rencana aksi yang longgar dan membantu saya mengidentifikasi area mana yang paling memakan waktu.

Bagi saya pendekatan ini bekerja karena ia hidup di antara pengkodean dan perencanaan. Setelah Anda memiliki ide pengujian dan / atau kode semu Anda dapat bekerja melalui setiap bagian logis dan mengimplementasikan kode. Saya sering menangani bagian tersulit dari solusi yang diusulkan terlebih dahulu, karena biasanya bagian tersulit adalah fitur inti dari aplikasi dan Anda selalu dapat menunda bel dan peluit.

Karena Anda berkomentar bahwa sebagian besar kode ada di kepala Anda dan Anda siap untuk menyelam dan memprogram, menggunakan pendekatan ini dapat membantu Anda fokus pada setiap bagian tanpa pikiran Anda menjadi kabur oleh sistem secara keseluruhan.

Untuk meringkas lebih ringkas, orang bisa mengatakan "menangani bagian tersulit pertama, membagi dan menaklukkan, dengan kode pseudo dan / atau rencana TDD"!

— BradB
sumber

Saya bukan penggemar TDD tapi terima kasih!

— WarrenFaith

Saya tidak perlu mengatakan menggunakan TDD, maksud saya adalah itu adalah sesuatu yang saya gunakan sebagai struktur untuk "merencanakan" kode saya. Dengan begitu saya tidak langsung menulis kode saya dan saya tidak menghabiskan waktu lama menulis dokumen massal / rencana proyek yang agak terlalu jauh dari pengkodean yang sebenarnya. Ini tentang menemukan media yang bahagia. Anda dapat mencapai hal yang sama secara prinsip dengan pena dan kertas. Saya juga harus menunjukkan bahwa saya tidak menulis tes untuk SEMUA - hanya area yang lebih kompleks.

— BradB

3

Coba saja buat kode modular. Apa pun yang Anda rencanakan kemungkinan akan dibuang selama iterasi berikutnya.

— davidk01
sumber

2

Saya sarankan paling tidak menuliskan ide-ide Anda. Tergantung pada ukuran proyek, banyak perencanaan formal mungkin tidak diperlukan. Namun jika itu sangat besar, Anda mungkin ingin menyelamatkan diri dari sakit kepala dan menghabiskan beberapa hari melakukan perencanaan yang lebih mendalam.

— Kenneth
sumber