IT Process & Delivery Blank media 

Where are we? • Pemisahan antara proses Development dan Proses Release • Proses Development menitik berat pada cara membangun solusi IT sesuai dengan keinginan user (diwakili oleh Product Owner) dan juga secara bersamaan meningkatkan kualitas (dari solusi yang dihasilkan) dan efisiensi (dengan otomasi). • Proses Release menitik berat pada produksi (solusi IT) yang berkala, terprediksi dan berkesinambungan. • Proses Scrum yang lebih baik 

Proses Development • Implementasi proses SCRUM yang diperbaiki • Peningkatan kualitas pada Scrum Artefact (isi backlog seperti User-Story, Task, Bug/Defects) • Sistem penilaian beban pekerjaan (Story-Point) yang lebih terukur • Peningkatan pada SCRUM Value (focus, courage, open, commit, respect) • Perbaikan pada ritual SCRUM (grooming, sprint planning, daily sprint, demo, retro) • Kapasitas dan Performa Terukur (Velocity & Burn Down) • Otomatisasi CI/CD menggunakan Azure DevOps & App Center • Otomatis quality check setiap kali Pull Request • Otomatis integration check (regression) by other team. 

Proses Development • Trunk Based development. Seluruh team dan engineer bekerja sama di satu development line. • Pekerjaan seseorang yang “selesai”, masuk ke master, akan di-test oleh team / engineer lain. • Integrasi pekerjaan antar team terjalin on-the-spot. 

Proses Development Berkesinambungan • Jaminan atas komitmen dan delivery. • Stakeholder menghormati komitmen yang direncanakan oleh developer. • Developer menghormati delivery yang menjadi komitmen mereka. • Otoritas Scrum Master untuk melindungi semua Scrum team dari “distraction” saat sprint dan memastikan semua Scrum team tidak terkendala apapun. • Scrum Team = Self-Organizing Team. • Product Owners adalah bagian dari scrum team masing-masing. • Anggota Team (PO, TL, DEV, UI/UX, etc) menanggung KPI Bersama. 

Tidak Ada Alasan! • PO, TL, Eng, UI/UX adalah 1 team. • KPI Bersama, milik Bersama, ditanggung Bersama. Jatuh Bersama atau Sukses Bersama. • Mulai bekerja sama, saling hormat-menghormati, saling mengingatkan dan saling bantu. Bangun kultur yang baik. MULAI SUKSES ! • Berhenti menyalahkan anggota team lain, Berhenti mengeluh. BERHENTI GAGAL ! 

“Just like ‘Trust’, Good developers are very-very-very important and very-very-very hard to come by.“ - Hard cold fact 

Kepercayaan Engineer In “Story Point” We deliver !!! • Percaya, engineer bekerja untuk menyelesaikan pekerjaan sesuai user story dan story-point yang telah disepakati • Percaya, engineer menentukan story point berdasarkan keahlian dan kapasitasnya. PO In “Story Point” We Trust • Percaya bahwa engineer bekerja sesuai dengan keahlian dan kapasitasnya, karenanya mendukung seluruh usaha yang dikerjakan oleh engineer. 

Kualitas Internal • Performa dari Scrum Team (setiap team) • Penilaian : Team Velocity • Indikator : Team Velocity yang stabil dan meningkat • Cycle : Tiap akhir sprint • Kualitas dari Source-Code (setiap repository) • Penilaian : Linting (coding style) • Indikator : Peningkatan penggunaan Linter dan Rule-set nya • Cycle : Tiap bulan • Kualitas dari program (setiap repository) • Penilaian : Test Coverage • Indikator : Peningkatan prosentase test coverage. • Cycle : Tiap bulan 

Kualitas External • QA Defect Count (tiap produk) • Penilaian : Jumlah defect/bug yang baru ditemukan oleh QA dalam proses release. Akumulasi defect/bug temuan QA yang belum selesai. • Indikator : Jumlah selalu menurun untuk semua kategori. • Cycle : Tiap bulan • User Defect Count (tiap product) • Penilaian : Jumlah defect/bug yang baru ditemukan oleh end-user dalam proses release. Akumulasi defect/bug temuan end-user yang belum selesai. • Indikator : Jumlah selalu menurun untuk semua kategori. • Cycle : Tiap bulan 

Proses Release • Release secara berkala (Release Train) • Release Candidate (RC) • Release mingguan, setiap hari Jumat. • RC1 = Jumat pertama setelah GA Release • RC2 = Jumat kedua setelah GA Release • RC3 = Jumat ketiga setelah GA Release • RC4 = Jumat keempat setelah GA Release • Target = Staging • General Availability (GA) • Release Bulanan, setiap tanggal 1 tiap bulan. • Target = Production • Release platform • Mobile app menggunakan AppCenter (iOS,Android + Distribution List) • Web App & Server service menggunakan Azure Devops (By SSH now, By Docker future, dijelaskan di slide mengenai infrastruktur) 

Proses Release 1. Kandidat Release (RC) Setiap Hari Jumat 2. Release Utama (GA) Tanggal 1 setiap bulan. Jika tanggal release adalah hari libur maka release dilakukan di hari kerja berikutnya. 

Release Process Calendar 

Proses Release • Release Manager Role • Manajemen Release Train • Manajemen Manifest • Melakukan Versioning • Melakukan Release (by Tagging) • Manifest • Berisi semua tiket (User-Story, Bug, Task) • Disiapkan oleh Release Manager • Ditulis oleh tech lead (sesuai DOD) • Diverifikasi oleh QA sesuai release (RC dan GA) • QA Role • Menjadi bagian dari Release Process. Bukan bagian dari Development Process. • Memastikan seluruh tiket yang ada dalam Manifest sudah di-Test. • Mencatatkan temuan-temuan sebagai tiket baru. • Memberikan laporan QA hasil Test pada manifest kepada Release Manager. 

Release Use Case 

Infrastruktur Untuk Release Now (VPS) • Deploy ke VPS Servers di Wowrack • Otomatisasi dengan Azure DevOps • Deploy lewat SSH ke “Bastion” untuk menjalankan pull script • Manual, Kaku, Reactive, Bayar Per- Server (bare metal) Future (DockerSwarm) • Deploy ke Docker Swarm di Wowrack • Otomatisasi dengan Azure DevOps • Deploy lewat SSH ke Swarm Manager untuk redeploy • Otomatis, Elastic, Reactive, Bayar Per- Server (bare metal) Ideal (Kubernetes) • Deploy ke Kubernetes di PaaS Provider (GCP, AWS, AliCloud) • Otomatisasi dengan Azure DevOps • Deploy pakai Azure/Kubernetes plugin. • Automatic, Elastic, Proactive, Pay Per-Usage 

Scrum Team Task and Function Now • Scrum Team diberi tugas untuk bekerja berdasarkan Experiences (Writing, Reading, QnA, Yummy, Web) • Mobilitas Team scrum menjadi terbatas pada experience tertentu saja. Advised • Scrum Team sebaiknya bekerja berdasarkan EPIC yang tidak harus terikat pada Experience tertentu. • Team manapun bisa develop EPIC apa saja yang berhubungan ke produk • Mobilisasi team dimungkinkan untuk Fitur yang dirasakan sangat penting 

Proses Quality Assurance • QA akan melakukan test pada RC yang terakhir release. • Berdasarkan Manifest yang ada untuk RC tersebut, setiap User- Story dan Bug akan di-test. • Untuk setiap User-Story dalam manifest, jika ada Bug/Defect maka akan dibuatkan Bug ticket baru. Sementara untuk Bug/Defect dalam manifest, jika Bug/Defect-nya belum hilang, maka tiketnya akan di Re-Open. • Bersama Release Manager, QA memutuskan RC mana yang akan di- release menjadi GA. • RC yang memiliki critical dan major bug tidak akan diizinkan oleh QA dan Release Manager untuk menjadi GA 

Contoh QA report setiap RC http://blanks.media 

Tipe Bug & Defect • Critical: Berimbas pada fungsi kritis atau data-data kritis. Dan tidak ada solusi alternatif ataupun cara untuk “mengakali”-nya. • Major: Berimbas pada fungsi-fungsi utama atau data utama. Ada solusi alternatif walau tidak begitu jelas dan susah untuk dilakukan. • Minor: Berimbas pada beberapa fungsi-fungsi sederhana namun tujuan utamanya tetap bisa dijalankan, atau data-data tambahan yang tidak begitu penting. Mempunyai solusi alternatif yang mudah. • Trivial: Tidak berimbas pada fungsi atau data apapun. Bahkan tidak memerlukan alternatif apapun. Tidak ada imbas pada produktifitas atau efisiensi. Mungkin sedikit ketidak-nyamanan saja. 

Web Experience Scrum Team • Saat ini, permintaan terhadap fitur baru atau bug atas solusi-solusi Web ini ditangani oleh DevOps team (yang mana bukan tugas DevOps). • Disarankan untuk dibentuk team baru untuk menangani fitur-fitur ataupun bug-fix pada platform Web. • Opsi-opsi: • Team DevOps diganti Namanya jadi “Web Experience” (recommended) • Team Lead untuk DevOps sebaiknya emban TL yang bersedia sementara belum ada yang baru. • PO untuk “Web Experience” ini di emban oleh PO yang bersedia sementara belum ada yang baru. (dedicated PO for web team is recommended) • Fungsi DevOps ditangani oleh Infrastruktur 

Devops 

Service Desk 

Thank you