Cara Microsoft berkembang 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-kru.
• Meningkatkan praktik kesehatan kode.
• Menumbuhkan transparansi dan akuntabilitas.

Mempromosikan keselarasan dan otonomi budaya

Peter Drucker berkata, "Budaya memakan strategi untuk sarapan." Otonomi, penguasaan, dan tujuan adalah motivasi manusia utama. Microsoft mencoba memberikan motivator ini kepada PC, pengembang, dan desainer sehingga 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:

• Lintas disiplin
• 10-12 orang
• Pengelolaan mandiri
• Piagam dan tujuan yang jelas selama 12-18 bulan
• Ruang tim fisik
• Penyebaran fitur sendiri
• Memiliki fitur dalam produksi

Berusaha untuk tim vertikal

Tim Microsoft dulunya horizontal, mencakup semua UI, semua data, atau semua API. Sekarang, Microsoft berusaha untuk tim vertikal. Tim memiliki 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)
• Rencana (3 sprint)
• Musim (6 bulan)
• Strategi (12 bulan)

Insinyur dan tim sebagian besar 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-kru

Metode sebelumnya menumbuhkan "budaya interupsi" bug dan insiden situs langsung. Tim Microsoft datang dengan cara mereka sendiri untuk memberikan fokus dan menghindari gangguan. Teams mengatur sendiri untuk setiap sprint menjadi dua kru yang berbeda: Fitur (F-crew) dan Customer (C-crew).

Kru F bekerja pada fitur yang berkomitmen, dan kru C menangani masalah dan gangguan situs langsung. 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 digunakan untuk membiarkan bug kode dibangun sampai kode selesai di akhir fase pengembangan. Teams kemudian menemukan bug dan bekerja memperbaikinya. Praktik ini menciptakan roller coaster bug, yang memengaruhi moral dan produktivitas tim ketika tim harus bekerja pada perbaikan bug alih-alih menerapkan fitur baru.

Teams sekarang 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 sampai mereka berada di bawah batas mereka. Tim sekarang membayar hutang bug saat mereka pergi.

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 selaras 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: Menumbuhkan basis pelanggan yang kuat dan bahagia.

Hasil utama:

• Tingkatkan skor promotor bersih eksternal (NPS) dari 21 menjadi 35.
• Tingkatkan kepuasan dokumen dari 55 menjadi 65.
• Aliran alur 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 berguna seperti metrik yang didasarkan pada metrik tersebut. 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 adopsi bulanan
• Perubahan performa
• Perubahan waktu untuk belajar
• Perubahan frekuensi insiden

Teams menghindari metrik yang tidak mengumpulkan nilai terhadap tujuan. Meskipun mungkin memiliki kegunaan tertentu, metrik berikut ini tidak berguna untuk melacak kemajuan menuju tujuan:

• Akurasi perkiraan asli
• Waktu selesai
• Baris kode
• Kapasitas tim
• Burndown tim
• Kecepatan tim
• Jumlah bug yang ditemukan
• Cakupan kode

Sebelum Agile dan setelah Agile

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

Sebelumnya	Sesudahnya
Tonggak pencapaian selama 4-6 bulan	Sprint 3 minggu
Tim horizontal	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
Cabang fitur	Semua orang bekerja di cabang utama
Tim 20+ orang	Tim 8-12 orang
Peta strategi rahasia	Peta strategi yang dibagikan secara publik
Utang bug	Utang nol
Dokumen spesifikasi 100 halaman	Spesifikasi PowerPoint
Repositori privat	Sumber terbuka atau InnerSource
Hierarki organisasi mendalam	Hierarki organisasi diratakan
Instal angka menentukan keberhasilan	Kepuasan pengguna mendefinisikan keberhasilan
Fitur dikirim setahun sekali	Fitur mengirim setiap sprint

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.
• Kirim di setiap sprint untuk membangun irama dan irama dan menemukan semua pekerjaan yang perlu dilakukan.
• Bangun budaya yang Anda inginkan untuk mendapatkan perilaku yang Anda cari.