ID Scum Notes


Project Pricing

Teman-teman yang lainnya sudah menjabarkan semuanya. Saya coba
nambahin dan semoga tidak bikin tambahn bingung.

Product owner itu bisa dari pihak customer atau dari in-house.
Tergantung situasi dan kebutuhannya.
Product owner itu intinya adalah pihal yang bisa mengendalikan dan
bertanggung-jawab atas “Return on investment”. Seperti yang
teman-teman sudah katakan, peranan Product owner ini sangat penting
sekali, karena kalau dia bisa memaksimalkan Scrum, ROI dari produknya
bisa besar. Kalau ROI besar ujung-ujungnya customer juga yang
diuntungkan. ūüėČ Disitulah makanya saya katakan PO ini harus mengerti
Scrum.

Dalam Scrum ataupun Agile secara umum, dikenal prinsip
Customer collaboration over contract negotiation
== kolaborasi dengan customer ketimbang negosiasi kontrak. Kontrak ini
biasanya secara tidak langsung mengacu pada “Fixed price” project.
[Source: http://agilemanifesto.org/
]

Kenapa? Karena yang dicari adalah kualitas dari produk. Customer
senang dengan produk yang dia telah bayar.

Kita jangan bisa semata-mata melihat dari harga saja. Yang harus
dilihat sebenarnya adalah ROI atau value dari produk tersebut, bukan
cost-nya. Harga bisa menipu.

Contoh sederhana:
– Beli sepatu dari pasar puring = Rp. 20,000
– Beli sepatu Reebok = Rp 200,000

Tapi yang dari pasar puring baru seminggu pakai sol-nya udah lepas.
Sedangkan sepatu Reebok udah 3 tahun dipakai masih awet aja. Jelas
bisa kita lihat disini harga bisa menipu.

Contoh lagi:
Tanpa Scrum, harga project = Rp. 5,000
Dengan Scrum, harga project menjadi Rp. 50,000

Tetapi tanpa Scrum hasil akhirnya malah banyak bug, requirement yang
tidak sesuai harapan user ataupun tidak user friendly. Kalau tidak
user friendly, user either jadi malas menggunakannya, akhirnya jadi
counter-produktif, bahkan mungkin tidak dipakai lagi. Kalau tidak
dipakai lagi uangnya juga kebuang sia-sia. Atau mungkin juga
project-nya di extend yang ujung2nya makan biaya lagi.

Dengan Scrum, user mendapatkan apa yang dia mau karena semua pihak
termasuk Product owner berkolaborasi penuh dengan tim developer.

Nah tapi apakah dengan begitu Scrum tidak bisa jalan dengan Fixed
Price. Bisa saja, tapi ini perlu kemahiran dari si Product Owner lagi
untuk bisa memainkannya.

Makanya semua pihak harus mengerti dahulu manfaat dari Scrum karena
kalau tidak ya cuma ikut-ikutan trend aja =D Dan kalau kondisinya
seperti itu, lebih baik kembali ke cara yang mula-mula saja. ūüôā Nah
makanya harus pintar-pintar jelasin ke kustomer. Kalau kustomer-nya
mengerti value dari Product, Insya Allah kamu bisa menangin tender.
ūüėÄ

Semoga ini dapat diterima, tapi kalau masih belum silahkeun
ditanyakan. Disini juga banyak rekan-rekan yang sudah berpengalaman
menggunakan Scrum.

Jadwal testing dan Error fixing di tengah jalan

Dalam Scrum, semua aktifitas yang biasanya kita lakukan di waterfall
dalam beberapa fase, dilakukan setiap hari di setiap sprint. Aktifitas
itu bisa berupa user requirement gathering, testing/QA, maupun
development. Di akhir Sprint tim Scrum akan mempresentasikan hasil
pekerjaannya di hadapan Product owner di dalam sebuah meeting yang
dinamakan Sprint review meeting. Sprint review meeting bukan bertujuan
untuk mengkritik, tetapi memberi masukan kepada Product owner mengenai
fitur/backlog apa yang dia bisa masukkan di Sprint planning
berikutnya.

Sekedar tambahan:
Walaupun Scrum popular dalam industri IT, tapi Scrum juga banyak
digunakan di industri lain seperti misalnya advertising, marketing,
perbankan. Dalam dunia advertising, marketing, perbankan, apabila QA
menunggu di akhir maka mereka bisa kehilangan kesempatan.

Ketika defect ditemukan di-dalam sprint, sang Product owner bisa meng-asses-nya.
Contoh:
– Is it a showstopper?
– bila bukan showstopper, apakah bisa menunggu sprint berikutnya?
– bila showstopper, apakah code-fix-nya besar?
– bila codefix besar, apakah ada temporary workaround?
– bila tidak ada temporary workaround, maka code-fix harus
dilakukan saat itu juga dengan konsekuensi Product owner tidak
mendapatkan semua backlog yang dia inginkan pada saat Sprint planning
– bila ada temporary workaround, lakukan itu dan code fix akan
masuk sprint berikutnya
– bila codefix tidak besar, fix it now dan tidak akan terlalu
menggangu deliverable di akhir sprint.

Story point and mandays

Para Scrummer dan simpatisan,
ada yg mengajukan pertanyaan melalui japri: story point itu dalam bentuk mandays gimana ya ?
(Mas, lain kali di jalur umum aja, siapa tahu ada pembaca lain yg juga kepingin tahu, atau belum tahu topik apa saja yg perlu didalami ūüôā ).
Penjelasan “story point” yg paling lengkap sumbernya adalah Mike Cohn, yg sekarang Chairman of the Board di Scrum Alliance.
Buku Mike Cohn ttg topik ini:¬†¬†“Agile Estimating and Planning”.¬†Penjelasan beliau juga¬†beredar di YouTube:

Singkatnya, story point sebagai takar ukuran “effort” itu justru TIDAK¬†untuk dihubungkan dg man-day atau estimasi yg diukur dg jam.
Contohnya: utk mengisi bak mandi dg air, seorang laki2 dewasa bisa mengangkut air dari sumur dua ember besar sekali jalan, tapi seorang anak kecil mungkin hanya bisa membawa satu ember kecil sekali jalan, dan jalannya pun lebih pelan, sehingga makan waktu yg lebih lama dalam jumlah menit dan jam dari si dewasa utk menyelesaikan tugas yg sama.
Dari sudut pandang lain, “story point”nya sama: satu bak mandi – tanpa perduli siapa yg mengisi airnya, dan berapa lama waktu yg dibutuhkan utk mengisi bak itu, atau oleh siapa.¬† Itu yg dimaksud dg “Business value, measured by story points”: “The Client” hanya ingin tahu bahwa tugasnya (mis. mengisi bak mandi)¬†sudah terpenuhi, tanpa perlu tahu siapa¬†yg mengisi, dan berapa lama.
Beberapa sprint (atau tahun) kemudian, si anak kecil tumbuh menjai remaja, dan bisa mengangkat ember air yg lebih besar, tugas yg sama bisa dia selesaikan lebih cepat. Tetap saja “story point” value untuk bak yg sama tidak berubah, walaupin¬†estimasi jam/man-day sudah menyusut.
Satu tim scrum focusnya adalah untuk memenuhi “business value”.
Tim yg sudah bekerja sama selama beberapa sprint biasanya bisa meningkatkan efisiensi kerjanya, sehingga bisa¬†meningkatkan “business value” yg mereka capai dalam kurun waktu satu sprint,¬†melebihi prestasi mereka di sprint2 awal.
Dg menggunakan “story point” sebagai takar ukuran, tim ini bisa membuktikan bahwa “velocity” mereka meningkat.
Efisiensi itu tidak akan kelihatan kalau task dan effort mereka hanya diukur dg. jam atau man-days.
Begitu kurang lebihnya.
Advertisements