Pilar Ketiga Agile Software Development: Kualitas Teknis yang Tinggi & Terjaga (bag. 2)

Navigasi esai: Intro & Pilar 1 | Pilar 2 | Pilar 3 (bagian 1) | Pilar 3 (bagian 2)


(Sambungan dari bagian 1)

Navigasi poin masalah:

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 tahu kondisi semua pekerjaan, secara detail, setiap saat. Mereka mengetik di belakang layar, bukan tukang bangunan yang pekerjaannya terlihat jelas.

Selain masif, pengetahuan dalam pengerjaan software juga amat dinamis—karena selalu mengerjakan hal baru. Fitur baru, teknologi baru, teknik baru, adalah makanan sehari-hari developer.

Dengan segala kondisi tersebut, kita bisa duga, potensi miskomunikasi antar-developer amat besar. Artinya, makin besar peluang melesetnya estimasi mereka di awal.

Solusi:

  • Lakukan daily standup secara konsisten. Dalam maksimal 15 menit setiap hari, semua anggota tim developer memahami kondisi seluruh anggota lain. Apa yang masing-masing sudah kerjakan, kendala apa yang ditemukan, rencana pekerjaan 24 jam ke depan. Agar efektif & tidak membosankan, haramkan membahas masalah—tunggu sampai daily standup ditutup dan forum dibubarkan.
  • Praktikkan pair programming di saat-saat yang butuh lebih dari satu kepala (bug fixing, analisis di awal, dsb).1
  • Jika ada yang merasa problemnya cukup krusial untuk diketahui semua developer, ajukan sesi mob programming ke tim.
  • Buat coding convention, juga jangan lupa masukkan aturan-aturan yang menyebarkan pengetahuan ke pembaca kode (contoh: komentar di kode, fungsi, & kelas). Jangan terima pekerjaan developer sebelum mereka menaati aturan-aturan code convention.
  • Pastikan curhatan-curhatan tentang miskomunikasi & pengetahuan tim terangkat di sesi retrospektif.

Masalah m: Banyak Gangguan saat Berkerja

Semua developer tahu, tidak enaknya diganggu saat asyik berpikir. Pernah menggerutu seperti ini?

  • “Kenapa sih, kalau ada yang ulang tahun semua harus ikut ngumpul. Kalau memang sudah budaya, di luar jam kerja dong!”
  • “Duh, lupa lagi mengerjakan apa. Sebelum si Jonathan minta bantuan terkait bug-nya dia..”

Ini yang lebih parah:

  • “Arrggghh… meeting dadakan lagi?!”

Rapat menghabiskan waktu 30 menit, minimal. Dan 30 menit itu cukup untuk menguras otak dari kode-kode yang sedang kita kerjakan. Untuk kembali fokus berkerja setelah rapat, biasanya butuh 15 menit. Lebih jelasnya: 15 menit yang tanpa gangguan. Sayangnya, sehabis rapat energi sering kali sudah habis & butuh istirahat.

Tanpa gangguan luar saja, pekerjaan teknis developer sudah banyak hal-hal tidak terduga. Apalagi dengan gangguan luar. Ini salah satu alasan, kenapa lama pengembangan software itu relatif sulit diestimasi dengan akurat.

Solusi:

  • Gunakan bingkai kerja yang meminimalisir rapat yang mendadak & bertele-tele. (Scrum, Kanban, XP)
  • Edukasi seluruh pihak di organisasi, tentang pentingnya fokus bagi developer. Kumpulkan semua anggota organisasi, buat kesepakatan akan bagaimana berkomunikasi dengan developer (secara langsung maupun digital)
  • Pastikan ada satu orang di tim yang berfungsi sebagai pelindung. Pihak luar yang ada perlu dengan developer di jam kerja, harus berkoordinasi dulu dengan pelindung ini.
  • Buka wawasan tim terhadap trik-trik untuk fokus berkerja (Hackernoon, Quora). Bahas di level tim, biarkan terangkat sebagai eksperimen perbaikan di retrospektif. Bahas pula di level organisasi jika diperlukan.
  • Buat tim menghitung nilai E Factor mereka sendiri setiap hari (rumus: jam fokus berkerja / jam berada di kantor). Gunakan itu sebagai metrik untuk ditinjau terus di setiap retrospektif. Tips: jangan biarkan manajemen mengetahui angkanya, sehingga mereka tetap jujur dalam menghitungnya.

Masalah n: Developer Masih Dicekoki Deadline

Nama lain masalah ini: “tidak adanya otonomi dalam mengestimasi lama pekerjaan”.

atau, “deadline-driven development

Deadline-driven development: adalah kondisi ketika manajemen percaya, satu-satunya cara untuk meningkatkan produktifitas developer, adalah dengan memberikan mereka deadline yang asal & tidak realistis. Selalu tantang developer untuk berkerja lebih cepat dari kondisi sekarang.

Berikut pembenaran manajer macam ini: “Ah, developer kan suka tantangan”. Betul. Tapi deadline sepihak bukanlah tantangan. Developer yang bekerja tidak bisa disamakan dengan atlet sprint yang berlari. Ada jauh lebih banyak faktor X yang mempengaruhi lama & keberhasilan. Jadi, tidak bisa sekedar ‘ditantang’.

Versi lain yang lebih halus adalah “estimasi yang jadi deadline”. Developer ditanya estimasi, tapi setelah itu dijadikan deadline—yang pada akhirnya memaksa lembur jadi rutinitas. Padahal secara arti kata saja ‘estimasi’ dan ‘deadline’ sudah jelas berbeda. ‘Estimasi’ adalah ‘perkiraan’, ‘deadline’ adalah ‘kepastian’. Lebih halus, tapi tetap bermasalah karena lembur jadi rutinitas.

Kenapa fenomena ini banyak terjadi? Sebenarnya, yang semua manajemen & pihak bisnis butuhkan itu hanya dua. Dan keduanya amat wajar:

  1. Estimasi yang akurat, sehingga bisa mudah berkoordinasi dengan pihak luar—investor, calon klien, tim marketing.
  2. Etos kerja tim developer yang sesuai ekspektasi, sehingga tidak merasa dicurangi setelah membayar penuh gaji tim developer.

Sayangnya, di lapangan, tidak sedikit developer yang etos kerjanya tidak bagus—mungkin karena punya pengalaman buruk dengan manajemen & klien.

Dari situ, bisa ditarik beberapa kemungkinan solusi dari sisi pihak manajemen.

Solusi:

  1. Buat perjanjian kerja yang jelas dengan developer: jam masuk, jam keluar, berapa lama harus fokus kerja di setiap hari, kapan saja bisa istirahat. Hargai perjanjiannya.
  2. Masukan transparansi dalam perjanjian kerja tersebut. Buat status & tren pekerjaan tim developer dapat terlihat oleh semua orang (kanban board, task burndown chart). Rutin inspeksi mereka secara mendadak.
  3. Gunakan bingkai kerja yang iterasinya singkat, sehingga estimasi makin akurat. (lihat juga solusi masalah a di pilar pertama demi estimasi yang lebih akurat)
  4. Tanya estimasi mereka & hargai itu. Jangan coba lobi—apalagi memaksa. Jika punya target bisnis, diskusikan dan coba cari solusi bersama mereka. (contoh: rekrut orang baru, outsource, lembur, atau turunkan ekspektasi).
  5. Sering berkoordinasi dengan mereka di tengah pengembangan, sehingga ekspektasi dari sisi bisnis tetap terjaga.
  6. Bantu hilangkan semua penghambat & tingkatkan kemampuan teknis mereka.

Masalah i, j, k, l, m, & n di atas hanyalah beberapa contoh. Terpikir masalah lain yang menghambat pengembangan di jangka panjang? Atau punya pengalaman pribadi? Tulis kotak komentar di bawah ya… 🙂

  1. Ternyata total biaya gaji akibat pair programming bukan meningkat dua kali lipat, melainkan hanya 15%. Dan itu amat murah untuk membayar manfaat-manfaatnya. Lebih lanjut bisa dibaca di paper berikut.

Product Manager dari Learn.AgileCampus.org

Ada pertanyaan atau pendapat?