İki Scrum takımı aynı yazılım bileşenini kullanıyorsa, bu bileşenin net bir mimari vizyonunu sağlamaktan ve kod tabanı geliştikçe bu vizyonu sürdürmekten / geliştirmekten kim sorumludur? Scrum'da kolektif bir kod sahipliğiniz olması gerekiyor, bu nedenle A Ekibi tarafından yapılan geliştirmenin B Ekibi tarafından yapılan geliştirmeye müdahale etmediğinden nasıl emin olabilirsiniz?
Yanıtlar:
Ben bir Scrum uzmanı değilim, ancak AFAIK "kolektif kod sahipliği" ekip başına ve ürün başına (ve sorunuzun Scrum'a özgü olmadığını düşünüyorum, herhangi bir "paylaşılan kod" geliştirme sürecine uygulanabilir).
İki A, B ekibiniz, iki A, B ürünü ve paylaşılan bir C bileşeniniz varsa, farklı olası senaryolar vardır. Belki de paylaşılan bileşen öncelikle A ürününe aittir (ve B ürünü için ekip tarafından yeniden kullanılır, ancak geliştirilmez). Bu durumda A takımı mimari vizyondan açıkça sorumludur. Ya da tam tersi: açıkça B ürününe aittir - bu yüzden sorumluluk oradadır. A takımı sorumluysa, B takımı acil hata düzeltmelerine izin vermek için bileşenin çatalını kullanabilir (bunları C'nin ana hattına yeniden entegre etmenin bir yolu da olmalıdır), ancak B, bileşenin daha büyük bir gelişiminden kaçınmalıdır.
Bununla birlikte, hem A hem de B ürünlerinde C için çok fazla "sürüş gereksinimi" varsa, C'yi kendi sürüm oluşturma, sürüm yönetimi, değişiklik yönetimi, birim testleri vb.İle tamamen ayrı bir ürün olarak yönetmelisiniz. bu bileşen için sorumluluk. Bu ekip sadece A, B veya her ikisinden ayrı geliştiricilerden oluşan bir "sanal ekip" olabilir. Bu ekip, C için "paylaşılan kod sahipliği" ve "mimari vizyon" sorumluluğuna sahiptir. Sadece üçüncü taraf bir satıcı tarafından teslim edilen bir bileşeni düşünün.
Scrum veya çevikte "açık mimari vizyon" kavramı yoktur!
Uzun zamandır bir mimarım ve mimari vizyona sahip olmak için gelecekteki gereksinimler hakkında net bir görüşe sahip olmamız gerektiği açık. Çoğu durumda gereksinimler hiç belli olmadığından, sabit bir vizyona sahip olmak mantıklı değildir.
Gerekli olan, değişen gereksinimlere yeterince uyarlanabilen bir mimariye sahip olmaktır. Başka bir deyişle, işler değişiyor ve mimari değişiyor - Yeniden yapılandırılabilen "yumuşak" bir mimariyi savunmuyorum. Bugünün mimarisinin yakında kullanılmayacağını ve değiştirilmesi gerekeceğini kabul etmekten bahsediyorum, bu yüzden hiç kimse onunla "evlenmemeli".
Kolektif kod sahipliği, herkesin - teorik olarak - herhangi bir şeyi değiştirebilmesi gerektiği anlamına gelir. Bu "siloların zıttı" olarak anlaşılmalıdır. Başka bir deyişle, normal ve beklenen bir beceri engeli olabilir - herkes SQL sorgularına ince ayar yapabilen, bir örnek vermek için deneyimli bir DBA değildir - ancak bundan sadece bir DBA'nın el sorguları optimize. Diğer kişilerin yetkinleşmesine yardımcı olabilecek bir "özellik etki alanı uzmanı" olacaktır, ancak görevler yine de herkese düşmelidir.
Örneğin: "A" özelliği konusunda etki alanı uzmanıysam, yine de başkalarının "A" özelliği üzerinde çalışmasını beklerim, ancak büyük değişikliklerin olması gerektiğinde veya insanların yardıma ihtiyacı olduğunda bana danışılır. "A" özelliği kesinlikle benim özelliğim olmaz. İyi bildiğim bir özellik olacak. Çok daha fazla özellik bilmek benim ilgim olacak ve diğer insanların bu özelliği bilmek ilgisi olacak.
Sentezde: mimarlık, gereksinimler ortaya çıktıkça ve değiştikçe geliştiriciler tarafından birçok kez tasarlanır ve yeniden tasarlanır. Herkesin becerilerine göre gerekli değişiklikleri yapması ve ne zaman yardım isteyeceğini bilmesi bekleniyor. Çünkü mimarisi üzerinde hiçbir uzun vadeli vizyon yoktur insanlara güven ve biz gereksinimleri güvenmiyorum .
Örneğin, spotify sorunu doğrudan belgeden çözmek için "Sistem Sahibi" adlı bir rol kullanır:
Teknik olarak, herkesin herhangi bir sistemi düzenlemesine izin verilir. Ekipler etkili bir şekilde takımlar olduklarından, normalde üretime yeni bir özellik kazandırmak için birden fazla sistemi güncellemeleri gerekir. Bu modelin riski, hiç kimse sistemin bir bütün olarak bütünlüğüne odaklanmazsa, bir sistemin mimarisinin dağılmasıdır.
Bu riski azaltmak için “Sistem Sahibi” rolümüz var. Tüm sistemlerin bir sistem sahibi veya bir çift sistem sahibi vardır (eşleştirmeyi öneririz). İşlevsel olarak kritik sistemler için, Sistem Sahibi bir Dev-Ops çifti - yani bir geliştirici perspektifine sahip bir kişi ve bir operasyon perspektifine sahip bir kişi.
Sistem sahibi, söz konusu sistemle ilgili teknik veya mimari konular için “git” kişisidir. O bir koordinatördür ve bu sistemde kodlayan kişilere birbirlerine rastlamadıklarından emin olmak için rehberlik eder. Kalite, dokümantasyon, teknik borç, istikrar, ölçeklenebilirlik ve tahliye süreci gibi konulara odaklanmaktadır.
Sistem Sahibi bir darboğaz veya fildişi kule mimarı değildir. Kişisel olarak tüm kararları vermesi, tüm kodları yazması veya tüm sürümleri yapması gerekmez. Genellikle sistem sahipliğine ek olarak günlük sorumlulukları olan bir takım üyesi veya bölüm lideridir. Ancak, zaman zaman bir “sistem sahibi günü” alacak ve o sistem üzerinde temizlik işi yapacaktır. Normalde bu sistem sahipliğini bir kişinin zamanının onda birinden daha azına tutmaya çalışırız, ancak tabii ki sistemler arasında çok değişir.
Şirket fikrinde (sadece ekip düzeyinde değil) aynı zamanda bazı mimari bütünlüğü sağlamaya çalışan sistem sistemleri ile bu fikri çok beğeniyorum.
Belgenin tamamının bağlantısı: https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf , kısa ama çok, çok ilginç bir çevik ölçekleme deneyimine dayanan bir belgedir.
Çözülmesi zor bir problemdir ve kesinlikle bir geliştirme metodolojisi değil, bir proje yönetimi metodolojisi olan Scrum tarafından çözülmemektedir.
Bulduğum en etkili çözüm iyi paket yönetimi (nuget / gem / etc) ve versiyonlamadır. Tüketmeye hazır olana kadar asla başka bir takımda değişiklik yapmayın. Siz yeni yapıya geçerken eski yapıyı kullanmaya devam etsinler.
Hangi değişikliklerin ihlal edildiğini ve hangilerinin uzantı olduğunu netleştiren bir sürüm oluşturma stratejiniz olduğundan emin olun.
Ayrıca, bir değişiklik yaptığınızda, HER BİR EKİPTE birisine kod incelemesi gönderin. Kendi değişikliklerini en üste uygulayabilmeleri için tüketmeye zorlanmadan çok önce onları nasıl etkileyebileceğine bakalım.
Ve işler gerçekten dağınık hale geldiğinde; bir takımın bir değişiklik yapması gerektiğinde ve başka bir değişikliği kolayca tüketemediğinde (bu çok nadir bir durum OLMALIDIR), kodu dallandırın, tamamen farklı bir paket haline getirin, ancak en kısa sürede ortak koda geri dönmeyi bir öncelik haline getirin izin verir.
Her zaman olabildiğince açık olmayan cevap, ekiplerin herhangi bir bileşeni nasıl paylaşacaklarına karar vermelerine izin vermektir.
Örneğin, ekibim kısa bir süre önce benzer ürünleri uzun süredir geliştiren diğer iki ekiple ortak birçok kod paylaşan yeni bir ürün serisi geliştirmeye başladı. Ürünümüz birkaç yolla farklıdır, bu nedenle zaman zaman ortak koda özelleştirme noktaları eklemenin yollarını bulmamız gerekir.
Bu kodla ilgili bazı çatışmalar yaşadık ve ortak sahiplikle başa çıkmak için birkaç farklı geçici yol denedik. Daha sonra, yeni ve büyük bir özellik ortaya çıktıkça, tüm ekipleri aynı sayfaya dahil etmek için bir araya gelmemiz gerektiğine karar verdik.
Ekiplerimizin ortaya koyduğu çözüm başka bir durumda işe yaramayabilir. Daha basit veya daha resmi bir şeye ihtiyacınız olabilir. Mesele şu ki, kolektif mülkiyeti alıp sizin için neyin işe yaradığını buluyorsunuz.
Varsayalım özgürlüğü:
Yukarıdaki varsayımlar doğruysa, zaman zaman iki takımın birbirine müdahale edeceği zamanlar olmalıdır. Aşağıdaki yolları kullanarak çözebilirler: