Cara Microsoft merencanakan dengan DevOps

Microsoft adalah salah satu perusahaan terbesar di dunia untuk menggunakan metodologi Agile. Selama bertahun-tahun pengalaman, Microsoft telah mengembangkan proses perencanaan DevOps yang menskalakan dari proyek terkecil melalui upaya besar-besaran seperti Windows. Artikel ini menjelaskan banyak pelajaran yang dipelajari dan praktik yang diterapkan Microsoft saat merencanakan proyek perangkat lunak di seluruh perusahaan.

Perubahan instrumental

Perubahan utama berikut membantu membuat siklus pengembangan dan pengiriman lebih sehat dan lebih efisien:

• Mempromosikan keselarasan dan otonomi budaya.
• Ubah fokus dari individu ke tim.
• Buat strategi perencanaan dan pembelajaran baru.
• Menerapkan model multi-tim.
• Meningkatkan praktik kesehatan kode.
• Menumbuhkan transparansi dan akuntabilitas.

Mempromosikan keselarasan dan otonomi budaya

Peter Drucker mengatakan, "Budaya memakan strategi untuk sarapan." Otonomi, penguasaan, dan tujuan adalah pemicu utama motivasi manusia. Microsoft mencoba memberikan motivator ini kepada PM, pengembang, dan desainer agar mereka merasa diberdayakan untuk membangun produk yang sukses.

Dua kontributor penting untuk pendekatan ini adalah keselarasan dan otonomi.

• Keselarasan berasal dari atas ke bawah, untuk memastikan bahwa individu dan tim memahami bagaimana tanggung jawab mereka selaras dengan tujuan bisnis yang lebih luas.
• Otonomi terjadi dari bawah ke atas, untuk memastikan bahwa individu dan tim berdampak pada aktivitas dan keputusan sehari-hari.

Ada keseimbangan yang halus antara penyelarasan dan otonomi. Terlalu banyak keselarasan dapat menciptakan budaya negatif di mana orang hanya berkinerja seperti yang dikatakan. Terlalu banyak otonomi dapat menyebabkan kurangnya struktur atau arah, pengambilan keputusan yang tidak efisien, dan perencanaan yang buruk.

Mengubah fokus dari individu ke tim

Microsoft mengatur orang dan tim ke dalam tiga grup: PM, desain, dan rekayasa.

• PM mendefinisikan apa yang dibangun Microsoft, dan mengapa.
• Desain bertanggung jawab untuk merancang apa yang dibangun Microsoft.
• Teknik membangun produk dan memastikan kualitasnya.

Tim Microsoft memiliki karakteristik utama berikut:

• Interdisipliner
• 10-12 orang
• Mengelola sendiri
• Piagam dan tujuan yang jelas selama 12-18 bulan
• Ruang tim fisik
• Penyebaran fitur milik sendiri
• Fitur sendiri dalam produksi

Upayakan Pembentukan Tim Vertikal

Tim Microsoft dulunya horizontal, mencakup semua UI, semua data, atau semua API. Sekarang, Microsoft berusaha untuk tim vertikal. Tim bertanggung jawab atas area produk mereka secara end-to-end. Pedoman ketat dalam tingkat tertentu memastikan keseragaman di antara tim di seluruh produk.

Diagram berikut mengonsepkan perbedaan antara tim horizontal dan vertikal:

Perbolehkan tim pemilihan mandiri

Sekitar setiap 18 bulan, Microsoft menjalankan "latihan lekat kuning", di mana pengembang dapat memilih area produk mana yang ingin mereka kerjakan untuk beberapa periode perencanaan berikutnya. Latihan ini memberikan otonomi, karena tim dapat memilih apa yang harus dikerjakan, dan penyelarasan organisasi, karena mempromosikan keseimbangan di antara tim. Sekitar 80% orang-orang dalam latihan ini tetap berada di tim mereka saat ini, tetapi mereka merasa diberdayakan karena mereka memiliki pilihan.

Membuat strategi perencanaan dan pembelajaran baru

Dwight Eisenhower mengatakan, "Rencana itu tidak berharga, tetapi perencanaan adalah segalanya." Perencanaan Microsoft diuraikan ke dalam struktur berikut:

• Sprint (3 minggu)
• Paket (3 sprint)
• Musim (6 bulan)
• Strategi (12 bulan)

Insinyur dan tim umumnya bertanggung jawab atas sprint dan rencana. Kepemimpinan terutama bertanggung jawab atas musim dan strategi.

Diagram berikut mengilustrasikan strategi perencanaan Microsoft:

Struktur perencanaan ini juga membantu memaksimalkan pembelajaran saat melakukan perencanaan. Teams dapat mendapatkan umpan balik, mencari tahu apa yang diinginkan pelanggan, dan menerapkan permintaan pelanggan dengan cepat dan efisien.

Menerapkan model multi-tim

Metode sebelumnya menumbuhkan "budaya interupsi" dalam bentuk bug dan kejadian langsung di situs. Tim Microsoft menemukan cara mereka sendiri untuk memberikan fokus dan menghindari gangguan. Tim mengatur diri mereka sendiri untuk setiap sprint dalam dua kru yang berbeda: Fitur (F-crew) dan Pelanggan (C-crew).

Kru F bekerja pada fitur yang dikomitmenkan, dan kru C menangani masalah dan gangguan pada situs yang sedang aktif. Tim menetapkan irama berputar yang memungkinkan anggota merencanakan aktivitas dengan lebih mudah. Untuk informasi selengkapnya tentang model multi-kru, lihat Membangun tim yang produktif dan berfokus pada pelanggan.

Meningkatkan praktik kesehatan kode

Sebelum beralih ke metodologi Agile, tim biasanya membiarkan bug kode menumpuk sampai kode selesai di akhir fase pengembangan. Teams kemudian menemukan bug dan bekerja memperbaikinya. Praktik ini menciptakan lintasan naik turun bug, yang memengaruhi moral dan produktivitas ketika tim harus fokus pada perbaikan bug daripada menerapkan fitur baru.

Teams saat ini menerapkan batas bug, dihitung dengan rumus # of engineers x 5 = bug cap. Jika jumlah bug tim melebihi batas bug di akhir sprint, mereka harus berhenti mengerjakan fitur baru dan memperbaiki bug hingga jumlahnya di bawah batas. Tim sekarang melunasi hutang teknis seiring berjalannya waktu.

Menumbuhkan transparansi dan akuntabilitas

Di akhir setiap sprint, setiap tim mengirim email yang melaporkan apa yang telah mereka capai dalam sprint sebelumnya, dan apa yang mereka rencanakan untuk dilakukan di sprint berikutnya.

Tujuan dan hasil utama (OKR)

Teams paling efektif ketika mereka jelas tentang tujuan yang coba dicapai organisasi. Microsoft memberikan kejelasan bagi tim melalui tujuan dan hasil utama (OKR).

• Tujuan menentukan tujuan yang akan dicapai. Tujuannya adalah pernyataan niat yang signifikan, konkret, berorientasi tindakan, dan inspirasional. Tujuan mewakili ide-ide besar, bukan angka aktual.
• Hasil utama menentukan langkah-langkah untuk mencapai tujuan. Hasil utama adalah hasil yang dapat diukur yang mengevaluasi kemajuan dan menunjukkan keberhasilan terhadap tujuan dalam periode waktu tertentu.

OKR mencerminkan hasil terbaik, bukan hanya hasil yang paling mungkin. Pemimpin mencoba untuk berambisi dan tidak berhati-hati. Mendorong tim untuk mengejar hasil utama yang menantang mendorong akselerasi terhadap tujuan dan memprioritaskan pekerjaan yang bergerak menuju tujuan yang lebih besar.

Mengadopsi kerangka kerja OKR dapat membantu tim berkinerja lebih baik karena alasan berikut:

• Setiap tim bersinergi dengan rencana.
• Tim berfokus pada mencapai hasil daripada menyelesaikan aktivitas.
• Setiap tim bertanggung jawab atas upaya secara teratur.

OKR mungkin ada di tingkat produk yang berbeda. Misalnya, mungkin ada OKR produk tingkat atas, OKR tingkat komponen, dan OKR tingkat tim. Menjaga OKR tetap selaras relatif mudah, terutama jika tujuan diatur ke atas ke bawah. Setiap konflik yang muncul adalah indikator awal yang berharga dari ketidakselarasan organisasi.

Contoh OKR

Tujuan: Tumbuhkan basis pelanggan yang kuat dan bahagia.

Hasil utama:

• Tingkatkan skor promotor bersih eksternal (NPS) dari 21 menjadi 35.
• Tingkatkan kepuasan dokumentasi dari 55 menjadi 65.
• Aliran pipa baru memiliki skor Apdex 0,9.
• Waktu antrean untuk pekerjaan adalah 5 detik atau kurang.

Untuk informasi selengkapnya tentang OKR, lihat Mengukur hasil bisnis menggunakan tujuan dan hasil utama.

Pilih metrik yang tepat

Hasil utama hanya seberguna metrik yang menjadi dasar penilaian mereka. Microsoft menggunakan indikator utama yang berfokus pada perubahan. Seiring waktu, metrik ini membangun gambaran yang berfungsi tentang akselerasi atau perlambatan produk. Microsoft sering menggunakan metrik berikut:

• Perubahan tingkat pertumbuhan bulanan adopsi
• Perubahan performa
• Perubahan waktu untuk mempelajari
• Perubahan frekuensi insiden

Tim menghindari penggunaan metrik yang tidak memberikan nilai pada tujuan. Meskipun mungkin memiliki kegunaan tertentu, metrik berikut ini tidak berguna untuk melacak kemajuan menuju tujuan:

• Akurasi perkiraan asli
• Jam yang telah diselesaikan
• Baris kode
• Kapasitas tim
• Pembakaran tim
• Kecepatan tim
• Jumlah bug yang ditemukan
• Cakupan pengujian kode

Sebelum Agile dan setelah Agile

Tabel berikut ini meringkas perubahan yang dilakukan tim pengembangan Microsoft saat mereka mengadopsi praktik Agile.

Sebelumnya	Setelahnya
Tonggak pencapaian 4-6 bulan	Sprint 3 minggu
Tim lintas fungsi	Tim vertikal
Kantor pribadi	Ruang tim dan pekerjaan jarak jauh
Siklus perencanaan panjang	Perencanaan dan pembelajaran berkelanjutan
PM, Dev, dan Test	PM, Desain, dan Teknik
Keterlibatan pelanggan tahunan	Keterlibatan pelanggan berkelanjutan
Fitur cabang	Semua orang bekerja di cabang utama
Tim dengan lebih dari 20 orang	8-12 tim orang
Peta strategi rahasia	Peta strategi yang dibagikan secara publik
Hutang teknis	Hutang nol
Dokumen spesifikasi 100 halaman	Spesifikasi PowerPoint
Repositori privat	Sumber terbuka atau InnerSource
Hierarki organisasi mendalam	Hierarki organisasi yang disederhanakan
Angka pemasangan menentukan keberhasilan	Kepuasan pengguna mendefinisikan keberhasilan
Fitur dikirim setahun sekali	Fitur mengirim setiap sprint

Poin-poin Penting

• Perhatikan ilmu Agile dengan serius, tapi jangan terlalu preskriptif. Agile bisa menjadi terlalu ketat. Biarkan pola pikir dan budaya Agile tumbuh.
• Rayakan hasil, bukan aktivitas. Menyebarkan fungsionalitas melebihi baris kode.
• Meluncurkan pada setiap sprint untuk membangun ritme dan pola serta mengidentifikasi semua pekerjaan yang harus dilakukan.
• Bangun budaya yang Anda inginkan untuk mendapatkan perilaku yang Anda cari.