Geçenlerde "özellik ekipleri", kalite açısından neden kötü oldukları ve SAFe'nin kopyaladığı iyi fikirleri bulmaya çalışırken insanların gezinmesi için bir mayın tarlası yaratan SAFe tarafından dayatılan kötü fikirlerin bir başka örneği oldukları hakkında bir tartışma yaptım . onların çerçevesi. Scaled Agile Framework'e göre, bir özellik ekibi, kullanıcının bakış açısından uçtan uca eksiksiz bir özellik sunmaya odaklanır. Buna karşılık, bir "bileşen ekibi" belirli iş yeteneklerini sunmaya odaklanır; örneğin vergi hesaplamasına veya envanter yönetimine odaklanan bir ekip.

İlk bakışta, kaynak kullanımını optimize etme açısından bu iyi görünüyor. Biriktirme listesindeki özellikler akışına ekipler atayabilir ve herkesi meşgul edebiliriz. Ancak bu, ekipler arasındaki iletişim sorunlarının etkisini, birleştirme çatışmalarının nasıl çözüleceğini, sistemle ilgili her şeyi anlamanın bilişsel yükünü vb. göz ardı eder. Yukarıdaki şemaları, birden fazla ekibin katkıda bulunmasına olanak tanıyan herhangi bir uygulamanın karmaşıklığını en aza indirir. tüm uygulama genelinde silolar halinde işi koordine etmeye çalışan üç, dört veya daha fazla ekibin tam yığınına veya etkisine ve karmaşıklığına.

Geçmişte kişisel olarak bu şekilde çalıştım ve kod entegrasyonunu koordine etmeye yardım etmem gerekti. Bu kalıp aynı zamanda, iletişimin uygulama mimarisi üzerindeki etkisi ve "sen inşa et, sen çalıştır"ın kalite ve kararlılık üzerindeki olumlu etkisi hakkında 50 yılı aşkın süredir bildiğimiz her şeyi göz ardı eder. Bu, bizi bu modelin göz ardı ettiği başka bir şeye getiriyor, kullanımı en üst düzeye çıkarmak amaç değil. Değer sunmak amaçtır. Değer sunmak, teslim edebileceğimiz, hızlı geri bildirim alabileceğimiz ve uyum sağlayabileceğimiz anlamına gelir. Aynı zamanda hızlı tepki verdiğimiz ve başarısızlığı düzelttiğimiz anlamına gelir. Bu iki yetenek birbirine sıkı sıkıya bağlıdır ve daha iyi bir organizasyonel tasarım gerektirir.

Birisi bana, "Buna güvenenlerin direnç bölgesini düşürmeye yardımcı olmak için tercih edilen alternatif nedir?" diye sordu.

Alternatif, iş hedeflerini açıkça belirtmek ve ardından organizasyonu bu sonuçları elde etmek için en az direniş yolunu izleyecek şekilde tasarlamaktır. Sondan başlayın ve geriye doğru çalışın.

Hedef: Ortalama Onarım Süremizi (MTTR) iyileştirin

Bir Formula 1 yarış arabasının birincil tasarım endişesi, pit stop süresini en aza indirmektir. Ayrıca, bu tasarım öğelerinden en etkili şekilde yararlanmak için gereken ekip çalışmasını uygularlar. Sonuç olarak, F1'de pit stopları ortalama 3 saniyenin altında. Yazılımda da benzer bir sorunumuz var. Yazılımın yararlı olması için insanların ona güvenmesi gerekir, bu nedenle işler ters gittiğinde hızla toparlanabilmemiz gerekir. MTTR'yi düşük tutmak için sistemin kolayca düzeltilmesine ihtiyacımız var. Bunu mümkün kılan araçlara, bilgiye, davranışlara ve uygulama mimarisine ihtiyacımız var. Bunları sağlayan organizasyon yapısına da ihtiyacımız var. Hızlı yanıt verme yeteneğini tasarladığımızda, yeni değişiklikler sunmak ve yeni özelliklerle ilgili geri bildirimlere hızla yanıt vermek için bu beceriden yararlanabiliriz.

Teslimatı Standartlaştırın

Başarısızlıktan hızlı bir şekilde kurtulmak, acil bir durumda güvenli ve hızlı değişiklikler sunmanın güvenilir bir yolunu gerektirir. Bu süreci uçtan uca otomatik hale getirmek, stres altında manuel adımları yürütürken yapılan hatalardan kaynaklanan sapmalara yol açmamamızı sağlar. Ayrıca acil durum düzeltme sürecimizin her zaman hazır olduğundan emin olmalıyız. Olmadığını keşfetmenin en kötü zamanı acil bir durumdur. Bunu, tüm değişiklikleri iletmek için yalnızca acil durum sürecimizi kullanarak yapıyoruz. Bu, yalnızca hızlı yanıt verme yeteneğimizi sürekli olarak geliştirmemize yardımcı olmakla kalmaz, aynı zamanda tüm değişiklikler için tek bir iş akışına sahip olmak için başka bir kusur oluşturan varyans kaynağını da ortadan kaldırır. Operasyonel destek için boru hattını optimize etmeye devam ederken, aynı zamanda değişim maliyetini de sürekli olarak azaltır.

Operasyonlar için Tasarım

Teslimat boru hattımız özellik sıfırdır. Bir sonraki endişe gözlemlenebilirliktir. Bu, ilk teslimattan itibaren pişirilmelidir, daha sonraki bir tarihte "işimiz bittikten" sonra endişe duyacağımız bir şey değil. Uygulama, arıza meydana geldiğinde veya meydana gelmek üzereyken bizi uyarmalıdır. Umarım, olası dış etkiler için de tasarlamışızdır ve bağımlılıklar başarısız olduğunda özellikleri zarif bir şekilde düşürebiliriz (Hiçbir donanım veya yazılım bağımlılığına asla güvenmem). Kodun anlaşılması kolay olduğu için nerede ve neyin düzeltileceğini belirlemek kolay olmalıdır. Modüler tasarım ve temiz mimari, karmaşıklığı düşük tutar ve sistemin düzeltilmesini kolaylaştırır. Ayrıca, onu anlayan uygulamayı destekleyen bir ekibe ihtiyacımız var.

Bir Destek Organizasyonu Kurun

Bir olay sırasında keşif için gereken süreyi en aza indirmek için bir şeyin nerede ve neyin bozulduğunu hızlı bir şekilde belirleyebilen ekiplere ihtiyacımız var. Bir ekibin bir şeyin nerede bozulduğunu hızlı bir şekilde belirlemesi için uygulamanın çözdüğü sorunu, nasıl çözdüğünü ve kodun mimarisini ve kültürünü anlaması gerekir. Küçük uygulamalar için bu çok zor değil. Tek bir ekip uygulamayı destekleyebilir ve ona çok aşina olabilir. Daha büyük uygulamalar için stratejik Etki Alanı Odaklı Tasarımdan yararlanıyoruz.

Destek ekiplerini, etki alanı uzmanları ve destekledikleri etki alanlarını uygulayan kod uzmanı olabilmeleri için kasıtlı olarak belirli iş yeteneklerine uygun hale getiriyoruz. Conway Yasasını göz önünde bulundurarak , aynı ekibin yakından ilişkili bileşenleri desteklediğinden ve gevşek bir şekilde bağlı tutmak istediğimiz bileşenleri farklı ekiplere koyduğumuzdan emin oluruz. Bu, bilişsel yükü azaltır ve ekibin istenen mimariyi korurken üretim sorunlarını hızla ele almasını sağlar.

Uygulamayı Geliştirmek

Uygulamanın kullanışlı kalması için, biz daha fazla şey öğrendikçe ve kullanıcıların ihtiyaçları değiştikçe gelişmesi kolay olmalıdır. Ayrıca istikrarımızı bozmadan sistemi hızla geliştirebilecek bir ekip oluşturmamız gerekiyor. Ekiplerin uygulamaya rastgele yeni özellikler eklemesini istemiyoruz, aksi takdirde mimari bozulur ve teknoloji borcu artar. Bu onlarca yıldır kanıtlanmıştır. Conway Yasası her zaman geçerlidir. Bir ekibin, işlemleri düşürmeden uygulamayı hızlı bir şekilde geliştirmesi için, etki alanı uzmanları ve yükselttikleri etki alanlarını uygulayan kod konusunda uzman olmaları gerekir. Destek ekibinin olayları hızlı bir şekilde düzeltmesini sağlamak için aynı gereksinim olduğuna dikkat edin.

Neden iki takım?

Bu iyi bir soru. Neden bir ekibin uygulamaya yeni özellikler eklemesini ve diğerinin hata düzeltmelerini yapmasını istiyoruz? yapmıyoruz. Bu, iletişim sorunlarına neden olur, geliştirme ekibinden gelen değerli kalite geri bildirimlerini gizler ve kaçınılmaz olarak teknoloji borcunu artırarak uygulamanın değiştirilmesini zorlaştırır. Ayrıca, "kusur" ile "yeni özellik" arasındaki farkı da göz önünde bulundurun. Yeni bir özellik eklemenin tek nedeni, uygulamanın gerektiği gibi davranmaması veya performans göstermemesidir. Bu, bir kusurla tam olarak aynı tanımdır. Kusur ve özellik arasındaki fark yalnızca önceliktir. İki ekip uygulamayı bağımsız olarak "düzeltiyorsa", kalite ve kalite geri bildirimini düşüren iletişim sorunları için iki doğruluk kaynağımız vardır. Bu, özellik ekiplerinde yaşadığımız sorunun aynısıdır.

Sistemin kararlılığı hakkında en iyi görüşe ve onu kullanma konusunda en fazla deneyime sahip olan ekip, aynı zamanda yeni özellikler eklemek için en nitelikli ekiptir. Sistemi en iyi onlar bilirler, sorun alanını anlarlar ve en çok sorunları ilk duydukları için teslim edilen sonuçları önemserler. Bu nedenle, bariz seçim, geliştirme ekibini ortadan kaldırmak ve iş yeteneğini destekleyen ekibe onu yükseltme yetkisi vermektir.

Site Güvenilirliği Mühendisleri ne olacak?

Bir SRE grup işleme desteğimiz olması gerekmez mi?

SRE'lerin uygulama desteği yoktur. SRE'ler, ekibin uygulamalarını daha güvenilir hale getirebilmesi için ürün ekipleriyle birlikte çalışarak geri bildirim sağlar. Bir sorun olduğunda bunu bilen ilk kişiler onlardır, ancak çözümün sahibi onlar değildir. Ekibin uygulaması, SRE ekibinin çok fazla ilgilenmesini gerektirecek kadar kararsız hale gelirse, istikrar için ekibe geri gönderilir. Kurban değiller.

Ama üretime erişimim yok!

Üretimden geri bildirime en çok ihtiyaç duyan kişilerin her zaman erişimi olmadığını belirtmekte fayda var. Kararlılık, işlevsellik vb. hakkında geri bildirim alma yeteneği olmadan bir şey inşa etmek beni korkutuyor. Bunu daha önce yapmak zorunda kaldım. Hep gözyaşıyla biter. Üretime erişiminiz yoksa, bu riski azaltmanın bir yolunu bulmanız gerekir. "Doğru şeyi mi yapıyoruz?" konusunda geri bildirim almak için elinizden geleni yapın. ve "doğru şekilde inşa ediliyor mu?" Üretime uygun bir ortam elde edebilir miyiz? Hedef kullanıcılardan geri bildirim almanın bir yolu var mı? Üretim benzeri bir ortamda değiştirilen ancak doğrulanmayan her kod satırı bir risk ve potansiyel bir kusurdur. Gözün üstünde olsun.

Yanlış Şeyler İçin Optimizasyon

Birçok kuruluş, Yönetim Deneyimi (ManEx) veya kullanımı veya çıktıyı en üst düzeye çıkarma arzusu etrafında tasarlanmıştır, ancak bu hedeflerin hiçbiri kullanıcıların sorunlarını etkili bir şekilde çözmez.

Çalıştığım önceki bir kuruluş, geliştirme ekiplerinin üretim desteğinin "dikkatini dağıtmasını" ortadan kaldırarak "geliştirici üretkenliğini artırmaya" karar verdi. Orijinal süreçte, çağrı merkezi, destek ekibine sağladıkları oyun kitaplarının çalışmadığını çalıştırdıktan sonra geliştirici ekipleri arayacaktı. Yeni “geliştirilmiş” süreçte destek, Tier 1 ve 2 desteğinden sorumlu farklı bir raporlama yapısı altında tamamen farklı bir organizasyondu ve geliştirme ekipleri Tier 3 idi. Bu, kullanıcı deneyimini kötüleştirdi.

Ani etki, bir olaydan sonraki 15 dakika içinde bir geliştirme ekibinin aranması yerine, sorunun yaklaşık 90 dakikasında çağrıldık. Daha sonra, gecenin bir yarısı sorunu çözmeye yardımcı olabilmemiz için sorunun bağlamı hakkında bilgi sahibi olmamız gerekiyordu. Bu, kesinti sürelerini uzattı ve genellikle düşmanca kullanıcılarla uğraştığımız anlamına geliyordu. Artık daha küçük sorunları görmediğimiz için, yeni ekip üyelerini daha düşük etkili sorunları kullanarak destek konusunda eğitme yeteneğimizi de kaybettik. Bunun yerine, destek kuruluşu sisteme yama uygulamak veya hatta koda bir düzeltme dağıtmak için bir komut dosyası yazar. Bu, düşük seviyeli sorunları geliştirme ekiplerinden sakladı. Bu kalite geri bildirimi eksikliği, geliştirme devam ederken küçük kusurların büyük kusurlara dönüştüğü ve yeni kodun üzerine inşa edildiği düşük seviyeli sorunlara kör olduğu anlamına geliyordu. Bunu, özellik ekiplerinden ürün ekiplerini yeniden düzenleyerek, bir CD iş akışına geçerek ve destek kuruluşunun kaldırabileceğinden daha hızlı değişiklikler yaparak çözdük. Bu, desteğin varsayılan olarak bize geri döndüğü, çok daha kaliteli geri bildirim aldığımız ve olaylara yanıt verebildiğimiz ve sistemi çok daha hızlı geliştirebildiğimiz anlamına geliyordu.

SAFe'den geri bildirim

SAFe tarafından öne sürülen birçok anti-kalıptan birinin bir örneği olarak özellik ekipleri için SAFe tavsiyesini yayınladığımda, bir "Sertifikalı SAFe Uygulama Danışmanı" yanıt verdi.

Özellik fabrikası modelinin, yalnızca belirli hizmet çıktıları sunan ve uçtan uca iş sonuçlarıyla bağlantısı olmayan DDD tabanlı iş hizmeti (bileşen) ekipleriyle en az bu kadar kötü olduğunu iddia ediyorum, çünkü bunlar yalnızca başarılı E2E entegrasyonuyla elde edilebilir. ilgili her bir hizmetten oluşur ve bu daha geniş vizyondan/sonuçtan tek bir [bileşen] sorumlu değildir.

Bunu iddia edebilirler, ancak hiçbir kanıt sunmadılar. Bu onlara mantıklı gelebilir çünkü aynı zamanda insanların üzerinde çalışacakları kadarına sahip olmalarını sağlama konusunda da yorumda bulundular. Amacımız bu değil. Operasyonel istikrar ve hızlı gelişim hedeflerimizdir.

Her iki modeli de kullanarak yıllarca çalıştım. Yetenekler etrafında organize edilmiş, çalıştığım her büyük sistemde, her ekip, hem sürekli üst düzey yol haritası tartışmaları hem de bileşenler arasındaki etkileşimi gösteren alan diyagramları nedeniyle bileşenlerinin daha büyük bütüne nasıl uyduğunu biliyordu. Ekipler, sözleşme değişikliklerini eşzamansız teslimatı etkinleştirecek ve birlikte çalışabilirliği sağlayacak şekilde koordine etmek için birbirleriyle görüştüler. Ekipler, uygunsuz mutasyonu önlemek için verilerin nasıl kullanılacağını anladı. Akış veya bilgi için birden fazla doğruluk kaynağı oluşturan hiçbir yetenek çakışması yoktu. Koordinasyon kolaydı çünkü ekiplerin tüm sistemle değil, yalnızca arayüzleri paylaştığı ekiplerle koordinasyona ihtiyacı vardı. Kalite yüksekti çünkü her takım doğumdan ölüme kadar kendi yeteneklerine sahipti. Amazon ve NetFlix de tam olarak böyle çalışır. Hiçbiri SAFe kullanmaz. Her ikisi de ölçekte çeviktir çünkü ölçeği süreçle değil mühendislikle yönetirler.

Sonuçlar için Tasarım

“Sen inşa et; kasıtlı olarak tasarlanmış bileşen ekipleriyle , özellik ekipleriyle Jenga Odaklı Geliştirmeden daha yüksek kalite sunar . Yine de insanların bunun ne anlama geldiğini anlamaları önemlidir. Bu, ekibin tüm altyapı ve teslimat sorunlarının sahibi olduğu anlamına gelmez; iyi self-servis platformları bunun içindir. Zarf gibi araçlar, değişmez ve tekrarlanabilir bir sistem yapılandırması oluşturarak çevreyi sağlıklı tutma çabasını ve bilişsel yükünü azaltmaya yardımcı olabilir.

Operasyonlardan geriye doğru çalışmak, odağımızı ait olduğu yere, istikrarlı değer teslimine yerleştirir. Ürünü kullananlara en yakın kişiler, ürünün nasıl geliştirileceğini en iyi bilen kişilerdir. Bir veya daha fazla ürün yeteneğine sahip olan, bunları nasıl sunacaklarına ve kararlarının sonuçlarına sahip olan ekipler kuruyoruz, böylece sahip olduklarını hızla geliştirip onarabiliyorlar. Ekipleri çıktı için değil değer sahipliği için tasarlıyoruz ve kaliteli geri bildirim için temiz iletişim yollarına sahip olmalarını sağlıyoruz.