Çevik kültürü benimseme
"Çevik dönüşümlerin" son on yılı boyunca öğrenilecek tek bir ders varsa, Çevik yaklaşımı benimsemek veya uygulamak için herkese uygun tek bir çözüm olmadığıdır. Her kuruluşun farklı gereksinimleri, kısıtlamaları ve gereksinimleri vardır. Bir reçeteyi körü körüne takip etmek başarıya yol açmaz.
Çevik hareket, yazılım oluşturma uygulamasını iyileştirmenin yollarını sürekli bulmakla ilgili. Bu, günlük mükemmel bir duruş veya geçmişe dönük bir bakışla ilgili değil. Bunun yerine, doğru şeyin olmamasından çok daha sık gerçekleştiği bir kültür oluşturmaktır. Standup'lar ve geçmişe dönük değerlendirmeler gibi etkinliklerin yeri vardır, ancak bir kuruluşun kültürünü değiştirmezler.
Bu makalede, her kuruluşun Çevik bir zihniyet ve kültür oluşturması için ihtiyaç duyduğu temel öğeler ayrıntılı olarak anlatilmektedir. Önerilere körü körüne uyulmamalıdır. Her kuruluş belirli bir ortamda mantıklı olanı uygulamalıdır.
Mükemmel sprint uzunluğu yoktur. Ekipler, bir ila dört hafta arasında değişen sprint uzunluklarıyla başarılı oldu. En önemli olan tutarlılıktır.
Kuruluşunuzun kültürüne, ürününe ve güncelleştirmeleri sağlama isteğine uygun bir sprint uzunluğu seçin. Örneğin, Microsoft'taki Geliştirici Araçları bölümü (yaklaşık 6.000 kişi) üç haftalık sprint'lerde çalışır. Liderlik ekibi bu sprint uzunluğunu seçmedi; mühendislik ekiplerinin doğrudan geri bildirimlerinden geldi. Tüm bölüm bu üç haftalık sprint zamanlaması üzerinde çalışır. Sprint'ler o zamandan beri kuruluşun sinyali haline geldi. Şimdi her takım aynı davulun vuruşu için yürüyor.
Sprint uzunluğunu seçmek ve buna bağlı kalmak önemlidir. Birden çok Çevik takım varsa, hepsi aynı sprint uzunluğunu kullanmalıdır. Geri bildirim değişikliği yönlendiriyorsa, anlayışlı olun. Doğru terim gerçekleştiğinde netleşir.
Microsoft'un Baş Grup Programı Yöneticisi Peter Provost ,"Sevkiyatta hile yapamazsınız" dedi. Bu ifadenin basitliği ve gerçeği Çevik kültürünün bir köşe taşıdır. Peter'ın demek istediği, yazılımınızı göndermenin size gerçekten yazılımınızı göndermediğiniz sürece anlayamayacağınız ve anlayamayacağınız şeyleri öğreteceğidir.
İnsan doğası gereğine kadar işleri geciktirmek veya yapmaktan kaçınmaktır. Yazılım geliştirme söz konusu olduğunda bu daha doğru olamazdı. Teams, hataları döngünün sonuna kadar sıkıştırır, zorlanana kadar kurulumu veya yükseltmeyi düşünmez ve genellikle mümkün olduğunca yerelleştirme ve erişilebilirlik gibi şeylerden kaçınır. Bu düzen ortaya çıktığında, ekipler daha sonra ödenmesi gereken teknik borçlar oluşturur. Sevkiyat tüm borçların ödenmesini talep ediyor. Sevkiyatta hile yapamazsınız. Çevik bir kültür oluşturmak için, her sprint'in sonunda ürünü göndermeye çalışarak başlayın. İlk başta kolay olmayacaktır, ancak bir ekip bunu denediğinde, olması gereken ama olmayan her şeyi hızla keşfeder.
Mükemmel Çevik ekibin tarifi yoktur. Ancak, birkaç temel özellik başarıyı çok daha kolay hale getirir.
Bir ekip farklı coğrafyalara yayılmış insanlarla başarı bulabilir mi? Evet, ama daha zor. İnsanlar birlikte bulunduğunda ve aynı odada oturduklarında, doğru konuşmalar gerçekleşme eğilimindedir. Dünya genelinde ve farklı saat dilimlerinde bulunan ekiplerle başarılı olmak mümkündür. Ama tüm bu engeller olmadan aynı ekibin bir avantajı olmaz mıydı?
Ekiplerin birlikte yazılım oluşturma sanatına hakim olmasını sağlayın. Ekipler karıştığında, geliştirdikleri tüm kimyalar bozulur. Bazen yeniden düzenleme yapmak uygun olur, ancak ekiplere birlikte çalışmayı öğrenmeleri için zaman verildiğinde genellikle daha üretken olur. Kılavuz olarak, ekipleri en az 12 ay boyunca olduğu gibi tutmaya çalışın.
Bazen takımlar geride kalır ve yardıma ihtiyaç duyar. Bunu ele almak için yaygın bir taktik, bir kişiyi bir ekipten diğerine ödünç vermektir. Ancak, bu ters üretilebilir. Daha iyi bir çözüm, aralarındaki kişileri yük dengelemek yerine başka bir takıma iş yükünü dengelemektir. Bir kişiyi bir ekipten başka bir ekipten başka bir kişiye yardım etmek her iki ekibi de kesintiye uğratabilir ve bu durum geçici olsa bile taşınmakta olan kişiyi hayal kırıklığına uğratabilir. Tüm bunlar ekip üretkenliğini etkiler ve büyük olasılıkla zamanlamada geri dönme becerisini olumsuz yönde etkiler.
Kişiler yerine yük dengeleme çalışması, zaten kurulmuş olan bir ekibin devreye girip yardım etmesine izin verir. Bu, kişiler hakkındaki bir konuşma değil, önceliklerle ilgili bir konuşma haline gelir.
Özellik alanlarına sahip dikey ekipler oluşturmaya çalışın. Bu ekipler, veritabanlarından kullanıcı arabirimi değişikliklerine kadar kendi alanlarına özellik eklemek için gereken tüm çalışmalardan sorumludur. Ekip, uçtan uca deneyim sunma ve bu deneyime sahip olmak için yetkilendirilmiştir.
Yatay takımlar mimari katmanlarına sahip olduğunda, uçtan uca deneyimden tek bir ekip sorumlu değildir. Özellik eklemek için birden çok ekibin eşgüdümlü olması gerekir ve daha yüksek düzeyde bağımlılık yönetimi gerekir. Hataları çözümlemek için birden çok ekibin hatayı düzeltmek için gereken koda sahip olup olmadığını araştırması gerekir. Takımlar hata olmadığını belirleyip başka bir ekime atadığından hatalar dağılır.
Özellik ekiplerinin bu sorunları yoktur. Sahiplik ve sorumluluk açıktır. Bazı mimari tabanlı ekipler için bir yer olabilir. Ancak dikey odaklı ekipler daha etkili olur.
Ekipler kendi Çevik dönüşümlerine başladıkça, bu temel ilkeleri göz önünde bulundurun. Unutmayın, her kuruluş için çalışacak tek bir tarif yoktur. Çevik dönüşümler bir yolculuk. Değişiklikler yapın ve onlardan bilgi edinin. Zamanla kuruluş ihtiyaç duyduğu Çevik kültürü geliştirecektir.
Microsoft, dünyanın en büyük Çevik şirketlerinden biridir. Microsoft'un DevOps planlaması için Çevik kültürü nasıl benimsediği hakkında daha fazla bilgi edinin.
Azure DevOps'un ekiplerin çevik kültürü benimsemesine ve ölçeklendirmesine nasıl olanak sağladığını öğrenin.