Desain iteratif skala besar

Biasanya dalam pengembangan game, pengembangan linier ( model air terjun ) penuh dengan kendala yang menguras kewarasan programmer (game ternyata mengerikan, tidak bisa mendesain ulang). Masukkan desain berulang . Desain berulang memungkinkan untuk prototipe berbagai kemungkinan di ruang bermain. Sayangnya, ia memiliki tangkapan besar . Segera setelah proyek bertambah besar, iterasi menjadi sangat lama dan mematikan keuntungan utama: hasil yang cepat.

Bagaimana seseorang dapat mempersingkat iterasi desain untuk proyek skala besar?

Saya pikir infrastruktur yang baik dapat membantu ini. Salah satu contoh adalah memiliki sistem data yang bagus dan mudah digunakan sehingga para insinyur dapat dengan mudah mengekspos data baru melalui, dan bahwa desainer dapat dengan cepat mengubah data dan melihat hasilnya. Hal bagus lainnya adalah memiliki bahasa scripting - seperti lua - yang bisa digunakan oleh programmer, dan bahkan desainer, untuk dengan cepat membuat prototipe.

Juga, memiliki pipa seni / aset bagus yang mudah digunakan dan mudah untuk memasukkan aset ke dalam permainan.

Pada dasarnya, hilangkan hambatan bagi orang yang melakukan pekerjaan mereka dan merampingkan alur kerja mereka.

Sayangnya, solusi siap pakai untuk hal-hal itu tidak benar-benar ada (bahkan di mesin permainan populer, ini tidak semua benar-benar menyelesaikan masalah), yang berarti bahwa Anda harus menginvestasikan waktu rekayasa untuk mendapatkan kelincahan ini. Jadi, sayangnya, jawabannya adalah Anda harus meluangkan waktu untuk membuatnya sehingga Anda dapat bekerja dengan cepat, yang mana yang mengalahkan tujuannya. Namun, begitu Anda menghabiskan waktu, segalanya berjalan dengan baik. Jika Anda dapat menggunakan kembali pekerjaan Anda untuk proyek-proyek masa depan, dividennya bahkan lebih baik.

Timeboxing berarti iterasi tidak menjadi lebih lama

Anda bertanya bagaimana mempersingkat iterasi. Tapi itu berarti mereka mengambil lebih banyak waktu, yang berarti Anda tidak menerapkan tinju waktu. Dalam iterasi apa pun ketika kompleksitas mulai menimbang lebih banyak (atau Anda memiliki kemunduran tak terduga lainnya), Anda tidak mengubah panjang iterasi. Anda bukannya membatalkan penambahan tambahan yang Anda rencanakan di awal iterasi. Beberapa metode berulang menyarankan melakukan penilaian ini di tengah-tengah iterasi (sebelum terlambat). Baca lebih lanjut tentang apa yang disarankan OpenUP :

Kelola tujuan Ketika sebuah tim tertinggal jauh di belakang, atau terjadi masalah kritis yang mencegah tim dari memenuhi tujuan iterasi, mungkin perlu untuk membatalkan pekerjaan untuk memastikan bahwa tim memberikan peningkatan produk yang berguna pada akhir iterasi, sambil memaksimalkan nilai pemangku kepentingan. Bekerja dengan tim dan pemangku kepentingan untuk merevisi Rencana Iterasi dan, jika perlu, mengurangi penekanan pada tugas-tugas yang kurang penting dengan menunda mereka ke iterasi berikutnya. Dalam kasus yang jarang terjadi, jika tujuan iterasi tampaknya masih mustahil dipenuhi, tim mungkin mempertimbangkan untuk mengakhiri iterasi atau merumuskan ulang iterasi ke tujuan baru.

Jika Anda melihat pada grafik pertama Anda dapat melihat bahwa nilai tambah kurang di iterasi selanjutnya. Ini berarti iterasi masih membutuhkan waktu seperti sebelumnya, tapi mungkin ada fungsionalitas yang lebih baru (relatif) dalam setiap iterasi.

Seperti yang Anda katakan, kekuatan berulang adalah mengurangi risiko dengan mendapatkan umpan balik sesering mungkin. Kedengarannya seperti Anda sedang berbicara tentang kerumitan proyek yang menghambat Anda pada iterasi selanjutnya? Saya tidak setuju ini adalah kelemahan yang berulang. Ini adalah kelemahan dari kompleksitas yang dikelola dengan buruk.

Secara teoritis, Anda menempatkan proyek dengan risiko terbesar di depan. Ini berarti Anda memiliki proyek yang sangat tidak stabil, tetapi ketika Anda mengelola risiko besar, itu seharusnya stabil. Kompleksitas, tentu saja, adalah salah satu risikonya.

Bahasa scripting dan proses otomatis membantu mengurangi risiko kompleksitas, yang dapat disebut kompleksitas "kebetulan" (dan dibahas dalam jawaban lain). Proyek yang sangat iteratif namun rumit (Chromium adalah contoh yang baik, meskipun bukan permainan) memiliki banyak infrastruktur untuk mengelola kompleksitas. Lihatlah https://www.chromium.org/developers untuk banyak contoh hal-hal seperti saran pengkodean untuk BuildBot .

Yang tidak ditunjukkan oleh angka ini adalah stabilitas proyek, yang mungkin terlihat seperti ini:

Sampai risiko teknis dipahami dengan baik, Anda berhadapan dengan prototipe sederhana