Salam kenal dari Tito

[Tito Sigilipoe]

Selamat sore,

Salam kenal semua, perkenalkan nama saya Tito. Saya masih awam mengenai SCRUM, tetapi tertarik dengan proses-nya.

Saat ini saya bekerja di bidang e-learning di Serpong. Ketertarikan saya karena strategi development yang saat ini saya gunakan (Analysis-Design-Development-Implementation-Evaluation), merupakan metode waterfall. Besar harapan saya di grup ini akan mendapatkan banyak pencerahan. 

Terima kasih. 

[Ivan Darmawan]

Selamat datang dan salam kenal.

Yakin nih benar-benar waterfall? :)

--
Anda menerima pesan ini karena berlangganan grup "Scrum Indonesia Community" di Google Grup.
Untuk berhenti berlangganan dan berhenti menerima email dari grup ini, kirim email ke scrum-indones...@googlegroups.com.
Untuk opsi lebih lanjut, kunjungi https://groups.google.com/d/optout.

[Tito Sigilipoe]

Salam kenal Pak Ivan,

Saya masih awam Pak soal perbedaan waterfall atau bukan.

Dasar saya menyebut waterfall mengutip dari sini:

http://www.cognitivedesignsolutions.com/Instruction/ADDIE.htm

Model proses ADDIE-nya terlampir.

Open to discuss Pak. 

Kebetulan belum ada kesempatan cerita banyak, kelak akan saya ceritakan tantangan-tantangan yang saya hadapi dengan model ini.

[Ivan Darmawan]

Hebat kalau bisa murni waterfall. Kebanyakan sih cuma di atas kertas waterfallnya, namun prakteknya pake metode hajar-bleh :)

Regards,
Ivan Darmawan

[Tito Centrinova]

Metode hajar bleh itu bagaimana Pak?

Ada beberapa hal yang bikin ISD ADDIE ini tidak sesuai plan, faktor yang sering saya temui adalah requirements dari klien yang berubah-ubah.

Kalau sudah begitu, bisa hujan revisi di tahap akhir.

Sementara tim saya tampaknya skeptis bila harus membuat prototype berulang-ulang. 

Kapan akan ada gathering lagi, Pak? Mohon bimbingannya.

--
Anda menerima pesan ini karena berlangganan topik dalam grup "Scrum Indonesia Community" di Google Grup.
Untuk berhenti berlangganan topik ini, kunjungi https://groups.google.com/d/topic/scrum-indonesia/a10NGWZoqQ0/unsubscribe.
Untuk berhenti berlangganan grup ini dan semua topiknya, kirim email ke scrum-indones...@googlegroups.com.

Untuk opsi lebih lanjut, kunjungi https://groups.google.com/d/optout.

--

Tito Sigilipoe
Instructional Designer
PT Centrinova Solusi Edukasi
021-53150501
www.centrinova.com

[iwan teguh santoso]

Pak tito
Pertanyaan kenapa requirment berubah2 ?  Seharusnya khan disepakati dr awal ..jika ada perubahan requirment maka akan dilaksanakan setelah requitment awal selesai semua .


Thx

Sent from my Windows Phone

---

From: Tito Centrinova
Sent: ‎16/‎02/‎2015 16:27
To: scrum-i...@googlegroups.com
Subject: Re: [scrum-indonesia] Salam kenal dari Tito

[Tito Centrinova]

Pak Iwan,

Penjelasannya kurang lebih seperti berikut Pak:

What causes so many revisions in e-learning projects? While there may be countless explanations to why people offer revisions to e-learning, I propose there are four basic reasons:

1. Lack of serious review of a previous deliverable. If you were to ask me, this is the number one reason for revisions, especially late in a project. One of the biggest dangers in an iterative process is when project team members assume that issues in early deliverables (Alpha, Beta) can be fixed later. This leads team members to half-heartedly review the deliverable. If deliverables aren’t reviewed seriously by everyone, down-line revisions are almost guaranteed.
2. Fear the deliverable will not meet expectations – and usually of a stakeholder outside the core project team. If someone fears that the deliverables are just not good enough for that manager or superior who will review it later, revisions continue to be requested.
3. Late review by an unknown stakeholder. When someone swoops in at the last minute (“seagulls”) and reviews the course without a clear understanding of the team’s intentions, a large number of serious revisions are likely.
4. Lack of commitment. This type of revision happens frequently at the Gold deliverable. This is the final review of the course and the time when anxieties increase. “Let’s just make one more pass at the content” is a common indicator that someone is reluctant to commit to the course. This person (or persons) probably demonstrated some of this earlier in the project, but not to the degree that they do at the final deliverable.

Penjelasan di atas saya ambil dari http://info.alleninteractions.com/bid/89207/A-Purposeful-Change-to-Your-e-Learning-Projects, yang mempelopori model instructional system development bernama SAM (Succesive Approximation Model),yang juga sebenarnya diadopsi dari model Agile. Ini juga yang memotivasi saya mencari penggiat Agile dan Scrum di Indonesia

Saya merancang konten e-learning, Pak. Gambarannya, pekerjaan saya mengkonversi training tatap muka dengan multimedia interaktif (atau blended, gabungan keduanya).

E-learning ini barang baru, di mana sebagian besar pihak klien belum paham seperti apa visualisasi, animasi dan interaktivitas dari konten yang akan didevelop. Selama ini masukan-masukan berharga baru terjadi ketika produk di tahap alpha.

Pada 16 Februari 2015 16.29, iwan teguh santoso <isan...@outlook.co.id> menulis:

Pak tito
Pertanyaan kenapa requirment berubah2 ?  Seharusnya khan disepakati dr awal ..jika ada perubahan requirment maka akan dilaksanakan setelah requitment awal selesai semua .


Thx

Sent from my Windows Phone

---

From: Tito Centrinova
Sent: 16/02/2015 16:27

[Tito Centrinova]

Maaf, jika ingin melihat contoh development model ADDIE-nya bisa dicek di video berikut:

https://www.youtube.com/watch?v=WURExEwxU2M

[T. Budiman]

Yang itu kan alasan-alasan perubahan requirements dari pengalaman orang lain. Walau itu bisa dijadikan referensi, jauh lebih penting untuk mengetahui alasan-alasan yang benar-benar terjadi pada team dan klien yang dialami.

Untuk pekerjaan di mana "visualisasi, animasi dan interaktivitas" adalah elemen yang penting, bentuk requirements-nya juga penting. Besar sekali kemungkinan review requirements tidak mungkin dilakukan dengan efektif kalau tidak bisa merepresentasikan "visualisasi, animasi dan interaktivitas" yang dimaksud.

[Tito Centrinova]

Pak T.Budiman, 

Betul, Pak. Yang jadi masalah memang REPRESENTASI-nya. Terima kasih pencerahannya.

Menurut saya, semakin REPRESENTASI-nya mirip produk akhir, maka semakin mudah di-review oleh reviewer.Reviewnya pun bisa lebih serius.

Representasi visual ini di IT, bisa dituangkan dalam prototype, wireframe atau mockups. Tolong dikoreksi bila ini salah.

Prosedur yang saat ini kami terapkan mungkin kurang representatif bagi klien/reviewer sejak awal.

Kami masih menggunakan dokumen berbasis teks (berisi outline, storyboard) untuk di-review. Dokumen-dokumen seperti ini membosankan bagi reviewer, yang berakibat proses review kurang serius, karena dokumen tersebut kurang REPRESENTATIF. Reviewer dari klien kami yang sudah membaca pola kerja kami lebih suka menunggu sampai tahap di mana pekerjaan kami sudah dalam format visual. Di sinilah biasanya muncul requirement-requirement baru, karena yang tadinya belum tervisualisasi sekarang sudah bisa dilihat dan direview.

Solusinya kalau menurut saya adalah prototyping, tapi jadi mengubah model kerja yang ada...

Bagaimana pendapat bapak-bapak?

[rizky kurniawan]

Ijin nimbrung Pak Tito,

 Saya juga pendatang baru kebetulan salam kenal hehe :D, jika ditempat kami biasanya gather req oleh analis diterjemahkan sampai bentuk mockup sehingga keseluruhan fitur sudah bisa kita sajikan meskipun tanpa action, jadi sudah bisa menggambarkan bagaimana kira2 alur dari aplikasi hingga peletakan posisi tombol dan berbagai fitur yang akan muncul di tiap form, Jika sudah jadi mockup akan kami demokan ke client, kami akan mulai menjelaskan bagaimana cara aplikasi bekerja dan fitur apa saja yang ada di dalam nya, biasanya sih mereka memang kebanyakan iya2 saja di depan ( krn memang biasanya ledakan informasi ada pada fase development ) untuk mengunci kesepakatan tersebut mockup harus di ttd oleh pihak yang berwajib :D dari sisi client dan kita. 

Jika telah disepakati mockup di berikan ke temen2 developer untuk mulai mendevelop, kami akan coba bagi menjadi bbrp deliverable agar client juga bisa merasakan progres pengerjaan kita. Untuk perubahan req setelah proses development akan kami perlakukan sebagai change req, change req ini juga akan menimbulkan bbrp konsekuesi baik dana waktu or else, ini juga penting untuk disepakati bersama jika masih ada yg belum acc jangan pernah dikerjakan krn akan hanya jadi kerjaan tanpa penghargaan :D

Untuk pemilihan metode prototyping kami pernah mencoba menggunakan untuk mempercepat penyempurnaan requirement, tapi dokumentasi harus bagus :D, tahapan tetap harus dibuat kesepakatan awal req sampe ke req yang sempurna baru ke riil development produk. Proses penyempurnaan req itu juga harus di biayakan sangat2 PENTING dokumentasi pergerakan requirement dan brp biaya + waktu yang disepakati harus clear di depan jika tidak akan bner2 ribet dibelakang :D

Mungkin cmn ini yang pernah kami lakukan mohon maaf jika ada byk kekurangan ... dan ditunggu gather feb nya :D mau banyak denger tentang scrum heheh

[Tito Centrinova]

Pak RIzki,

Istilahnya bagus: "Ledakan Informasi" :D. kurang lebih seperti itu yang dialami tim kami.

Penjelasan Bapak mengenai mockup bisa saya bayangkan. Begitu pula dengan mengunci atau signoff mockup-mockup tersebut oleh stakeholder yang tepat. Saya setuju mengenai memecah proses menjadi beberapa deliverable.

Terima kasih, masukan-masukan di sini sangat berharga. Ditunggu info gathering Februari juga. 

--

Anda menerima pesan ini karena berlangganan grup "Scrum Indonesia Community" di Google Grup.
Untuk berhenti berlangganan dan berhenti menerima email dari grup ini, kirim email ke scrum-indones...@googlegroups.com.
Untuk opsi lebih lanjut, kunjungi https://groups.google.com/d/optout.

--

[Hendri Arifin]

Salam kenal juga, saya juga baru join. Hendri di BSD

Regards,

Hendri

[Tito Centrinova]

Salam kenal Pak Hendri Arifin, kantor saya juga di BSD Serpong.

--

[Hendri Arifin]

Wah boleh Pak Tito, kapan2 Ngopi2 darat, btw, untuk permulaan buat kita yg beginner kayanya bagus nih, presentasi mengenai Scrum oleh Pak Rizky Syaiful, di http://scrum-indonesia.org/apa-itu-scrum, dengan Judul: Scrum 101: Bahkan Nenek Saya Bisa Ngerti.

Regards,

Hendri

--

Best Regards,

Hendri Arifin

[Irwansyah Irwansyah]

Ada link bagus, dari judulnya kelihatan negatif tapi isinya sangat mencerahkan: http://gilesbowkett.blogspot.com.au/2014/09/why-scrum-should-basically-just-die-in.html

[Rizky Syaiful]

Bang Irwan, satu-satunya yang saya benar-benar pertanyakan argumennya hanyalah yang :

"programmer kok ga boleh dibilang orang bisnis.... semua programmer itu orang bisnis, harus bisa marketing."

Si Giles menurut saya salah tangkap. Ini bukan tentang kemampuan marketing produk sendiri.

Yang dimaksud Agile Manifesto sebagai orang bisnis adalah "pihak (yang mewakilkan) yang butuh software". "business people and developers must work together." <- kalau di XP itu anjuran bahwa developer kalau bisa satu gedung sama yg make software.

+++++++

Mungkin Bang Irwan kaget, saya setuju kok sama sisanya.

Fenomenanya juga saya lihat semua kok. Sayang Bang Giles kurang baca aja:

• Planning Poker di luar Scrum
  
  
• Daily Scrum dilarang saling menimpali (rapat) -- tapi saya juga setuju yang paragraf diawali dengan "To be fair to Scrum...". Scrum implementation often breaks.
  
  
• Velocity di luar Scrum
  
  
• Spotify udah ga (bilang) lagi mereka pake Scrum.
  

Lain kali cari artikel yang lebih bagus bang.

( Silahkan kalau siapapun mau Scrum-bashing di sini, saya mendukung kebebasan berbicara. Saya bukan Scrum-basher, tapi kebetulan juga anti Scrum-worshipping )

FYI, buat yang baru datang ke sini, bang Irwan ini peduli banget sama software development, passion-nya yang tinggi amat inspiratif, silahkan telusuri diskusi2 beliau sebelumnya.

++++++++

Fenomena tulisan Giles (dan Irwansyah di milis ini) ini dibahas di buku saya. Berikut beberapa skrinsut.

///////

////////

+++++++++++++

Saya dan Bang Irwan ini sama-sama punya kepedulian yang tinggi dengan software development (setidaknya klaim kami begitu).

Sayang Bang Irwan (dan Om Giles di Aussie) ga tahu Scrum itu apa. Kecampur2 yang di dalem sama di luar Scrum Guide.

Supaya ga gini2 lagi. Saya sarankan Bang Irwan beli buku saya.

Inprogress lagi bukunya. Sekarang bertambah jadi 150 halaman. Saya memutuskan menambah banyak esai2 pendamping. Supaya miskom-miskom seperti ini jadi minimal. Supaya orang-orang yang baru denger2 tetang Scrum & agile jadi punya pegangan yang lebih kuat.

Semoga kita semua selalu terhindar dari sentimen. Baik itu negatif maupun positif.

With respect, positive thinking, and :)

Rizky Syaiful about.me/rizkysyaiful

~ http://rizkysyaiful.com

~ http://linkedin.com/in/rizkysyaiful

[Tito Centrinova]

Terima kasih Pak Irwan dan Pak Rizky, atas resource dan screenshotnya, jadi tambah wawasan.

--

Anda menerima pesan ini karena berlangganan topik dalam grup "Scrum Indonesia Community" di Google Grup.
Untuk berhenti berlangganan topik ini, kunjungi https://groups.google.com/d/topic/scrum-indonesia/a10NGWZoqQ0/unsubscribe.

Untuk berhenti berlangganan grup ini dan semua topiknya, kirim email ke scrum-indones...@googlegroups.com.

Untuk opsi lebih lanjut, kunjungi https://groups.google.com/d/optout.

--

[buyung bahari]

Salam kenal, Saya Buyung dari BSD. Satu kantor sama Pak Hendri. Jadi tambah wawasan, yang diberikan Pak Irwan dan Pak Rizky,

Thanks

Buyung Bahari

[Tito Centrinova]

Waw, Pak Buyung dan Pak Hendri, 

saya juga di BSD di Ruko Golden Boulevard. Salam kenal.