Microsoft DevOps ile nasıl planlar?

Microsoft, Çevik metodolojilerini kullanan dünyanın en büyük şirketlerinden biridir. Microsoft, yıllar boyunca en küçük projelerden Windows gibi büyük projelere kadar ölçeklenebilen bir DevOps planlama süreci geliştirmiştir. Bu makalede, Microsoft'un şirket genelinde yazılım projeleri planlarken uyguladığı derslerin ve uygulamaların birçoğu açıklanmaktadır.

Araçsal değişiklikler

Aşağıdaki önemli değişiklikler, geliştirme ve gönderim döngülerinin daha sağlıklı ve daha verimli hale getirmesine yardımcı olur:

• Kültürel uyumu ve özerkliği teşvik edin.
• Odağı bireylerden ekiplere değiştirin.
• Yeni planlama ve öğrenme stratejileri oluşturun.
• Çok mürettebatlı bir model uygulayın.
• Kod sağlığı uygulamalarını geliştirme.
• Saydamlığı ve sorumluluğu teşvik edin.

Kültürel uyumu ve özerkliği teşvik etmek

Peter Drucker dedi ki, "Kültür kahvaltı stratejisini yer." Özerklik, ustalık ve amaç temel insan motivasyonlarıdır. Microsoft, bu motivasyonları, başarılı ürünler oluşturma konusunda kendilerini güçlü hissetmeleri için proje yöneticilerine, geliştiricilere ve tasarımcılara sağlamaya çalışır.

Bu yaklaşımın iki önemli katkıda bulunanı hizalama ve özerkliktir.

• Hizalama, bireylerin ve ekiplerin sorumluluklarının daha geniş iş hedefleriyle nasıl uyumlu olduğunu anlamasını sağlamak için yukarıdan aşağıya doğru gelir.
• Özerklik, bireylerin ve ekiplerin günlük etkinlikler ve kararlar üzerinde etkisi olduğundan emin olmak için alttan yukarıya gerçekleşir.

Uyum ve özerklik arasında hassas bir denge vardır. Çok fazla hizalama, insanların yalnızca kendilerine söylenen şekilde performans gösterdiği negatif bir kültür oluşturabilir. Çok fazla özerklik, yapı veya yön eksikliğine, verimsiz karar alma sürecine ve kötü planlamaya neden olabilir.

Odağı kişilerden ekiplere değiştirme

Microsoft, kişileri ve ekipleri üç gruba ayırır: PM, tasarım ve mühendislik.

• PM, Microsoft'un ne oluşturduğunu ve neden oluşturduğunu tanımlar.
• Tasarım, Microsoft'un yaptıklarını tasarlamaktan sorumludur.
• Mühendislik ürünleri oluşturur ve kalitelerini güvence altına alır.

Microsoft teams aşağıdaki temel özelliklere sahiptir:

• Disiplinler arası
• 10-12 kişi
• Kendi kendini yönetme
• 12-18 ay için net bir strateji ve hedefler
• Fiziksel takım odaları
• Kendi özellik dağıtımı
• Üretimdeki özgün özellikler

Dikey yapılı ekipleri hedefleyin

Microsoft ekipleri, tüm kullanıcı arabirimini, tüm verileri veya tüm API'leri kapsayan yatay bir ekipti. Artık Microsoft, dikey ekipler için çaba gösteriyor. Ekipler uçtan uca ürün alanlarının sahibidir. Belirli katmanlardaki katı yönergeler, ürün genelinde ekipler arasında tekdüzenlik sağlar.

Aşağıdaki diyagramda yatay ve dikey takımlar arasındaki fark kavramsallaştırılarak gösterilmiştir:

Kendi kendini seçen ekiplere izin ver

Yaklaşık her 18 ayda bir Microsoft, geliştiricilerin sonraki birkaç planlama dönemi için ürünün hangi alanları üzerinde çalışmak istediklerini seçebilecekleri bir "sarı yapışkan alıştırma" çalıştırır. Bu alıştırma, ekiplerin hangi projelerde çalışacaklarını özgürce seçebilmelerine olanak tanıyarak özerklik sağlar. Aynı zamanda, ekipler arasında dengeyi teşvik ederek organizasyonel uyumu destekler. Bu alıştırmadaki kişilerin yaklaşık 80% mevcut ekiplerinde kalıyor, ancak seçme şansı olduğu için kendilerini güçlü hissediyorlar.

Yeni planlama ve öğrenme stratejileri oluşturma

Dwight Eisenhower dedi ki, "Planlar değersizdir, ancak planlama her şeydir." Microsoft planlama aşağıdaki yapıya ayrılır:

• Sprint'ler (3 hafta)
• Planlar (3 sprintler)
• Mevsimler (6 ay)
• Stratejiler (12 ay)

Mühendisler ve ekipler çoğunlukla sprint'lerden ve planlardan sorumludur. Liderlik öncelikle mevsimlerden ve stratejilerden sorumludur.

Aşağıdaki diyagramda Microsoft planlama stratejisi gösterilmektedir:

Bu planlama yapısı, planlama yaparken öğrenmeyi en üst düzeye çıkarmaya da yardımcı olur. Ekipler geri bildirim alabilir, müşterilerin ne istediğini bulabilir ve müşteri isteklerini hızlı ve verimli bir şekilde uygulayabilir.

Çok mürettebatlı bir modeli uygula

Önceki yöntemler hataların ve canlı sistem olaylarının "kesinti kültürünü" teşvik etti. Microsoft ekipleri, odaklanma sağlamak ve dikkat dağıtıcı şeylerden kaçınmak için kendi yöntemleriyle geldi. Takımlar, her sprint için kendiliğinden iki ayrı ekibe ayrılır: Özellikler Ekibi (F-crew) ve Müşteri Ekibi (C-crew).

F-crew, taahhüt edilen özellikler üzerinde çalışır ve C-crew canlı site sorunları ve kesintileriyle ilgilenir. Ekip, üyelerin etkinlikleri daha kolay planlamasını sağlayan dönen bir tempo oluşturur. Çok ekipli model hakkında daha fazla bilgi için bkz. Üretken ve müşteri odaklı ekipler oluşturma.

Kod sağlığı yöntemlerini geliştirme

Çevik metodolojilere geçiş yapmadan önce, ekipler geliştirme aşamasının sonunda kod tamamlanana kadar kod hatalarının birikmesine izin verirdi. Ekipler daha sonra hataları keşfetti ve bunları düzeltmek için çalıştı. Bu uygulama, ekiplerin yeni özellikler geliştirmek yerine hata düzeltme çalışmaları üzerinde çalışmak zorunda kaldığı zaman teamin moralini ve üretkenliğini etkileyen zorlu ve dalgalı bir hata süreçleri yarattı.

Teams artık formülüyle hesaplanan bir # of engineers x 5 = bug cap uygular. Bir ekibin hata sayısı sprint'in sonunda hata sınırını aşarsa, yeni özellikler üzerinde çalışmayı durdurması ve üst sınırına ulaşıncaya kadar hataları düzeltmesi gerekir. Takımlar artık çalıştıkça hata borcunu azaltıyor.

Saydamlığı ve sorumluluğu teşvik edin

Her sprint'in sonunda, her ekip bir önceki sprint'te neler başardıklarını ve bir sonraki sprint'te ne yapmayı planladıklarını bildiren bir posta gönderir.

Hedefler ve önemli sonuçlar (OKR)

Ekipler en çok kuruluşun gerçekleştirmeye çalıştığı hedefler konusunda net olduklarında etkilidir. Microsoft, hedefler ve önemli sonuçlar (OKR) aracılığıyla ekipler için netlik sağlar.

• Hedefler , ulaşılması gereken hedefleri tanımlar. Hedefler önemli, somut, eylem odaklı ve ideal olarak ilham verici amaç ifadeleridir. Hedefler gerçek sayıları değil büyük fikirleri temsil eder.
• Önemli sonuçlar , hedeflere ulaşma adımlarını tanımlar. Önemli sonuçlar, ilerlemeyi değerlendiren ve belirli bir zaman aralığındaki hedeflere karşı başarıyı gösteren ölçülebilir sonuçlardır.

OKR'ler yalnızca en olası sonuçları değil, mümkün olan en iyi sonuçları yansıtır. Liderler hırslı ve ihtiyatlı olmamaya çalışırlar. Ekipleri zorlu önemli sonuçları izlemeye zorlamak, hedeflere karşı hızlanmayı artırır ve daha büyük hedeflere doğru ilerleyen işleri önceliklendirir.

OkR çerçevesini benimsemek, ekiplerin aşağıdaki nedenlerle daha iyi performans göstermelerine yardımcı olabilir:

• Her ekip planla hizalanmış durumda.
• Ekipler, etkinlikleri tamamlamak yerine sonuçlara ulaşmaya odaklanır.
• Her ekip, düzenli olarak yürütülen çabalarından sorumludur.

BIR ürünün farklı düzeylerinde OKR'ler olabilir. Örneğin, üst düzey ürün OKR'leri, bileşen düzeyi OKR'leri ve ekip düzeyi OKR'leri olabilir. OkR'leri hizalı tutmak, özellikle hedefler yukarıdan aşağıya ayarlanmışsa nispeten kolaydır. Ortaya çıkan tüm çakışmalar, kurumsal yanlış hizalamanın değerli erken göstergeleridir.

OKR örneği

Amaç: Güçlü ve mutlu bir müşteri tabanı geliştirin.

Önemli sonuçlar:

• Dış net yükseltici puanı (NPS) 21'den 35'e yükseltin.
• Belge memnuniyetini 55'ten 65'e yükseltin.
• Yeni işlem hattı akışı 0,9 Apdex puanına sahiptir.
• İşlerin kuyruk süresi 5 saniye veya daha kısadır.

OKR'ler hakkında daha fazla bilgi için bkz. Hedefleri ve önemli sonuçları kullanarak iş sonuçlarını ölçme.

Doğru ölçümleri seçme

Önemli sonuçlar yalnızca temel aldıkları ölçümler kadar yararlıdır. Microsoft, değişikliğe odaklanan önde gelen göstergeleri kullanır. Zaman içinde bu ölçümler, ürün hızlandırma veya yavaşlamanın çalışma resmini oluşturur. Microsoft genellikle aşağıdaki ölçümleri kullanır:

• Aylık benimseme büyüme oranındaki değişiklik
• Performans değişikliği
• Öğrenme zamanı değişikliği
• Olayların sıklığında değişiklik

Ekipler, hedeflere değer katmayan ölçümlerden kaçınıyor. Belirli kullanımları olsa da, aşağıdaki ölçümler hedeflere doğru ilerlemeyi izlemek için yararlı değildir:

• Özgün tahminlerin doğruluğu
• Tamamlanan saatler
• Kod satırları
• Ekip kapasitesi
• Takım iş azaltımı
• Ekip hızı
• Bulunan hata sayısı
• Kod kapsamı

Agile öncesi ve Agile sonrası

Aşağıdaki tabloda, Microsoft geliştirme ekiplerinin Çevik uygulamalarını benimsedikçe yaptığı değişiklikler özetlenmiştir.

Önce	Sonra
4-6 aylık hedefler	3 haftalık sprint'ler
Yatay ekipler	Dikey ekipler
Kişisel ofisler	Ekip odaları ve uzaktan çalışma
Uzun planlama döngüleri	Sürekli planlama ve öğrenme
PM, Geliştirme ve Test	PM, Tasarım ve Mühendislik
Yıllık müşteri etkileşimi	Sürekli müşteri etkileşimi
Özellik dalları	Herkes ana dalda çalışır
20'den fazla kişi ekibi	8-12 kişilik ekipler
Gizli yol haritası	Genel olarak paylaşılan yol haritası
Hata birikimi	Sıfır borç
100 sayfalık belirtim belgeleri	PowerPoint özellikleri
Özel depolar	Açık kaynak veya InnerSource
Derin kuruluş hiyerarşisi	Düzleştirilmiş kuruluş hiyerarşisi
Yükleme numaraları başarıyı tanımlar	Kullanıcı memnuniyeti başarıyı tanımlar
Özellikler yılda bir kez yayınlanır	Özellikler her sprint'i gönderir

Önemli çıkarımlar

• Çevik bilimi ciddiye alın, ancak fazla kuralcı olmayın. Çevik metodolojiler bazen fazla katı hale gelebilir. Çevik zihniyet ve kültürün büyümesine izin verin.
• Etkinliği değil sonuçları kutlayın. İşlevlerin dağıtılması, kod satırlarından daha ağır basıyor.
• Bir ritim ve tempo oluşturmak ve yapılması gereken tüm işleri bulmak için her sprint'te sevk edin.
• Aradığınız davranışı elde etmek istediğiniz kültürü oluşturun.