Ada beberapa kebiasaan dalam proses pengembangan aplikasi yang dapat merusak keharmonisan tim
Terjebak dalam dikotomi bukan bagian programmer
Programmer bukan sekedar juru ketik yang mentranformasikan ide bisnis ke baris kode. Profesi ini juga memiliki beberapa peranan:
Memiliki pemahaman dalam logika (konsep) bisnis, basis data(database), integrasi. Bahkan programmer pun harus melakukan proses pengetesan (walau tidak mengesampingkan bagian tester), setidaknya melalui unit test dan integrasi tes. Perlu ditekankan kita tidak perlu ahli 100% dalam aspek di wilayah luar programming seperti Product Owner atau Quality Assurance, tapi yang dibutuhkan adalah gambaran besar dari lingkup diluar koding (T-shaped).
Selain itu terutama dalam scrum, developer juga bertindak sebagai bos atas dirinya sendiri, sebab:
- bos tidak selalu mengawasi, &
- bos seharusnya tidak melakukan mikro manajemen
Selayaknya programmer berkarya sebagai ilmuwan yang melakukan penyampaian usul/saran, membuat kerangka hipotesa, melakukan tes, meriset dan membuat keputusan berdasarkan fakta yang tersedia.
Gampang menyalahkan
blamming driven design
Terdapat dua tipe karakterisik dalam sikap ini:
Menyalahkan user
- Pengembangan perangkat lunak pada dasarnya adalah bagian dari proses untuk menghasilkan layanan / produk kepada perusahaan (outsource) atau pelanggan (user). Terdapat beberapa alasan yang sering muncul ke permukaan ketika produk tidak berjalan seperti:
- si A tidak tahu alur yang harus dijalankan
- si B harusnya mengklik tombol ujung bawah dulu kemudian simpan, atau tombol kirim tidak boleh diklik berulang
- si C harusnya tidak boleh mengisi nilai negatif atau kosong
Pada dasarnya, menyalahkan pengguna tidak membuat masalah terselesaikan, salahkan kebutuhan (requirement) yang tidak bisa mengetahui karakteristik pengguna. Sebab pengguna lah dasar dari layanan / produk kita bisa berjalan
Bagaimana untuk mengatasinya:
Data driven design.
Dapat menggunakan metode survey pada beberapa pengguna dan mendapat umpan balik saran.
Serta bisa pula menggunakan alat bantu analisis seperti hotjar/google analytic untuk mengetahui tingkah laku pengguna dalam menggunakan aplikasi
Menyalahkan rekan kerja
Menyalahkan rekan kerja dapat membuat mental seseorang jatuh alih-alih untuk memberikan contoh yang baik. Apabila ingin memberikan perbaikan lakukan melalui:
Lakukan dalam Pull Request, apabila menemui ketidak setujuan:
- Berikan pendapat konstruktif seperti `Lebih baik gunakan cara A daripada B sebab proses nya lebih cepat sekian kali`, ‘atau kode ini berpotensi akan menimbulkan bug bila ada input yang belum dijaga’
- Hilangkan kata ‘kenapa / mengapa’. Lebih diterima mana:
- Kenapa fungsi ini punya 100 baris kode?
dibandingkan
- Kalau fungsi ini dipisah ke beberapa fungsi kecil ini akan lebih mudah dibaca dan di-maintenance
3. Ambigu
“Kayaknya ada cara yang lebih bagus deh selain ini”
“Beneran kodenya mau seperti ini?”
Apabila tidak memiliki perspektif yang jelas jangan mengatakan sesuatu yang tidak berguna seperti ini, komentar harus jelas dan memiliki arahan jelas apa yang harus dilakukan atau dioptimasi.
Apabila dibutuhkan lebih baik untuk berpedapat:
‘Sebaiknya coba koordinasi sama tony karena dia yang mengerjakan aplikasi jarvis sebelumnya, atau coba lihat kode pada penggajian karena konsepnya mirip dengan yang kamu kerjakan.’
4. Jangan dimasukkan ke dalam hati
Di lain sisi jangan membawa saran terlalu personal, rekan mu telah menyempatkan waktu untuk mereview dan memberi saran yang lebih baik, jangan punya persepsi bahwa rekan tersebut punya masalah denganmu, baca komennya dan perbaiki secara proporsional.
Tidak mampu melakukan estimasi pekerjaan
Gampang kok 2 hari juga kelar
Di satu sisi programmer memiliki ego dalam penentuan berapa lama pekerjaan dapat terselesaikan. Pada kenyataannya estimasi yang dilakukan berada pada kondisi yang ideal dimana tidak ada hambatan sedangkan ketidakpastian pada pengembangan aplikasi bersifat tinggi.
Ada juga tekanan dari pihak manajemen atau perusahaan untuk melakukan rilis secara terburu-buru yang menyebabkan developer merasa tidak enak bila menolak deadline yang diberikan.
Tapi bila ternyata sampai pada akhir estimasi, pekerjaan belum terselesaikan maka akan membawa dampak jelek ke perusahaan atau ke tim itu sendiri (burnout). atau apabila itu berhasil dirilis akan mengandung kecacatan (defect).
Ada beberapa cara seperti
- melakukan diskusi (collective agreement) untuk menentukan berapa besar lingkup pekerjaan, bukan berapa lama hari. Dan disisi lain developer jangan hanya
yes bostapi juga mampu mengungkapkan pendapat atas proyek yang dikerjakan dan batasannya. - menggunakan data berdasar berapa besar lingkup pekerjaan suatu tugas, dibanding tugas yang pernah diselesaikan sebelumnya. Misal bobot pengerjaan untuk tugas A sebelumnya sebesar 5 poin dan pengerjaannya lebih susah untuk tugas yang B maka gunakan poin 8.
Ketakutan untuk mengoptimasi (refactor) kode
Terkadang kita memasukkan kode yang agak acak aduk kedalam rilis produksi karena tuntutan dikejar waktu atau karena takut kode yang kita kerjakan dapat merusak fungsi lain. Kode ini lambat laun akan menjadi rumit dan susah untuk dikembangkan.
Tidak semua kode harus di-`refactor` karena menghabiskan sumber daya baik waktu maupun biaya. Dan apabila dirasa waktunya perlu maka beberapa hal ini dapat membantu proses refactoring.
a. sediakan waktu terpisah antara pengembangan fitur dan pembayaran technical debt (hutang pemograman). Bisa diantara selepas rilis fitur besar atau saat ada momen banyak libur pada pertengahan minggu
b. pastikan tes tersedia, untuk memastikan fungsi modul yang dioptimasi sama dengan sebelum optimasi
c. untuk modul yang bersifat kompleks seyogyanya melewati tes pada environment staging untuk memastikan fungsi yang direfaktor berjalan pada lapisan database yang mirip dengan production
d. Mitigasi ke kode lama dapat dilakukan dengan cepat apabila ada masalah critical yang timbul;
- dapat melalui revert (mengembalikan ke rilis lama)
- atau menggunakan feature toggling untuk fitur baru atau lama apabila dirasa perlu
e. pair programming dapat memperkaya perspektif untuk melakukan refaktor berikut juga review kode oleh anggota tim lain
Tidak ada pencatatan progress (tracking)
Let it flow — frozen
Pengembangan aplikasi memerlukan pencatatan proses seperti Jira atau Pivotal Tracker. Hal ini membantu saran, pengembangan, atau bug yang tertinggal dapat tercatat atau untuk menemukan blocker yang dihadapi dalam personal sehingga anggota tim lainnya dapat membantu atau memberikan petunjuk.
Pencatatan juga dapat melihat proyeksi kecepatan dan kapasitas suatu tim dalam suatu waktu untuk pengerjaan aplikasi.
Segan dalam menyampaikan ide atau pendapat
Heraclitus — There is nothing permanent except change
Ide yang disampaikan merupakan cerminan dari buah pikir developer. Harapan akan fitur/teknologi yang bisa diimplementasikan.
Memang beberapa ide tampaknya susah diimplementasikan pada kondisi saat ini, pendapat lainnya terkesan bagus tapi melanggar norma tidak tertulis atau beberapa opsi dikesampingkan dalam `to-do list` untuk dibahas pada kemudian hari.
Menertawakan ide atau menjatuhkan opini dari rekan tim akan membuat pencetus merasa dihukum. dan apabila diteruskan akan membuat lebih baik diam saja cari aman daripada mengemukakan pendapat yang jelas-jelas berakhir di tong sampah.
Apa yang terjadi?
Programmer dapat berhenti untuk belajar. Berhenti untuk mengemukakan ide atau konsep, berhenti untuk berinteraksi dengan pelanggan dan terutama berhenti untuk mendalami bisnis.
