Komuta ve Kontrol, SAFe, Etki Alanına Dayalı Tasarım ve Sürüm Trenleri
Büyük karmaşık projelerin yönetilmesi zordur. Yazılım sürüm trenleri bir koordinasyon çözümüdür. Ancak yaklaşım, öz-örgütlenme ve modern yönetim kavramlarına aykırıdır.
Birkaç bağımlı projeyi koordine etmek için bir serbest bırakma dizisi kullanılır. Bunun bir parçası olarak, tüm projeler, beta testi, sürüm veya güncelleme gibi aşamalardan birlikte geçen koordineli sürümler geliştirir. Fikir, Eclipse, Ubuntu, Spring Framework veya LibreOffice gibi birçok büyük projede kendini kanıtlamıştır.
Ölçekli Çevik Çerçeve (SAFe), birden fazla çevik ekibin çalışmasını koordine etmek için bir Çevik Sürüm Treni önerir. Her iki haftada bir sistem demosu ile yeni bir sistem artışı sunmak ve sunmak için sabit bir zamanları vardır. Çevik Sürüm Treni, yazılım geliştirmeyi koordine eder ve ardından kullanıcıların yeni özellikleri kullanabilecekleri sürümü yayınlar. Bu, birden fazla ekipte bir veya daha fazla temel özelliğin geliştirilmesini koordine etmekle ilgilidir. Amaç, yalnızca bireysel ekiplerin değil, tüm sistemin düzenli olarak yeni özellikler uygulamasıdır. Bu, daha büyük özelliklerle ilgili olası sorunları ortaya çıkarmalıdır. Doğal olarak, bir Agile Release Train’in merkezi koordinasyonu için çeşitli roller vardır.
İşbirliği için koordinasyon her zaman gereklidir, ancak aynı zamanda ek yük de oluşturur. Merkezi koordinasyon, mümkün olduğu kadar çok sorumluluk devretmekle çelişir. Modern organizasyonlar mümkün olduğunca az hiyerarşiye sahip olmalı ve ekipler, merkezi koordinasyon ve komuta ve kontrole bağlı olmak yerine kendi kendine organize bir şekilde çalışmalıdır. Organizasyon, merkezi kontrol olmadan daha da iyi ölçeklenir.
Koordinasyon yerine mimari!
Aşırı koordinasyon organizasyonel bir sorun olsa da temel neden bir mimari sorunu olabilir: Bir müşteriye değer katan değişiklikler birden fazla ekip ve bileşenin koordinasyonunu gerektirdiğinde, daha iyi teknik uyum ilgili bileşen sayısını azaltabilir ve dolayısıyla ekipleri azaltabilir. Etki alanına dayalı tasarım, bunun için bir dizi önlem önermektedir. Çevik sürüm trenindeki koordinasyon çok karmaşıksa, kesinlikle mimariye bir göz atmaya ve optimizasyon potansiyeli olup olmadığına bakmaya değer.
Ancak yazılım mimarisi mükemmel olsa bile, bir özellik birden çok ekibi etkileyen değişiklikler gerektirebilir. Sonuçta ekipler bir sistem üzerinde birlikte çalışır ve bu nedenle özellikler her zaman birden çok ekip arasında dağıtılabilir. Etki alanına dayalı tasarım da bunun için çeşitli modeller önerir. Müşteri/Tedarikçi modelinde Müşteri ekibi, Tedarikçi ekibinden özellikleri uygulamasını talep edebilir. Alternatif “konformist”tir – bu nedenle ekip aldıklarını almak zorundadır ve özellik sunumlarını talep edemez.
Böylece bir DDD ekibi, taşeronlaşmaya dayalı olsa bile bir özelliği uygulayabilir. Bunun için müşteri/tedarikçi gibi takımlar arasında sadece “oyunun kurallarının” tanımlanması gerekiyor. Elbette, bir uyuşmazlık üst merciinin tanımlanması gerekebilir, ancak normal şartlar altında ekipler merkezi koordinasyon olmadan çalışabilir ve birbirleriyle merkezi olmayan bir şekilde koordine olabilir.
Ortaklık: çok yakın bir bağ mı?
Agile Release Train’e benzer özelliklerin işbirlikçi gelişimi de DDD’de mevcuttur. DDD bunu bir “ortaklık” olarak tanımlıyor. Bir ortaklığın aslında olumlu bir çağrışımı vardır. DDD referansının İngilizce baskısı, ortaklığı göstermek için üç aşamalı bir yarış, yani katılımcıların bir etapla birbirine bağlandığı bir yarış kullanır. Böyle bir ortaklık ve bunun sonucunda ortaya çıkan yakın koordinasyon, Çevik Serbest Bırakma Treninden bekleneceği gibi bir sorun yaratma eğilimindedir.
Çözüm
Agile Release Trains tarafından uygulananlar gibi yakın merkezi koordinasyon, iyi bir yazılım mimarisi ile kesinlikle gerekli olmamalıdır ve başka yollarla engellenebilir. Belki de algılanan güvenlik, SAFe gibi yaklaşımların başarılı olmasının bir nedenidir. Koordinasyon, genel proje düzeyinde ilerlemenin izlenmesini mümkün ve gerekli kılar. Bu daha fazla güvenlik sağlayabilir. Ekiplere gerçekten sorumluluk devretmek ise yüksek düzeyde güven gerektirir.
tl; doktor
İndirme trenleri, birkaç ekibin işbirliğini koordine eder. Etki alanına dayalı tasarım yaklaşımları ise ekiplere daha fazla sorumluluk devreder ve bu nedenle daha az koordinasyon gerektirir.
Makalenin önceki bir versiyonuna yaptıkları yorumlar için meslektaşlarım Anja Kammer, Martin Kühl, Torsten Mandry, Sebastian Schwaiger ve Benjamin Wolf’a çok teşekkürler.
()
Haberin Sonu