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
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.
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.
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.
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 !
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.
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
: 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
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)
• 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.
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
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
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.
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
hyperjump
vanstee
productmarketing
tammyeverts
tenderlove
marcduiker
shpigford
lynnandtonic
phodgson
paigeccino
eileencodes
deanohume
jponch
