Çevik'i büyük ekiplere ölçeklendirme

Büyük ve Çevik sözcükleri genellikle aynı cümlede kullanılmaz. Büyük kuruluşlar yavaş hareket ediyor olma ününü kazanmıştır. Ancak bu durum değişiyor. Birçok büyük yazılım kuruluşu Çevik'e dönüştürmeyi başarıyla gerçekleştirmektedir. SAFe, LeSS veya Nexus gibi popüler çerçevelerle veya çerçeveler olmadan Çevik ilkelerini ölçeklendirmeyi öğreniyorlar.

Microsoft'ta bu tür bir kuruluş, Azure DevOps markası altında gönderilen ürün ve hizmetleri oluşturmak için Çevik'i kullanır. Bu grubun üç haftada bir üretime sunulan 35 özellik ekibi vardır.

Azure DevOps'taki tüm ekipler baştan sona ve ötesine kadar özelliklere sahip olur. Müşteri ilişkilerine sahipler. Kendi ürün kapsamlarını yönetirler. Üretim dalında kod yazar ve denetler. Üç haftada bir üretim dalı dağıtılır ve yayın herkese açık hale gelir. Ekipler daha sonra sistem durumunu izler ve canlı site sorunlarını çözer.

Çevik ilkelerine göre, otonom ekipler daha üretkendir. Çevik bir kuruluş, ekiplerinin günlük yürütmeleri üzerinde denetim sahibi olmasını ister. Ama hizalama olmadan özerklik kaosa yol açabilir. Bağımsız çalışan onlarca ekip birleşik, yüksek kaliteli bir ürün üretmez. Hizalama, ekiplere amaçlarını sağlar ve kuruluş hedeflerine ulaşmalarını sağlar. Hizalama olmadan, en iyi performans gösteren takımlar bile başarısız olur.

Çevik'i ölçeklendirmek için, kuruluşla uyumlu olmasını sağlarken ekip için özerkliği etkinleştirmeniz gerekir.

Hizalama ve özerklik arasındaki hassas dengeyi yönetmek için DevOps liderlerinin taksonomi tanımlaması, planlama süreci tanımlaması ve özellik sohbetlerini kullanması gerekir.

Taksonomi tanımlama

Çevik bir ekibin ve üyesi olduğu daha büyük Çevik kuruluşun başarılı olması için net bir şekilde tanımlanmış bir kapsam gerekir. Kuruluş hedefleri belirsizse ekipler başarılı olmakta zorlanır.

Net hedefler belirlemek ve her ekibin bunlara nasıl katkıda bulunup bulunmadığını belirtmek için kuruluşun bir taksonomi tanımlaması gerekir. Açıkça tanımlanmış bir taksonomi, bir kuruluş için sıfat oluşturur.

Yaygın taksonomilerden biri destanlar, özellikler, hikayeler ve görevlerdir.

Epic’ler

Epic'ler, kuruluşun başarısı için önemli olan girişimleri açıklar. Epic'lerin tamamlanması için birkaç takım ve birkaç sprint gerekebilir, ancak bunlar bitemez. Epic'lerin açıkça tanımlanmış bir hedefi vardır. Bir kez elde edildikten sonra destan kapatılır. Kuruluşun odaklanması için devam eden epic'lerin sayısı yönetilebilir olmalıdır. Epic'ler özelliklere ayrılır.

Özellikler

Özellikler, bir epic'in hedefini gerçekleştirmek için gereken yeni işlevleri tanımlar. Özellikler yayın birimidir; müşteriye yayınlananları temsil ederler. Yayımlanan sürüm notları, yakın zamanda tamamlanan özellikler listesine göre oluşturulabilir. Özelliklerin tamamlanması birden çok sprint alabilir, ancak müşteriye tutarlı bir değer akışı sağlamak için boyutlandırılmalıdır. Özellikler hikayelere ayrılmıştır.

Hikayeler

Hikayeler, bir özellik oluşturmak için takımın sağlaması gereken artımlı değeri tanımlar. Ekip özelliği artımlı parçalara ayırır. Tamamlanan tek bir hikaye müşteriye anlamlı bir değer sağlamayabilir. Ancak tamamlanmış bir hikaye, üretim kalitesinde yazılımları temsil eder. Hikayeler, ekibin çalışma birimidir. Ekip, bir özelliği tamamlamak için gereken hikayeleri tanımlar. Hikayeler isteğe bağlı olarak görevlere ayrılır.

Görevler

Görevler, bir yazıyı tamamlamak için gereken çalışmayı tanımlar.

Girişimler

Bu taksonomi, her boyuta uyan tek bir sistem değildir. Birçok kuruluş girişim olarak adlandırılan epic'lerin üzerinde bir düzey tanıtır.

Her düzeyin adları kuruluşunuza özelleştirilebilir. Ancak yukarıda tanımlanan adlar (epic'ler, özellikler, hikayeler) sektörde yaygın olarak kullanılmaktadır.

Özerklik çizgisi

Taksonomi ayarlandıktan sonra kuruluşun bir özerklik çizgisi çizmesi gerekir. Özerklik çizgisi, düzeyin sahipliğinin yönetimden ekiliğe geçtiği noktadır. Yönetim, ekibin sahip olduğu düzeylerle karışmaz.

Aşağıdaki örnek, aşağıdaki özelliklerin çizildiği özerklik çizgisini gösterir. Yönetim, hizalama sağlayan epic'lere ve özelliklere sahiptir. Ekiplerin kendi hikayeleri ve görevleri vardır ve yürütme yöntemleri üzerinde özerklik sahibidir.

Bu örnekte yönetim, takıma öyküleri ayrıştırma, sprint planlama veya çalışma yürütme adımlarını anlatmaz.

Ancak ekip, yürütmelerinin yönetimin hedeflerine uygun olduğundan emin olmalıdır. Bir ekip hikaye kapsamına sahip olsa da, kapsamlarını kendilerine atanan özelliklerle uyumlu hale getirmesi gerekir.

Planlama

Çevik planlamayı ölçeklendirmek için ekibin taksonominin her düzeyi için bir plana ihtiyacı vardır. Ancak, planı yinelemek ve güncelleştirmek önemlidir. Bu işleme dalgalı planlama denir.

Plan, düzenli aralıklarla beklenen kalibrasyon ile sabit bir süre için yön sağlar. Örneğin, altı ayda bir 18 aylık bir plan ayarlanabilir.

Aşağıda taksonominin her düzeyi için planlama yöntemleri örneği verilmiştir: epic'ler, özellikler, hikayeler, görevler.

Görsel

Vizyon epic'ler aracılığıyla ifade edilir ve kuruluşun uzun vadeli yönünü belirler. Epic'ler, kuruluşun önümüzdeki 18 ay içinde neleri tamamlamak istediğini tanımlar. Yönetim, plana sahip olur ve her altı ayda bir bu planı kalibre eder.

Vizyon, el ele bir toplantıda sunulur. Vizyonun iddialı olması amaçlandığından ve bu süre içinde çok şey değişeebildiğinden, vizyonun yaklaşık %60'ını gerçekleştirmeyi bekleyebilirsiniz.

Mevsim

Bir sezon özelliklerle açıklanır ve önümüzdeki altı ay için stratejiyi belirler. Özellikler, kuruluşun müşterileri için neleri aydınlatmak istediğini belirler. Yönetim, mevsimsel planın sahibidir ve vizyon ve mevsimsel planları el ele bir toplantıda sunar. Tüm ekip planları yönetimin mevsimsel planıyla uyumlu olmalıdır. Mevsimsel planın yaklaşık %80'ini gerçekleştirmeyi bekleyebilirsiniz.

3 sprint planı

3 sprint planı, ekibin sonraki üç sprint'in tamamlanacağı hikayeleri ve özellikleri tanımlar. Ekip, plana sahip olur ve her sprint'i kalibre eder. Her ekip, planlarını özellik sohbeti aracılığıyla yönetime sunar (aşağıya bakın). Plan, ekibin yürütmesinin 6 aylık mevsimsel planla nasıl uyumlu olduğunu belirtir. 3 sprint planının yaklaşık %90'ını gerçekleştirmeyi bekleyebilirsiniz.

Sprint planı

Sprint planı, ekibin sonraki sprint'te tamamlanacağı hikayeleri ve özellikleri tanımlar. Ekip sprint planının sahibidir ve tam saydamlık için tüm kuruluşa e-posta ile gönderir. Plan, takımın geçmiş sprint'te neler başarmış olduğunu ve bir sonraki sprint'e odaklanmasını içerir. Sprint planının yaklaşık %95'ini gerçekleştirmeyi bekleyebilirsiniz.

Özerklik çizgisi

Bu örnekte, ekiplerin özerklik planlamasının nerede olduğunu göstermek için özerklik çizgisi çizilmiştir.

Yukarıda belirtildiği gibi yönetim, sahipliği özerklik çizgisinin altına uzatmaz. Yönetim, vizyon ve sezon planlarını kullanarak rehberlik sağlar ve ardından ekiplere 3 sprint ve sprint planları oluşturmak için özerklik sağlar.

Özellik sohbetleri: Özerklik hizalamayla karşılaşıyor

Özellik sohbeti , her ekibin 3 sprint planını yönetime sunduğu düşük törenli bir toplantıdır. Bu toplantı, ekip planlarının kuruluş hedefleriyle uyumlu olmasını sağlar. Ayrıca yönetimin ekibin yaptıkları hakkında bilgi sahibi kalmasına da yardımcı olur. 3 sprint planı her sprint'in ayarlanmasına karşın, özellik sohbetleri genellikle bire üç sprint'lerde gerektiği gibi tutulur.

Özellik sohbeti toplantısı her ekibİ 15 dakika ayırır. 12 özellik ekibiyle bu toplantılar yaklaşık üç saat sürecek şekilde zamanlanabilir. Her ekip aşağıdaki slaytlarla birlikte 3 slaytlık bir deste hazırlar:

Özellikler

İlk slaytta, ekibin sonraki üç sprint'te yanacağı özellikler özetlenir.

Borç

Sonraki slaytta ekibin teknik borcu nasıl yönettiği açıklanmaktadır. Borç, yönetimin kalite çubuklarına uymayan bir şey. Mühendislik direktörü, tüm ekipler (hizalama) için aynı olan kalite çubuklarını ayarlar. Örnek kalite çubukları mühendis başına hata sayısını, birim testlerinin geçirme yüzdesini ve performans hedeflerini içerir.

Sorunlar ve bağımlılıklar

Son slaytta listelenen sorunlar ve bağımlılıklar, ekibin çözümleyememe sorunları veya yükseltme gerektiren diğer takımlara bağımlılıklar gibi ekip ilerleme durumunu etkileyen her şeyi içerir.

Her ekip slaytlarını doğrudan yönetime sunar. Ekip, 3 sprint planının 6 aylık mevsimsel planla nasıl uyumlu olduğunu sunar. Liderlik, net sorular sorar ve yönde değişiklikler önerir. Ayrıca daha derin sorunları çözmek için izleme toplantıları isteyebilirler.

Bir ekibin planı yönetimin beklentilerine uygun olmazsa, yönetim yeniden plan isteyebilir. Bu nadir durumda ekip, gözden geçirmek için ikinci bir özellik sohbetini yeniden planlayacak ve zamanlayacak.

Güven: Hizalamayı ve özerkliği bir arada tutan tutkal

Çevik'i uygun ölçekte çalışırken güven iki yönlü bir yoldur:

• Yönetimin doğru şeyi yapmak için ekiplere güvenmesi gerekir. Yönetim ekiplere güvenmiyorsa, ekiplere özerklik vermez.

• Ekip, sürekli olarak yüksek kaliteli kodlar sunarak güven kazanır. Ekipler güvenilir değilse, yönetim onlara özerklik vermez.

Yönetim, ekiplerin yürütülecek ekiplerle uyumlu olması ve ardından bu ekiplere güvenmesi için net planlar sağlamalıdır. Ekiplerin planlarını kuruluşla uyumlu hale getirmesi ve güvenilir bir şekilde yürütmesi gerekir.

Kuruluşlar Çevik'i daha büyük senaryolara ölçeklendirmeye çalışırken, önemli olan ekiplere özerklik sağlarken kurumsal hedeflerle uyumlu olduklarından emin olmaktır. Kritik yapı taşları açıkça tanımlanmış sahiplik ve güven kültürü olarak tanımlanır. Bir kuruluş bu temele sahip olduktan sonra Çevik'in çok iyi ölçeklenebileceğini fark ederler.

Sonraki adımlar

Her büyüklükteki bir ekibin bugün avantajları görmeye başlamasının birçok yolu vardır. Ölçeklendirilen bu uygulamalardan bazılarını gözden geçirin.

Ekipler arasında portföy yönetimi ve görünürlük için Azure DevOps özellikleri hakkında bilgi edinin.

Microsoft, dünyanın en büyük Çevik şirketlerinden biridir. Microsoft'un DevOps planlama ölçeği hakkında daha fazla bilgi edinin.