Prioritaskan dengan MoSCoW

Saya belum pernah mempelajari Dynamic Systems Development Method (DSDM), sebuah Agile methology yang banyak dipakai di Eropa (karena memang metodologi ini lahir disana). Tapi proses belajar saya pada Agile methodology, mengantarkan kepada cara memprioritaskan dengan metode metode MoSCoW yang ada pada DSDM.

Methode MoSCoW merupakan cara pembagian prioritas dengan level yang ditentukan untuk suatu kebutuhan (requirement/customer need), fungsi dari produk ataupun bagian dari proyek yang akan dibuat. MoSCoW sebenarnya adalah singkatan dari Must, Should, Can, Won't yang merupakan tingkatan pada suatu item yang diprioritaskan.

• MUST berarti sesuatu yang harus dimiliki (MUST have this)
• SHOULD berarti harus dimiliki jika memungkinkan (SHOULD have this if at all possible)
• CAN berarti dapat dimiliki jika tidak berefek pada yang lain (CAN have this if it does not effect anything else)
• WON'T berarti tidak perlu dimiliki, tapi mungkin nanti (WON'T have this time but would like in the future)

Pemriositasan sebaiknya dilakukan pada fungsi ditingkat yang tinggi (high level fungtionality) yaitu kebutuhan/fungsi yang belum didetailkan (masih general) misalnya waktu menentukan kebutuhan modul-modul utama pada aplikasi, dan juga pada tingkatyang lebih rendah yaitu kebutuhan/fungsi yang lebih spesifik.

Melakukan prioritas, baik dilakukan untuk menentukan bagian mana yang akan dikerjakan atau tidak, juga untuk menentukan mana akan dikerjakan lebih dulu.Prioritas fungsi atau kebutuhan pada high-level juga membantu kita untuk menentukan yang bagian mana yang merupakan out-of-scope dari project.

Komponen penting yang menjadi pertimbangan prioritas adalah project scope, kualitas, waktu, resources, dan resiko [referensi]. Komponen tersebut bisa saling berbenturan sehingga melakukan prioritas bukan hal yang mudah.

Kadang-kadang project scope tidak didefinisikan dengan detail atau jelas pada saat proyek mulai berjalan. Klien atau customer juga cenderung ingin semuanya kebutuhannya dipenuhi. Hal ini semua menyulitkan kita dalam memprioritaskan kebutuhan.

Dalam perjalanannya, prioritas suatu kebutuhan/fungsi sangat mungkin sering berubah sehingga meprioritaskan kembali (reprioritisation) jangan menjadi hal tabu. Yang perlu diwaspadai adalah banyaknya perubahan prioritas yang drastis misalnya dari level WON'T ke level MUST. Jika hal itu terjadi maka ada sesuatu yang salah dengan awal proses prioritisasi atau tujuan awal (goal) dari proyek.