Hari ini di milis it-project-indonesia@googlegroups.com ada Joshua Partogi dari Scrum Indonesia yang kenalan, kemudian terjadi diskusi yang cukup seru tentang Scrum Vs Waterfall. Nah di salah satu thread ada yang menanyakan gimana sih development di banking kepada saya


> Buat Ifnu, bisa ceritain nu development di banking kaya gimana dan
> kenapa waterfall itu yang terbaik?

Nah karena jawaban saya panjang lebar, sepertinya cocok diletakkan di dalam blog agar lebih banyak yang bisa baca. Hmm, oke gw ceritain agak panjang yah tentang topik ini.

Background Institusi

Salah satu investment bank paling gede se jerman. Budget biasanya sih ga jadi masalah, karena uang cukup berlimpah, bisa bayar employee di atas rata-rata pasar singapura.

Team

Di sini ada beberapa team yang menangani aplikasi :
1. Team development : Developer, BA, Functional Specialist, PM
2. Team Internal Testing
3. Team UAT testing
4. Infrastructure team: Unix, DBA, Deployment, Configuration team dan Source Control team (build, package, versioning system)
5. Production support team

Di luar itu ada beberapa peran yang gak ada di dalam team di atas :
1. Product Owner dari sisi bussiness
2. Product Owner dari sisi IT

Development Methodology

Kita menggunakan Waterfall strict yang comply dengan CMMI Level 5, semua dokumentasi dimantain di sharepoint server dan ada guidlines (template) dokumen apa saja yang perlu dibuat setiap release. Ketika project diinisialisasi diasumsikan bahwa project ini akan terus didevelop, dienhance, patch dan dimantain selama bertahun-tahun.

Project akan dikasi alokasi budget fix di awal tahun, budget ini biasanya ditentukan apakah aplikasi ini menghasilkan ROI yang bagus di tahun-tahun sebelumnya. Kalau iya maka diterusin dikasi budget besar, kalau nggak biasanya cuma dikasi budget seupil untuk maintenance aja. Atau malah dibunuh aplikasinya kalau sudah ga ada client sama sekali. Budgetnya juga ga main-main loh, aplikasi gw ini cuma kecil banget tapi bisa habis ratusan ribu USD setahun. Ada aplikasi yang source codenya aja 5GB, ini bisa puluhan juta dolar budgetnya, #ngiler.

Setiap aplikasi akan release 4x dalam setahun, misalnya tahun ini ada release 11.1, 11.2, 11.3 dan 11.4. Apa yang ada di dalam setiap release ini ya juga tergantung budget, kalau dikasi budget development ya banyak yang direlease, kalau cuma maintenance ya sudah ga ada release sama sekali. Paling cuma simple patching, seperti ganti copyright setial awal tahun :) ).

Di sisi vendor, ada 2 arrangement: managed service dan non managed service. Di jenis managed service, vendor akan dikasi budget fix per tahun, kemudian dikasi scope apa aja yang harus dikerjakan dan dikasi komposisi teamnya. Nah biasanya kalau managed service ini sama vendor
dieksekusinya di negara asalnya, india, nggak di singapura. Kenapa? ya karena gaji karyawanya kan cuma 1/3 dari singapura. Delivery menjadi tanggung jawab vendor, kalau ada yang salah, misalnya ada show stopper bug di production, vendor bisa kena denda setelah 3x. Dendanya buaanyak. Dari sisi client cuma ada Product Owner, PM dan Senior Architect. PO akan menentukan feature apa aja yang dibuat, partnernya di sisi vendor adalah BA. PM menentukan gimana jadwalnya dan architect menentukan bagaimana feature ini secara teknis diimplementasi.

Jenis satunya lagi non managed service, client bertanggung jawab terhadap delivery project, vendor cuma menyediakan resource dan nyalain argo :D . Simple, dan easy money sih di sisi vendor.

Flow development dimulai dari highlevel management untuk menentukan strategi bisnis dan aplikasi, kemudian PO akan merancang requirement apa saja yang perlu dari aplikasi ini. Setelah itu PM bersama dengan PO dan management akan menentukan budgeting dan proyeksi go livenya kapan. Setalah itu Architect akan membuat highlevel design dan arsitektur aplikasinya. Sampai di sini belum ada keterlibatan development team, semua effort masih di sisi client, hingga suatu saat (ini bisa bertahun-tahun kadang-kadang) dirasa semua stakeholder aware dengan semua aspek aplikasi maka development dirollout deh.

BA akan membuat Functional Spec yang saaangatttt rinciii, sampe kecil-kecil pritil-pritil, sampe ke error message, error validation dan semua tetek bengeknya. Setelah Functional Spec kelar, baru kemudian Architect memerintahkan Functional Specialist membuat detail design, seperti UML, ERD, dan seterusnya. Product Owner signoff Functional Spec, architect sign off Detail Design document.

Baru kalau Functional Spec dan Detail Design kelar, developer dihire. Langkah pertama adalah bikin POC, bikin Project Template, bikin build script, DDL, DML dan semua logistik project. Functional Specialist akan melakukan code review berkala untuk semua kode yang dicheckin oleh developer. Ada dokumenya juga loh :O. Dia akan memeriksa hasil code analysis dari PMD, Findbug dan Sonar.

Dalam waktu bersamaan Internal Tester akan membuat skenario testing yang lengkap untuk semua feature aplikasi, ini ga main-main jumlahnya, di project saya aja ada sekitar 400 test case, padahal project kecil. Kalau yang gede ga tau deh berapa banyak :D . BA akan sign off
skenario testing ini.

Proses development biasanya dibagi-bagi menjadi drop kecil-kecil, drop 1, drop 2, drop 3 dan seterusnya. Setiap drop ini ada release notesnya feature apa saja yang sudah diimplementasikan, tester akan mengetest berdasarkan skenario testing dan berdasarkan functional spec yang dibuat oleh BA. Nah inilah masa-masa developer dipecut-pecut, :( . Masa ini disebut dengan SIT testing period, setiap hari jam 2 sore ada rapat TD (test defect) setiap TD yang dibuat oleh tester dibahas oleh: PM, Product Owner dari aplikasi, Senior Developer, Functional Specialist dan kadang-kadang BA juga ikut kalau ada feature yang kurang jelas.

Ini adalah sesi pembantaian developer :( , pertanyaan banyak sekali diajukan oleh PM, jangan kira PM ini males-males dan maunya beres aja seperti di indo loh, senior banget jabatanya udah
Vice President dan nanyaaaaaaaaaaaaaaaaaaaaaaa terus kerjaanya :( . Kalau kita gagu aa uu aa uu, wah wah wah, dicatet deh sama PM, kalau ada pemotongan jumlah pegawai ya siap-siap dikasi surat cinta.

Setelah masa SIT berarkhir maka SIT akan menyerahkan hasilnya (TD yang belum terpecahkan dan TD yang udah terpecahkan) ke UAT tester. UAT tester ini adalah kepanjangan tangan dari Product Owner dari sisi Bussiness, mereka ini biasanya bukan orang teknis, ya disimulasikan
seperti user biasa aja, tapi pinter-pinter, bisa ketemu deh skenario aneh2 yang bikin aplikasi jadi ga beres :( .

Bersamaan dengan UAT biasanya ada Load Testing yang akan mengetest performa aplikasi ketika dikasi load tertentu. Kalau Load Tester ini membuat Test Defect, alamaaaaak, cari pemecahanya susyaaah bener. Pasang profiler di mana-mana, pasang transaction log untuk melihat eksekusi per komponen aplikasi, pasang database index, pasang cache L1, pasang cache L2, pasang asynchronous/background process, pasang heap dump log, pasang JVM argument aneh-aneh, pasang JVM BEA, ganti lagi JVM Sun, pasang ini itu di sana sini masiiih aja kadang-kadang ga
ketemu bugnya di mana. :( . Nangis darah deh kalau kena jenis ini.

Test terakhir adalah penetration testing, ini sih bugnya menakutkan, tapi mengatasinya sih ga susah. Soalnya kalau di java frameworknya sudah banyak membantu, seperti SQL injection, XSS, Session Forgery dan ACL sudah ada frameworknya, tinggal masang aja.

Semua tester harus menyediakan signoff sebelum deadline production release, ada satu aja tester ga mau tanda-tangan ya sudah production date akan ditunda.

Day To Day developmentnya sih cukup hectic yah, seperti yang saya bilang di atas setiap jam 2 sore ada Test Defect call, kemudian kadang-kadang kalau ada load test defect yang serius, seperti outofmemoryexception atau page timeout akan ada load test defect call
jam 4 sore. Trus jam 9 malem ada UAT Test Call juga. Hedeeeeh. gila deh.

Setelah release biasanya kita pesta-pesta, makan makan dan selama management menentukan apa saja yang perlu discope di release berikutnya, developer bisa pulang tenggo :D . Tapi technical specialist gw ga rela deh kalau ada developer idle, pasti dikasi kerjaan apa gitu, POC misalnya. Soalnya kalau developer idle PM akan nanya, si ini ngapain? kalau dijawab ga ngapa2in, PM akan nanya lagi, udah berapa lama ga ngapa2in? udah 2 bulan. Ya sudah PM akan segera melepas ini developer deh. Kalau developer ini pegawai tetap ya vendor akan meletakkan dia di “pool” dan dicariin project lagi, asik banget deh di pool ini, ga ada kerjaan gajian jalan terusssss :) ). (sayang gw ga pernah masuk pool, ngenes).

Kalau di indonesia model development seperti ini juga lazim digunakan, cuman yang bener-bener mirip itu Permata, soalnya dipengaruhi oleh pemegang sahamnya, HSBC. Sedangkan bank lain seperti BRI masih pake project management kuno, koboy :) ).

Nah sekian cerita saya nih. Kalau capek bacanya bisa dengerin saya cuap-cuap bareng adelwin tentang topik large development team di banking

http://ifnubima.org/indo-java-podcast-10-ngobrol-bareng-adelwin-tentang-large-development-team/