Yazılım mimarisinden sorumlu Çevik Bir Ortamda


19

Çevik bir ekipte, sadece mevcut sprint'te yapılan işi değil, tüm sistemi etkileyen üst düzey mimari ve tasarım kararları almaktan kim sorumludur?

Belki ürün sahibi, scrum ustası, scrum ekibi veya başka biri?

resim açıklamasını buraya girin


10
Bu ... mantıklı değil ...
Telastyn

3
Ürün ve Sprint biriktirme listelerinin varlığı, yazılım mimarisinden kimin sorumlu olduğunu etkilemez. Daha iyi bir soru şu olabilir: Çevik bir Ortamda, yazılım mimarisinden kim sorumludur?
ChargerIIC

Soruyu en azından anlaşılabilecek şekilde güncellemeye çalıştım. % 100 emin değilim eğer doğru anladım ...
FrustratedWithFormsDesigner

Yanıtlar:


24

"Yazılım mimarisi tüm ekip tarafından gerçekleştirilir. Bu uygulama bir yazılım mimarı ihtiyacını ortadan kaldırmaz, sadece mimarın tartışmaya daha geniş ve muhtemelen daha deneyimli bir bakış açısıyla katkıda bulunduğu anlamına gelir, yine de ekibin tüm üyeleri yazılım mimarisi. "


5
Pure Agile, "proje yöneticisi" ve "sistem mimarı" gibi geleneksel yukarıdan aşağı rolleri reddetme eğilimindedir, bunun yerine bu rolleri yeniden gözden geçirmeyi ve geleneksel sorumluluklarını ekip boyunca dağıtmayı tercih eder.
Jonathan Eunice

6
@JonathanEunice: Bu pratik olarak nasıl uygulanabilir? Her geliştirici de iyi bir mimar değildir.
Giorgio

2
@JonathanEunice: Yani DWD'nin sorduğu soru sonuçta mantıklı. Tüm iniş çıkışları anlamıyorum.
Giorgio

3
@DaveHillier: Belki bu projeler büyüktür, ancak mimari yeterince basittir: geliştiricilerin parçaları oldukça basit, tekrarlayan bir şemada doldurmaları gerekir (örneğin, web tabanlı bir uygulamada yüzlerce benzer formu mevcut bir etki alanı modeliyle yazmak) . Öte yandan, bir uygulama yeterince karmaşık hale gelir gelmez, mimariye (genellikle açık) bakacak birine ihtiyacınız olduğunu biliyorum, aksi takdirde büyük bir karmaşa ile sonuçlanacaksınız.
Giorgio

6
"Büyük Açık Tasarım", açık bir tasarım olmaması gerektiği sonucuna varmak için tipik çevik bir argüman: aşırıya doğru bir yaklaşım, aşırı kanıtlanmış yanlış ve karşı uç bir çözüm olarak öneriliyor. Büyük bir ön tasarımın nadiren iyi bir yaklaşım olduğunu kabul ediyorum, ancak daha sonra büyük bir yeniden düzenleme veya tam yeniden yazmayı önlemek için bazı temel mimari kararlar alınmalıdır. Bu, "kodun çok dağınık olduğunu ve yeniden düzenleme gerektirdiğini hissettiğinde" doğaçlama yapılabilecek bir etkinlik değildir. Deneyim iyi bir denge bulmaya yardımcı olur.
Giorgio

19

Mimarlar, elbette, ama belki de geleneksel mimarlar değil.

Tüm düşünceyi yapan ve sonra tüm yazmayı yapmak için maymunları terk eden baş cerrah türünde bir mimar demek istemiyorum. Tersine çevrilmesi zor kararların maliyet / fayda dengesini anlayan ve ekiplere ne yapmaları gerektiği konusunda tavsiyede bulunan deneyimli bir lider programcı demek istiyorum.

Etkili mimarları bulmak zordur, ancak harika bir pozisyon olabilir ve bu yüzden muhtemelen en iyisini yapabilecek deneyimli, düşünceli bir programcıya sahipsiniz. Böyle bir kişinin

  • Elbette iyi mimari kararlar verin, aynı zamanda
  • Etkili bir şekilde nasıl tavsiyede bulunacağınızı bilin, böylece başkaları bunu rahatça hissedebilir
  • Mimari kararları yavaşça ekiplere devredin

Bu son nokta bir sürü insanı yukarı çekiyor. İyi niyetli agilistler "Takım mimariye sahiptir" gibi şeyler söylediklerinde, bu "doğru" a sahip olurlar, ama tavsiyeyi uygulamasında neredeyse tamamen anlamsız buluyorum. Takımların kendi mimarileri için sorumluluk almalarına güvenmiş olsaydınız, ilk etapta soruyu sormazdınız, değil mi ?! Bu nedenle soruyu sorduğunuzu varsayıyorum çünkü bazı endişeler de var.

  • Kimse sorumluluk almayacak ve zayıf bir mimariye sahip olacağız veya
  • Yanlış insanlar sorumluluk alacak ve zayıf bir mimariye sahip olacağız veya
  • Kim sorumluluk alırsa günah keçisi olur ve bundan kaçınmayı umuyorsunuz

Sorumluluk alması için birine ihtiyacınız varsa , kabul etmek isteyen herkese verin. Ciddi anlamda. O kişi en azından umurunda. O kişiye işi yapmak için ihtiyaç duydukları kaynakları verin ve ihtiyaç duyduklarında onlara yardım edin. Muhtemelen kişinin ne kadar yetkin olduğu önemli değildir, çünkü eğer ilgilenirlerse, öğrenmeleri gerekeni öğrenmeye çalışırlar. Doğal olarak, böyle bir kişinin okumak için iyi kitaplar ve yardım ve tavsiye isteyebilecekleri bir akran ve mentor topluluğu şeklinde desteğe ihtiyacı vardır.

Yanlış kişinin sorumluluk almakla ilgili endişesi varsa, umarım "doğru kişi" nin kim olduğunu bilirsiniz ve bir mimar olarak kurmak için savaşırsınız. Yeni Stratejik Satış gibi bir kitap , bunu gerçekleştirmek için satış tekniklerini öğrenmenize yardımcı olacaktır.

Sadece bir günah keçisine ihtiyacınız varsa, en çok yok etmek veya bozmak istediğiniz kariyere sorumluluk vermek için başkalarını sessizce dürtün. En azından dürüst ol.

Etkili bir mimarın çalışmasına geri dönerek, işlerini sadece karar verme pozisyonundan ziyade bir yönetim pozisyonu olarak düşünebilirler. Ekiplere en azından en rutin kararları vermezlerse, bir darboğaz olacak ve tüm organizasyonu yavaşlatacaklar . En üste daha fazla mimar eklemek bunu daha hızlı yapmaz. Baştan sona daha iyi mimari kararlar vermek. Heyet kurulu tekniği senin mimarı olan takımlar yetkinliğini gösteren güvenini kazanmak olarak takımlarına daha çok kararlar delegating zamanla daha rahat hale yardımcı olacaktır.

Büyük bir mimarı, sistemlerimi nasıl daha iyi tasarlayacağımı anlamama yardımcı olan, istediğimde bana sabırla tavsiye edecek ve zaman zaman çok kötü bir karar vermemi engelleyecek biri olarak düşünüyorum. Böyle bir mimar, kelimenin tam anlamıyla bir lider gibi davranır: başkalarının gönüllü olarak takip ettiği biri .

Bunun çok olduğunu biliyorum.

Referanslar

Miller, Yeni Stratejik Satış . Bu kitap, belirli bir satışı neden kapatamadığınızı anlamak için bir model içeriyor. Bunu, iş arkadaşlarının neden önerdiğim açıkça harika şeyi yapmayacağını anlamada çok değerli buluyorum.

Weinberg, Teknik Lider Olmak . Bu kitap, etkili mimarın işinin mimar olmayan kısmının nasıl yapılacağını öğrenmeme yardımcı oldu.

Appelo, Delegasyon Kurulları ve Delegation Poker . Delegasyonun ne kadar zor olduğunu ve ne kadar emdiğimizi küçümsemeyin. Daha etkili ve daha rahat bir şekilde yapmayı öğrenin.


1
'H' anahtarınız tehlikeli mi? ;)
Dave Hillier

3
Hayır Dave. Spivak (cinsiyetten bağımsız) zamirleri kullandım.
JB Rainsberger

@DaveHillier pozları gibi sorular nedeniyle, "s / o" kullanma eğilimindeyim ... (Bu harika cevap için teşekkürler, gerçekliği "takım / yok / sahip / sahibi ..." klişeler)
Marjan Venema


1
@Walfrat Daha fazla düşündükten sonra, bu noktayı biraz daha açıklığa kavuşturmaya karar verdim. İlgilenen bir kişi ne öğrenmeleri gerektiğini öğrenmeye çalışır, ancak bir akıl hocası gibi desteğe ihtiyaç duyar.
JB Rainsberger

10

En iyi mimariler , gereksinimler ve tasarımlar kendi kendini düzenleyen ekiplerden ortaya çıkar

- Çevik Manifesto

Böylece ekip, uygun gördüğü şekilde mimari kararlar vermek için kendini organize eder. Zor ve hızlı bir kural yoktur, konsensüsten en üst düzey üyelerin "konseyine", mimarlık otoritesi olarak belirli bir üyeyi atamaya, mimarın böyle bir iş unvanına sahip bir üye olup olmadığını seçmesine izin verebilir. .


9
Çevik'i severim, ama bu büyük bir zayıflıktır - mimari genellikle ihmal edilir veya birlikte taşlanır.
user949300

1
@ user949300 "Çevik" manifestoda olduğu gibi mimari hakkında çok az şey söylüyor. Bu sonucu tam olarak hangi yöntemlerle kullanıyorsunuz? XP, sizi acımasızca yeniden düzenlemeye teşvik eder. BUFD lehine misin?
Dave Hillier

"XP, acımasızca yeniden düzenlemeyi teşvik eder": Yeniden kodlama yapmaya yeni kod yazmaktan daha fazla zaman harcayana kadar. Bence en iyi çözüm, dikkatli bir analizden sonra aldığınız temel mimari kararlar ile yeniden düzenleme yoluyla uyguladığınız daha küçük tasarım kararları arasında bir denge bulmaktır.
Giorgio

@ user949300, çünkü ekip kendi kendini organize etmiyor, eğer olsaydı, bir mimari kararın alınması gerektiğinde ekibin geri kalanıyla sık iletişim içinde olacaklar ve bu fikirleri doğru bir şekilde belgeleyecek / tartışacak / tartışacaklardı.
Rudolf Olah

3

"Üst düzey mimari ve tasarım kararları almaktan kim sorumlu?" Cevabının ekiplerin büyüklüğüne ve sayısına bağlı olduğunu hissediyorum.

Her takımda 3-7 olan bir veya iki takım için, kendi kendini organize eden takım kıdemli üyelerin liderliğinde yapabilir.

3 veya daha fazla takım için artan karmaşıklık, çeşitli alt takımların diğer takımlarla arayüz oluşturacak işler yapıp yapmadığını görebilen bir mimari ekibine ihtiyaç duyulmasına yol açar. Deneyimlerime göre, bu nokta yaklaşık 8 takım olduğunda veya yaklaşık 50 kişide ulaşır.


1

Sitelerinde Ölçekli Çevik Çerçeve (SAFe) ekibinden bazı harika kaynaklar var .

Temel olarak, kuruluşunuz genelinde çevikliği ölçeklendirmenize ve tek bir sürümün yanı sıra portföy ve program planlamasına geçmenize yardımcı olur. Belgelerinde, Girişimcilik ve Sistem Mimarlarınızı serbest bırakma trenine mimari destanları tanıtma sürecine nasıl dahil edeceğiniz konusunda öneriler gösterilmektedir.

Soruyu daha doğrudan ele almak için anlaşılır olması için düzenleyin:

Ölçeklendirilmiş çevik bir ortamda mimari üzerinde birden fazla mülkiyet katmanı vardır. Çevik uygulama ekibi, birikmiş işlerini uygulamalarına devam etmek için gerektiğinde yeniden düzenleyerek düşük seviyeli ortaya çıkan mimariye sahip olacak. Yüksek düzey mimari kararlar (desteklenen işletim sistemleri, tarayıcılar, platformlar, kütüphaneler) sisteminizin ve kurumsal mimarlarınızın sorumluluğundadır. Bu değişikliklerin ne zaman yapılması gerektiğine ilişkin iş durumları yapacaklar ve bu mimari değişikliklerin uygulama ekipleri için sürüm trenine eklenmesini önerecekler.

Dolayısıyla, sprint'in ötesine geçen yüksek düzey mimari kararlarla ilgili olarak, bunları genellikle ekibin üzerinde bir seviyede alacaksınız. Bu profesyonellerin geleneksel olarak zaten işletme içinde 'mimar' rolü vardır.


2
bu, "üst düzey mimari ve tasarım kararlarını vermekle sorumlu olan" sorusunu nasıl yanıtlıyor?
gnat

1
Teşekkürler tatarcık, soruyu cevaplamak için niyetimin ne olduğunu daha net hale getirmek için düzenlemeye çalıştım. Kafamda birkaç sıçrama yaptım, ama onları yazmayı unuttum :)
Jay S

1

Bence diğer cevapların çoğu bunu bir projenin içinde olma perspektifinden düşünüyor.

Eğer bir organizasyondaki tek mimarlık seviyesi buysa, sonuç açıkça kaos olacaktır. Bu kaosa ilk elden şahit oldum, ne yazık ki oluyor.

TOGAF'a göre, Kurumsal Mimari Departmanı, BT ortamını oluşturmak ve değiştirmek için işletme için ve onunla üst düzey planlar yapar. Kurumsal Mimar mimari ilkeleri tanımlayacak ve bunları kurumun en üst düzeylerinde imzalayacak ve her proje için yüksek düzeyli mimari ve gereksinimlerin yaratılmasına yardımcı olacaktır. Her proje, bu üst düzey mimaride bir mimari yapı taşı sağlamak için başlatılır.

Bu nedenle, proje düzeyinde, Çözüm Mimarı proje mimarisini (muhtemelen yinelemeli olarak) oluşturacak ve Enterprise Architect'ten imza alacaktır.

Şimdi, çevik bir projeye odaklanmak. Çevik bir projenin gereksinimleri vardır. Onlar büyük bir "İhtiyaçlar Belgesi" şeklinde değil, bunun yerine destansı ve hikayelerdir. Bu Destanlar hala planlama gerektirir. Bilinmeyene birkaç sprint üzerinde geliştiricilerden oluşan bir ekip göndermiyorsunuz. Sistemin ne yapması gerektiğini, diğer hangi sistemlerle etkileşime girmesi gerektiğini ve kuruluşun hangi donanım / İşletim Sistemi / Dil kısıtlamalarını üstlendiğini ve bu, Çözüm Mimarına açık olan mimari seçimleri yönlendirir ve kısıtlar. Örneğin, .NET ve SQL sunucusuna adanmışsanız, son dereceiki DB, iki dil, iki web sunucusu vb. destekleme maliyetleri nedeniyle PHP ve MySQL kullanarak Magento tabanlı bir e-ticaret sitesi uygulamak için zorlayıcı bir durum. Alternatif olarak, bir proje tamamen farklı bir kütüphane veya farklı bir görünüm kullanmayı tercih edebilir ve hissediyorum ve bunun diğer tüm uçuş içi projelere etkisi olabilir. Bu tür bir "Mimari Borç" un meydana gelmesini önlemek için bir Kurumsal Mimarın gözetimi gereklidir.


0

Kuruluşun organizasyonel tasarımına ve ürünün portföyde olup olmadığına bağlıdır. Daha büyük, rol odaklı kuruluşlar bu tür faaliyetlere öncülük etmek için kıdemli mimarlar atayabilirler.

Genellikle kıdemli bir mimar, tasarım kararlarını sadece bir ürün biriktirmesini etkilemedikleri için kolaylaştırır ve yönlendirir, aynı zamanda bir ürün portföyündeki birkaç ürünü etkileyebilir.

Daha küçük ve çevik şirketler, geliştirme ekibinin mimari tasarıma uyum sağlaması için sistem uzmanı olan geliştiricilere güvenebilir.

Sonuçta, mimari kararların ürün üzerinde çalışan dağıtım ekibi tarafından kararlaştırılması gerekir. Deneyimli Mimarlar ve teknoloji liderleri, tasarımı dikte etmek yerine tasarımın neye benzemesi gerektiği konusundaki tartışmayı kolaylaştırmaya odaklanacaktır.


0

Bence çoğu cevap zaten tek bir kişinin değil takımın bu kararları alması gerektiğini vurgulamaktadır .

Dokunmadıkları başka bir Çevik ilke:

Basitlik - yapılmayan iş miktarını en üst düzeye çıkarma sanatı - esastır.

Üst düzey mimariler ve tasarım kararları düşünmek genellikle basitlik göz önünde bulundurulmaz, muhtemelen çok fazla çaba harcanmasına ve işleri genişletmeyi zorlaştıracak gereksiz karmaşıklık eklemeye yol açar.

'Bahçecilik' üzerinde 'mimarlık' düşünün - Canlı, büyüyen bir tasarım kültürü oluşturun

Mevcut yinelemeniz sırasında, mevcut ihtiyaçlarınız için mimari ve tasarım kararları almalısınız. Asla olmayacak bir geleceğe bakmak yerine, şimdi ihtiyacınız olan şeye odaklanın. Muhtemelen YAGNI şimdi iyi düşünülmüş bir mimari, ekibin yavaş yavaş ele almasına izin verin.

Diğer okumalar:

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.