Microsoft DevOps ile nasıl planlar?

Microsoft, Çevik metodolojilerini kullanan dünyanın en büyük şirketlerinden biridir. Microsoft, yıllar boyunca windows gibi büyük çabalarla en küçük projelerden ölçeklendirilen 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.

İşaretli 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 durumu 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 gücünde hissetmeleri için VM'lere, 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 derleyip neden oluşturacaklarını tanımlar.
• Tasarım, Microsoft'un ne derlemelerini tasarlamakla 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 kiralama ve hedefler
• Fiziksel ekip odaları
• Kendi özellik dağıtımı
• Üretimde kendi özellikleri

Dikey ekipler için çabalayın

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. Ekipler ne üzerinde çalışılması ve ekipler arasındaki dengeyi artırdıkça kurumsal uyumu seçebildiği için bu alıştırmada özerklik sağlanır. Bu alıştırmadaki kişilerin yaklaşık %80'i mevcut takımlarında 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 sprint)
• 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ı model uygulama

Önceki yöntemler hataların ve canlı site olaylarının "kesme 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. Teams, her sprint için kendi kendine iki ayrı ekibe ayrılır: Özellikler (F-crew) ve Müşteri (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 durumu uygulamalarını geliştirme

Çevik metodolojilerine geçmeden önce ekipler, geliştirme aşamasının sonunda kod tamamlanana kadar kod hatalarının derlenmesine izin vermek için kullanılırdı. Ekipler daha sonra hataları keşfetti ve bunları düzeltmek için çalıştı. Bu uygulama, ekiplerin yeni özellikler uygulamak yerine hata düzeltmeleri üzerinde çalışması gerektiğinde ekibin moralini ve üretkenliğini etkileyen hataların hız trenini oluşturmuştur.

Teams artık formülüyle # of engineers x 5 = bug caphesaplanan bir hata üst sınırı 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 hata borçlarını kullandıkça ödü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ı olmaya ve ihtiyatlı olmaya ç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 plana uygun .
• Ekipler, etkinlikleri tamamlamak yerine sonuçlara ulaşmaya odaklanır.
• Her ekip düzenli olarak çabalardan sorumludur .

BIR ürünün farklı düzeylerinde OKR'ler olabilir. Örneğin, üst düzey ürün TAMAM'ları, bileşen düzeyi OKR'ler ve ekip düzeyinde OKR'ler 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ında değiştirme
• Olayların sıklığında değişiklik

Ekipler, hedeflere değer tahakkuk ettiren ö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ıma yazma
• Ekip hızı
• Bulunan hata sayısı
• Kod kapsamı

Çevik'in öncesi ve çevik 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 kilometre taşları	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 borcu	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 sevk eder	Özellikler her sprint'i gönderir

Önemli temel bilgiler

• Çevik bilimi ciddiye alın, ancak fazla açıklayıcı olmayın. Çevik çok 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.