Sepertinya perdebatan software house mana yang implement agile itu nggak terlalu penting untuk saya pribadi sih. Karena hanya dengan membaca Scrum, kanban, lean dan agile terbukalah perspektif baru di pikiran saya tentang gimana sebuah software development team itu seharusnya dibentuk dan bekerja.

Di scrum, keywordnya adalah "self managed team" dimana setiap tim di dalam scrum dapat mendevelop aplikasi sesuai kecepatan tim tersebut, naah bayangkan fun-nya kerja di tim seperti ini: nggak lembur nggak dikejar2 deadline wew, holy grailnya developer tho? hal ini dimungkinkan dengan adanya sistem pull kerjaan bukanya push. Sekarang coba deh lihat kerjaan masing2, semuanya dipush kan? mau featurenya mau estimasi kapan selesainya semuanya dipaksa dengan adanya gant-chart. Kadang2 PM yang konyol suka bilang "pokoknya besok harus jadi", wew.

Project owner di scrum diberi kekuasaan untuk menentukan feature apa yang akan dikerjakan dalam satu sprint, diurutkan berdasarkan feature yang paling banyak memberikan "bussiness value" terhadap aplikasi di mata kepada konsumen. Kemudian programmer akan menentukan task apa saja yang akan dilakukan dan estimasinya. Project owner ga boleh turut campur menentukan estimasi ini, apa artinya? artinya adalah programmer bekerja sesuai kecepatanya dan bisa mengasumsikan bahwa jam kerja adalah jam 9-18. cool tho? :D

Project owner kemudian harus memilih mana saja feature yang akan diimplementasikan agar bisa memenuhi kontrak ke customer. Setiap sprint berakhir ada yang namanya retrospektif, semua orang berkumpul dan memberikan saran. Coba deh dipikir2, kapan sesekalinya programmer bisa ketemu sama semua pihak dalam project? jarang kan, nah di scrum ini diwajibkan di awal dan akhir sprint.

Hal yang terpenting kemudian adalah transparansi antar semua pihak yang terlibat, programmer bisa aja bilang sama manager perusahaan kalau internetnya lemot ga bisa cari informasi dengan cepat, atau PCnya dah outdated karena layar cembung dan bikin sakit mata, atau hal2 yang lebih spesifik ke project misalnya informasi tentang rumus tertentu belum tersedia. Transparansi ini bisa didaftar dan disampaikan ke stakeholder setiap hari, karena ada daily scrum meeting. Jadi masalah2 nggak muncul meledak di satu waktu. Daily scrum meeting juga berfungsi untuk memberikan kesan demokratis ke dalam tim, kenapa? karena anggota tim melaporkan apa yang dilakukan kemaren dan hari ini ke anggota tim lain, bukan ke "boss".

Wah masih banyak deh inspirasi dari belajar Scrum, kanban, agile dan lean management. ;)

Agile adalah metologi yang menarik buat saya karena sekilas sejauh yang saya coba pahami, satu poin pentingnya adalah efisiensi, yang disini mas ronald bilang mengurangi sampah. Tapi seperti udah mas ronald singgung, siap gag sih kita ngeadopsi ini??
Di indonesia saya lihat ini mungkin akan lebih cocok di adopsi oleh sebuah in house development team. tapi lagi-lagi pertanyaan besarnya apakah mereka siap mengadopsinya?
CMIIW
Ditunggu banget lanjutannya mas...

http://waroengvb.net

Kalo di kuliah rpl-ku masih belajar metode waterfall,spiral dll.
Terus pernah waktu masuk kuliah manajeme proyek, kita disuruh bikin proporal proyek, terus ditanyain dosennya, "Lalu kalian mau ngecharge klien berdasarkan apa? Termin #`1, analisa & desain sudah dilaksanakan? mana mau klien?"

btw, iya neh kok tumben podcastnya pendek banget,
aku tertarik ama method ini, software house di indonesia ada yg pake metode ini gak ya?
pengalaman ama beberapa software house cenderung programmer is superman, analis iya, ngoding iya, dokumentator iya, customer support iya.
kalo pun programmer > 1, gak ada namanya pair progamming, si A garap modul 1, si B garap modul 2.

cara nge-bill bukan sesuatu yang biasanya aku harus urusin sehari2. Ini biasanya urusannya sales dan para account manager. Tapi biasanya agile itu cocoknya digabungin sama time and material.
Jadi lebih mirip staff augmentation. Yang dijual adalah resources per sprint.

itu lah yang bikin agile lebih jarang di adopt, apalagi buat konsultan. karena bisnis cenderung pengen tau berapa duit dan apa yang dibikin di depan melalui analisa, desain dan proposal. sedangkan di agile, visi ke depannya tidak jauh (untuk supaya ga mubazir itu).

aku juga cukup tertarik nih buat mencari software house di indonesia yang pake agile. kalo ada rekmendasi, pengen nih diajak ngobrol.

wew, pas banget, saya baru nyoba implementasiin agile buat pengembangan software saya. sebelumnya saya lebih suka pakai tipe pengembangan prediktif kayak spiral, cuma waktu ntu ternyata ada perubahan pasar dan teknologi akhirnya design yang udah saya capek buat-buat gak bisa dipake lagi, sayang kalo dipaksa.

Saya juga baru ngepost artikel tentang agile di http://bit.ly/8T1DTE, mungkin mas ronald bisa cek en kasih feedback kalo ada kesalahan pemahaman saya.

Tapi sayang podcast kali nie kok sebentar amat hehe, pengen saya sedot nie ilmu agile-nya bro ronald hehe.

Firman, tulisan yang bagus. Aku akan masukin show notesnya teman macet juga ya untuk referensi. Komennya aku cross post ke teman macet juga untuk memungkinkan para ttm untuk berdiskusi lebih lanjut.

Sesuatu yang aku kurang setuju adalah dengan list kekurangannya. di point kedua dan ketiga kamu mengatakan bahwa agile meningkatkan resiko kesalahan teknis dan proses yang kurang terorganisir. Aku ingin menanggapi sedikit kedua point tersebut.

Agile justru mengurangi resiko kesalahan teknis dengan adanya komunikasi antar developer dan juga dengan stakeholder. Setiap developer juga berkerja dengan user stories yang akibatnya, banyak developer yang menyentuh code satu sama lain. Ini memiliki efek positif, karena secara natural kode akan di-review satu sama lain dan secara konstan ter-refaktor.

Agile justru menurut aku lebih teroganisir dan disiplin dari metodologi pada umumnya. Di setiap saat, stakeholder/scrummaster(xp coach) bisa melihat burn down chart/velocity untuk melihat produktivitas team, melihat progress user story yang sudah ditutup dan sedang dilaksanakan. The lack of gannt chart, maupun UML tidak harus berarti projeknya 'kurang' terorganisir. Toolingnya aja yang beda.

hmmm.... masukan yang bagus.
Sebagai orang yang dulu mengutamakan dokumen design, saya melihat bahwa tidak digunakannya beberapa dokumen yang digunakan di metode pengembangan prediktif nantinya akan membuat pengembangan akan sedikit terganggu. Ditambah dengan opini-opini yang saya temukan di beberapa artikel bahwa agile agak kurang terorganisir oleh karena itu saya masukkan ke dalam daftar kekurangan.
2 poin terakhir kekurangan agile di artikel tersebut saat ini sedang saya dalami lebih lanjut terlebih dahulu.

wew, pas banget, saya baru nyoba implementasiin agile buat pengembangan software saya. sebelumnya saya lebih suka pakai tipe pengembangan prediktif kayak spiral, cuma waktu ntu ternyata ada perubahan pasar dan teknologi akhirnya design yang udah saya capek buat-buat gak bisa dipake lagi, sayang kalo dipaksa.

Saya juga baru ngepost artikel tentang agile di http://bit.ly/8T1DTE, mungkin mas ronald bisa cek en kasih feedback kalo ada kesalahan pemahaman saya.

Tapi sayang podcast kali nie kok sebentar amat hehe, pengen saya sedot nie ilmu agile-nya bro ronald hehe.

wah ini pelajaran kuliah RPL dulu neh.aq dapat nilai C kalau ga salah.hehe...

my_blog