Knowledge

Evolusi dan Agility: Clean Inside, Lean Outside

Di dalam tulisan saya sebelumnya, saya menuangkan gagasan mengenai pandemi sebagai katalis dari intelligent learning yang terasa semakin dekat. Jika pandemi adalah katalis, maka formula awal dari evolusi adalah agility.
 
Agility bukan hanya mengenai kecepatan dan kelincahan. Dalam hal perkembangan teknologi, agility adalah kesinambungan (sustainability), bahkan dalam keadaan ekstrem sekalipun. Agility is a team game. Agility membutuhkan sikap proaktif dan kolaboratif dari semua pihak yang terlibat, khususnya pengembangan teknologi.
 
Agile manifesto sendiri menyebutkan bahwa:
 
Customer collaboration over contract negotiation
Responding to change over following a plan
 
hal ini membuktikan bahwa sejatinya agile adalah cikal bakal dari sustainability. Respon yang terus menerus dan berkesinambungan lebih diutamakan dibandingkan dengan mengikuti rencana yang dalam konteks ini memiliki kemungkinan tingkat relevansi yang berkurang atau bahkan sudah tidak relevan dengan keadaan.
 
Melakukan data entry mungkin sudah tidak relevan lagi jika tujuannya adalah untuk melakukan efisiensi administrasi, ada teknologi yang lebih efisien, yaitu OCR. Menggunakan password yang berbeda-beda antara satu sistem dengan yang lainnya sudah tidak relevan lagi bagi pihak-pihak yang sudah mengandalkan sistem SSO dan Active Directory. Menggunakan physical storage sudah tidak relevan lagi bagi pekerja yang membutuhkan data-on-demand, penyimpanan cloud sebagai solusinya. Faktanya, tingkat relevansi antara masalah dengan solusi memiliki time frame yang sangat singkat. Dari hitungan dekade menjadi hitungan tahun, dari tahun menjadi bulan, dari bulan menjadi hari. Akan selalu ada evolusi lahir setiap hari dari tim-tim yang sudah menerapkan agile.
 
No gain without pain
 
Singkatnya time frame yang dimiliki akibat menurunnya tingkat relevansi antara masalah dengan solusi tentu memiliki dampak signifikan, terutama untuk para software developer. Sejatinya, setiap software yang dihasilkan akan memiliki dua value berbeda untuk para stakeholder, yaitu behavior dan architecture^[1]. Software developer dipekerjakan untuk membuat software dengan behavior yang menghasilkan uang atau menghemat cost dengan membantu para stakeholder mengembangkan spesifikasi fungsional atau dokumen requirement, kemudian menulis program yang memenuhi requirement tersebut. Di sisi lain, software yang dihasilkan memiliki struktur yang “soft” dengan tujuan agar behavior dari sistem dapat diubah dengan mudah ketika kondisi awal requirement menjadi sudah tidak relevan lagi. Software developer bertanggung jawab untuk memastikan bahwa kedua nilai tersebut agar software yang dihasilkan memiliki kualitas yang tinggi dalam time frame yang ada. Semakin singkat time frame yang dimiliki, semakin besar effort yang dilakukan untuk mempertahankan agility. Pekerjaan yang sulit dan menyakitkan, tapi sangat mungkin untuk dilakukan.
 
Akan selalu ada shortcut untuk dapat menghantarkan produk/sistem di dalam time frame yang sudah ditentukan, namun bukan berarti shortcut tersebut memiliki konsekuensi lebih kecil dibandingkan jalan yang seharusnya. Adalah hal umum bagi stakeholder dalam software development untuk mementingkan fungsionalitas dibandingkan fleksibilitas sistem kedepannya, dan para software developer umumnya tidak menentang attitude tersebut. Namun, attitude ini bukanlah attitude yang baik dalam prinsip agile, bahkan bisa mengakibatkan menurunnya kualitas dari software yang dihasilkan, atau lebih buruk, software yang dihasilkan memiliki kualitas yang rendah.
 

Ada tiga alasan yang solid mengapa sebuah software memiliki kualitas yang rendah, Tim developer tidak mengetahui teknik dan praktik untuk mengembangkan aplikasi berkualitas tinggi Tim developer tidak diizinkan oleh stakeholder untuk mengembangkan aplikasi berkualitas tinggi karena hal tersebut dianggap menyita waktu dan terlalu mahal Tim developer tidak memiliki motivasi untuk melakukannya   Joshua Partogi dalam Manajemen Modern dengan SCRUM, 2015

 
Idealnya, agar tetap mempertahankan agility, software developer harus memetakan scope delivery perubahan untuk membedakan mana yang penting (important) mana yang mendesak (urgent). Mantan Presiden Amerika Serikat ke-34, Dwight D Eisenhower menciptakan matriks hubungan antara importance dengan urgency.
 

 
“I have two kind of problems,the urgent and the important. The urgent are not important, and the important are never urgent”
 
Jika kita hubungkan antara value yang harus dihasilkan oleh software developer dengan matriks diatas, kita akan setuju bahwa:
 
value behavior dari software bersifat urgent tapi tidak selalu important, dan
value architecture dari software bersifat important tapi tidak memiliki urgensi yang tinggi
 
meskipun dalam beberapa kondisi khusus kita dapat menemui value behavior dan value architecture bisa menjadi hal yang sama-sama important dan urgent. Dan bila diurutkan dalam skala prioritas maka:

1. Urgent dan important
2. Tidak urgent namun important
3. Tidak important namun urgent
4. Tidak important dan tidak urgent

 
Value behavior dapat kita letakan pada prioritas nomor 1 apabila ada kasus khusus (seperti pandemi) dan pada nomor 3, sementara untuk value architecture dapat kita letakan pada prioritas nomor 2.
 
Kesalahan yang sering dibuat oleh stakeholder dan software developer rangka demi mempertahankan agility adalah menaikan derajat prioritas yang ada di prioritas nomor 3 menjadi prioritas nomor 1. Dengan kata lain, kita telah gagal untuk memisahkan mana fitur/deliverable yang urgent namun tidak important dengan mana yang benar-benar urgent dan important. Kegagalan ini mengarah pada diabaikannya arsitektur sistem yang penting demi fitur sistem yang tidak penting. Bila arsitektur sistem menjadi prioritas terakhir maka sistem akan semakin sulit untuk di-develop, semakin “boros”, bahkan mustahil untuk diubah hingga akhirnya akan memperlambat agility atau agility menjadi 0.
 
It’s always people problem, mengapa konsep agile menjadi sangat menyakitkan untuk dilakukan. Banyak yang berpikir bahwa permasalahan dalam pengembangan software dapat dipecahkan dengan meningkatkan kapasitas maupun kualitas teknologi yang digunakan. Namun akar dari permasalahan tersebut terletak pada peletakan prioritas yang tidak proporsional terhadap risiko akan perubahan dan evolusi.
 
Clean inside, lean outside
 
Peletakan prioritas yang tidak proporsional yang disebutkan pada paragraf sebelumnya bukan hanya berkaitan dengan proporsi backlog development, namun juga erat kaitannya dengan kepedulian dari para developer dalam membuat sistem yang bersih dan lean namun tetap kompatibel, yang dalam hal ini bukan hanya sekedar mengenai value arsitektur sistem, namun juga value behavior yang berasal dari kode program yang ditulis.
 
Menulis kode program sama seperti menulis sebuah buku. Kode harus dapat dimengerti dan dibaca berulang-ulang tidak hanya oleh software developer yang menulisnya, namun juga oleh developer lainnya yang bahkan bukan berada di environment asal kode tersebut muncul. Kode awal yang ditulis ibaratkan seperti draft dimana masih terdapat tulisan-tulisan yang masih dipertimbangkan fungsi-fungsinya, belum fully-functioned, dan masih “kotor” (dirty code).
 
Software developer yang telah menerapkan konsep agile akan terus-menerus membersihkan dirty code atau yang disebut dengan refactoring. Hal ini dilakukan karena para developer menyadari bahwa software dibuat bukan hanya untuk sekali pakai, namun juga harus memiliki sifat sustain selama mungkin. Bukan hal yang mustahil apabila pengembangan atau update selanjutnya akan dilakukan oleh tim yang berbeda. Developer selanjutnya akan membaca kode yang ada sebelum memperbaiki defect atau menambah fitur.
 
Bila kode dari software kotor, maka akan memakan waktu lebih lama untuk dapat memahami algoritma dan logic dari software tersebut. Bahkan di keadaan yang lebih buruk, dengan adanya dirty code, software developer akan kesulitan dalam menemukan letak masalah/bug dari program. Waktu yang digunakan untuk menemukan masalah/bug ini dapat memakan waktu lebih lama dibandingkan membuat inovasi baru. Permasalahan ini akan menurunkan agility karena seperti yang kita sama-sama pahami bahwa time frame dari relevansi sebuah software semakin kesini semakin singkat.
 
Melakukan programming - refactoring - testing yang menghasilkan kode bersih (clean code) mungkin akan membutuhkan sumber daya yang lebih banyak dibandingkan merilis software yang “asal jalan”, namun apabila agility dan sustainability merupakan prinsip utama agar sistem yang dikembangkan memiliki return on investment yang tinggi, melakukan praktik clean code menjadi sebuah kewajiban. Sedangkan untuk menjaga value arsitektur, beberapa pakar system architecture mengemukakan ide-ide mereka mengenai clean architecture, seperti Hexagonal Architecture yang dikembangkan oleh Alistair Cockburn dan diadaptasi oleh Steve Freeman dan Nat Pryce dalam buku “Growing Object Oriented Software with Tests”, Data-Context Interaction (DCI) oleh James Coplien dan Trygve Reenskaug, dan juga Boundary-Control Entity (BCE) yang diperkenalkan oleh Jacobson dari bukunya yang berjudul “Object Oriented Software Engineering: A Use-Case Driven Approach”.
 
Meskipun ketiga konsep arsitektur tersebut memiliki perbedaan pada detail dan spesifikasinya, mereka memiliki objektif yang sama, yaitu pemisahan antara business rules, system dan user interface. Secara detail, masing-masing dari konsep tersebut memiliki karakteristik sebagai berikut:

• Independen dari framework dimana arsitektur sistem tidak bergantung pada keberadaan library dari framework tersebut,
• Testable dimana business rules dapat dites tanpa menggunakan user interface (UI), database, web server atau elemen eksternal lainnya,
• Independen dari UI, sehingga apabila terjadi perubahan pada UI tidak akan mempengaruhi sistem dan business rules
• Independen dari database dimana sistem dapat diimplementasikan pada server database manapun tanpa mempengaruhi business rules
• Independen dari agent eksternal manapun

 

 
Masing-masing area lingkaran pada clean architecture merepresentasikan area yang berbeda dari software. Secara umum, semakin dalam area lingkaran, maka semakin tinggi level dari software tersebut. Lingkaran terluar adalah mekanisme, sedangkan lingkaran terdalam adalah policies. Aturan utama yang membuat arsitektur ini berfungsi disebut dengan Dependency Rule dimana ketergantungan source code harus mengarah ke arah dalam, menuju ke arah policies.
 
Segala sesuatu di lingkaran dalam, tidak memiliki keterkaitan dengan segala sesuatu di lingkaran luar. Secara khusus, spesifikasi yang ada di lingkaran luar tidak boleh dideklarasikan pada kode yang ada di lingkaran dalam, termasuk di dalamnya nama fungsi, nama kelas, nama variabel, dan entitas software lainnya. Sehingga apapun yang terjadi pada lingkaran luar, tidak akan berdampak apapun pada policies.
 
Mematuhi aturan sederhana ini tidak sulit, dan itu akan menghemat banyak sumber daya kedepannya. Dengan memisahkan software menjadi beberapa lapisan dan menyesuaikan dengan Dependency Rules, kita dapat membuat sistem yang dapat diuji secara intrinsik termasuk dengan semua benefit dan fitur yang terkandung. Apabila salah satu bagian eksternal dari sistem menjadi tidak relevan lagi dengan teknologi terkini, seperti database atau framework, elemen-elemen itu dapat diubah dengan minimum effort.
 
Agile, Agile, Agile
 
Seperti yang telah disebutkan sebelumnya bahwa agility lebih kepada people problem dimana ada andil dari sikap dan cara dari para software developer dan stakeholder dalam merencanakan bagaimana sistem dikembangkan dan dipelihara adalah kunci utama. Praktik clean code dan clean architecture tidak dapat dianggap remeh jika ingin mempertahankan sustainability dan adaptif dalam kondisi ekstrem sekalipun. Pun jika kita belum berada pada lingkungan dengan standar clean code dan clean architecture yang tinggi, saya rasa belum terlambat untuk mulai berbenah diri sebagai knowledge worker.
 
Tantangan ke depan mungkin akan semakin berat dengan semakin canggihnya teknologi yang lahir setiap menitnya. Manusia sebagai knowledge worker adalah yang menciptakan teknologi, manusia adalah starting point dari lahirnya inovasi dan kreasi baru, manusia adalah poros dari evolusi. Mempertahankan agility dalam menghadapi evolusi adalah sebuah long life mission agar tetap berada di dalam standar kehidupan manusia yang lebih baik. Sekarang mari kita merefleksikan apa yang sudah dilakukan, apakah kita sudah cukup agile dalam beradaptasi di era ini?