By
Agile Development

Lanjutan dari tulisan Kesalahan Populer saat Menulis Scrum di Proposal. 1. Kelebihan Scrum dibanding Cara Konvensional "Apa untungnya buat saya?" Pembaca proposal bisa jadi belum tahu Scrum, atau bahkan, punya pandangan buruk. Buka proposal dengan keunggulan Scrum, sehingga mereka makin tertarik membaca. 2. Otoritas Penuh Product Owner dalam Arah Produk & Riset Pengguna Salah satu konsep paling revolusioner di Agile Software Developement adalah keberadaan Product Owner / Product Manager. Di manajemen konvensional ada Project Manager. Tanggung jawabnya hanya memastikan inisiatif pimpinan dieksekusi dengan baik sesuai rencana. Terlihat perannya berbeda sekali dengan Product Owner. Di sisi lain, janji Scrum adalah nilai manfaat produk yang setinggi-tingginya. Kuncinya, juga ada di peran Product Owner. Maka, pastikan perannya dijelaskan dengan baik & ringkas di awal. Pro tips: Cantumkan nama orang yang diproyeksikan mengisi peran Product Owner. Ini akan memudahkan pembaca membayangkan implementasi. Jika hubungannya adalah klien-vendor, usahakan Product Owner ada di sisi

By
Agile Development

Tulisan ini akan membantu Anda menyelamatkan proyek/inisiatif Anda—mulai dari proposalnya. Sepengamatan saya, banyak implementasi Scrum yang sudah bermasalah sejak dalam kandungan. Um, maksudnya, sejak dalam proposal. Kita semua tahu, baik di hubungan kerja klien-vendor eksternal ataupun lintas divisi internal, semua inisiatif dimulai dari proposal. Proposal memicu pembahasan proses kerja (baca: cara berkomunikasi & berkoordinasi). Semua pihak berdiskusi mencari win-win solution. Hingga akhirnya disahkan di kontrak kerja. Scrum sendiri—sebagaimana sebuah proses kerja—tentu harus dibahas & disepakati implementasinya di awal. Berikut dua kesalahan populer saat menjelaskan Scrum di proposal—dilanjutkan dengan solusinya. 1. Tidak Detail Karena Berasumsi Semua Orang Membaca Scrum Guide Bila melihat proposal yang bagian metode kerjanya hanya berisi: Pernyataan bahwa pengembangan akan memakai Scrum, Definisi Scrum yang dikutip dari Scrum Guide: "Scrum (kb): Sebuah kerangka kerja dimana orang-orang dapat mengatasi masalah kompleks adaptif, dimana

By
Agile Development, Software Engineering

Navigasi esai: Intro & Pilar 1 | Pilar 2 | Pilar 3 (bagian 1) | Pilar 3 (bagian 2) (Sambungan dari bagian 1) Navigasi poin masalah: l) Pengetahuan yang Kurang Tersebar m) Banyak Gangguan saat Berkerja n) Developer Masih Dicekoki Deadline Masalah l: Pengetahuan Kurang Tersebar "Ingin memperlambat jalannya pengembangan? Gampang. Tambahkan saja programmer baru." Orang IT tentu familiar dengan pernyataan di atas. Berbeda dengan pekerja pembangun rumah, menambah developer tidak akan langsung meningkatkan kecepatan pengembangan. Kenapa? Karena ada jauh lebih banyak pengetahuan yang perlu diserap oleh developer baru, dibanding tukang bangunan baru. Mulai dari sisi bisnis produk, arsitektur software, gaya menulis kode, teknologi-teknologi baru, workflow tim, bingkai kerja tim, sampai tentunya, basis kode software. Kecil kemungkinan ada satu orang di tim, yang bisa mengajarkan seluruh basis kode software. Biasanya, si anak baru perlu bertanya ke beberapa orang. Pengetahuan untuk mengerjakan software tersebar di banyak kepala. Tidak ada mandor yang

By
Agile Development, Agile Operational

Saya mungkin tidak berbeda dengan anda, dibesarkan dalam budaya keluarga yang serba sungkan untuk menyampaikan sesuatu tapi di lain waktu bisa dengan mudah mengeluarkan sumpah serapah hanya untuk urusan kesalahan sepele. Saya begitu terlatih menyimpan semua emosi negatif, terlihat penurut kepada orang yang saya lihat sebagai superior lalu melampiaskan semua kekesalan yang tertahan kepada pihak yang bisa saya jadikan keset (baca: inferior). Setiap kali saya merasa diperlakukan tidak adil dan saya terlalu takut untuk menyampaikan apa yang saya rasakan dengan alasan takut durhaka atau takut dianggap baper, saya pikir solusinya adalah berdoa. Tak lupa menitipkan pesan kepada Tuhan agar menjadi hakim yang seadil-adilnya. Namun akhirnya saya menyadari, mengapa apa-apa Tuhan saya seret-seret untuk campur tangan? Lah wong yang perlu terus memperbaiki cara berkomunikasi itu saya koq. Saya jadi tidak beda jauh dengan anak kecil manja yang setiap kali kecewa tidak bisa bermain dengan

By
Agile Development, Software Engineering

Navigasi esai: Intro & Pilar 1 | Pilar 2 | Pilar 3 (bagian 1) | Pilar 3 (bagian 2) Jika hanya membaca pilar 1 & pilar 2, programmer pemula pasti langsung khawatir, "kalau requirement bisa berubah drastis—apalagi dipaksa rilis setiap minggu—pasti fase testing dikorbankan. Kode juga jadi berantakan. Agile ini lebih neraka dari waterfall." ~ seorang programmer pemula Mereka tahu 3 bulan lagi, kode program mereka sendiri akan seperti sphagetti. Cukup berantakan hingga mereka kesulitan menulis kode fitur baru. Mereka tahu akan dibangunkan tengah malam, karena harus memperbaiki bug fitur pembayaran yang merugikan kas perusahaan. Jangan sampai ketangkasan Agile Software Development justru membuat perusahaan rugi milyaran rupiah, karena bug yang krusial, serta penurunan performa developer. Lebih-lebih, membuat developer mengundurkan diri. Ingat pilar 1? Makin lambat tim developer berkerja, makin sulit untuk tangkas. Untuk itu, Agile Software Development butuh pilar ketiga. Pilar yang umumnya diketahui & dikuasai programmer tingkat ahli. Pilar 3: Kualitas Teknis yang