Mimarlar kendi kendini organize eden Scrum ekipleriyle nasıl çalışabilir?

Çok sayıda çevik Scrum takımına sahip bir organizasyonda "kurumsal mimarlar" olarak atanan küçük bir grup da bulunur. EA grubu, kalite ve kararlara bağlılık için kontrol ve bekçi görevi görür. Bu, takım kararı ile EA kararları arasında çakışmaya yol açar.

Örneğin, ekip X kütüphanesini kullanmak veya SOAP yerine REST kullanmak isteyebilir, ancak EA bunu onaylamaz.

Artık bu, takım kararları reddedildiğinde hayal kırıklığına yol açabilir. Yeterince ele alındığında, potansiyel olarak EA halkının tüm gücü "ele geçirdiği" ve takımın motivasyonunu kaybettiği ve çok çevik olmadığı bir duruma yol açabilir.

Scrum kılavuzları bu konuda şöyle demektedir:

Kendi kendini organize etme: Hiç kimse (Scrum Master bile değil) Geliştirme Takımı'na Ürün İş Listesini potansiyel olarak serbest bırakılabilir işlevselliğin artışlarına nasıl dönüştüreceğini söylemez.

Bu makul mi? EA ekibi dağıtılmalı mı? Takımlar reddetmeli mi yoksa sadece uymalı mı?

Bir Geliştirme Ekibi, gerçek işi yapan çapraz fonksiyonel becerilere sahip 3-9 kişiden oluşur

Scrum Master "Kurumsal Mimar" ı proje ekibinin bir parçası olmaya davet etmelidir. O zaman mimar ve programcılar arasındaki iletişim mükemmel olurdu.

Kullanılan teknoloji seçimi, yazılımın gerekliliklerinin bir parçasıdır; bu, herhangi bir nedenle, belirli teknolojileri kullanmadığınız özellik isteğinin bir parçası olduğu anlamına gelir.

Mimarlar sistemler ve kod tabanı için konuşuyor çünkü sistemler ve kod tabanı kendileri için konuşamıyor. Bir mimarın olması genellikle bir şirketin, özellikle de şirket içinde oluşturulan yazılıma dayanan bir şirketin uzun vadeli çıkarları içindedir.

Mimarlar geliştiricilere biriktirme listesini nasıl artışlara (sprint) dönüştüreceklerini söylemiyorlar, hangi teknolojilerin kullanılabileceğini ve kullanılamayacağını söylüyorlar. İki farklı konuyu karıştırıyorsunuz.

Çözüm hiçbir şeyi değiştirmektir. Mimarlarınız çok kısıtlayıcı veya çok zorlayıcı olduğu için ekipleriniz hayal kırıklığına uğruyorsa, bu SCRUM ile ilgisi olmayan ve çalışan memnuniyeti ve mümkünse sonuç olarak iş paydaşları ile ele alınması gereken bir personel meselesidir. (" Mimar Turbo Turbo kullanmamıza izin vermeyeceği x%için özellikler geliştirmemiz daha uzun sürüyor .")yz

Bu tür bir şey, projenin yapılması için büyük bir ekibe ihtiyaç duyma ile çevik ekipleri küçük tutma ihtiyacı arasındaki dengeyi korumak için gereklidir.

Genel olarak, 'takım liderliği scrum' her küçük takımdan seçilen bir üyeden oluşur. Bu, kendi kendini organize eden doğanın bir kısmını sağlar ve üst düzey grup tarafından alınan kararların çevik grup tarafından kabul edilmesi için bir çeşit temsil şekli sağlar.

Özel senaryolarınız için, çevik takım motivasyonunu durdurmak için bir şeyler yapılmalı, ancak muhtemelen isyan ya da basit bir kabul görmemelidir. Ekibin, idealleri kowtow değil, iyi bir yazılım yapmak için orada olduğunuzu fark etmesi gerekiyor. Aynı projede benzer şeyler yapmak için her biri farklı teknolojiler kullanan bir takım farklı ekiplere sahip olmak daha kötü yazılımlara yol açacaktır. Bir grup farklı ekibin aynı projede farklı kodlama standartları kullanması daha kötü yazılımlara yol açacaktır.

Eğer ihtiyacımız olacak Yani bazı proje çalışmaları nasıl gidiyor hakkında bazı fikir birliğine varmaya yol. Takım kurşun scrum başka yerlerde etkili bir şekilde kullanılır. Farklı bir şeyler yapmanız veya grubunuzun neden bunu etkili bir şekilde yapmadığına bakmanız gerekebilir.

Soru: Bu Mimar ekibinin var olmasının nedeni nedir? Düşünebilmemin tek nedeni, çeşitli ekipler arasında birlikte çalışabilirliği güçlendirmektir. Ya da ekipler tek bir ürünün çeşitli parçaları üzerinde çalışıyor ve bu mimar ekibi her parçanın birlikte çalışmasını sağlamak için var.

Tam olarak söylediğiniz gibi, bu şemanın çevik bir ortamda iyi çalışabileceğini düşünmüyorum. Çeşitli takımlar kendi içinde tutulmalı ve girdi ve çıktıları olmalıdır. Dolayısıyla çıktılarını sınırlamak yalnızca girdi gereksinimlerinin bir parçası olmalıdır. Ancak bu kısıtlamalar makul olmalıdır. "X kitaplığını kullanmamalı" gibi bir şey iyi bir gereklilik değildir, ancak "Kullanılan üçüncü taraf kitaplıklarının sayısını en aza indirmeli" veya "Başka takımlarda kullanılmayan yeni kitaplıklar ekleme" sınırlandırılmalıdır. iyi olmalı.

Sonra mimar ekibini tüm ekiplere dağıtır ve uzmanlıklarını mimarlık sorunlarında kullanırdım. Ekibin bir parçası olarak, ekibin yaşadığı sorunları daha iyi görebilecekler ve mimarinin temel parçalarını değiştirme konusunda daha iyi fikirlere veya daha eğitimli fikirlere sahip olabilirler. Ayrıca, ekipler arasındaki mimarların mimarlığın ekipler arasında tutarlı kalmasını sağlamak için iletişim kurmaları teşvik edilmelidir.

Scaled Agile Framework'teki grup bununla çok iyi konuşuyor. Çoğumuz Takım Seviyesinde iş yaparız, ancak ölçek büyütürken, Program ve Portföy seviyesinde de rol oynayacağını bilmemiz gerekir. Mimari kararların kuruluş genelinde alınması gerekir ve bu da kuruluşun alt düzeylerinde olup bitenlerle beslenmelidir. Mimari kararlar almanın yanlış bir yanı yok!

Bununla ilgili olarak, Dean Leffingwell'in Agile Software Requirements hakkındaki son kitabı bu konuda iyi bir okuma, kendim okuyorum.

Ayrıca çok sayıda çevik ekibimiz var (bazıları Kanban, bazıları Scrum) ve mimarlarımız var. Mimarlar tüm ürünlerimizi kapsayan altyapıdan sorumludur (yardımcı kütüphaneler, kimlik doğrulama, altyapı oluşturma vb.).

Bu iyi çalışıyor ve genellikle çatışma yok. Bence çok önemli bir nokta:

Mimarların ekipler üzerinde resmi bir yetkileri yoktur ve sadece onları geçersiz kılamazlar. Normalde, mimarlar tüm ürünler için geçerli olan kararlar alırlar ve ekipler kendi ürünleri için kararlar verir. Bir çatışma varsa, mimar ve ekibin sadece bir anlaşmaya varması veya yönetime tırmanması gerekir (bu nadiren olur).

Bence mimarları ve geliştiricileri akran yapmak gerçekten önemli. Her ikisi de sadece farklı alanlarda ortak bir hedefe doğru çalışıyor. Hiç kimse diğerini "geçersiz kılamazsa", işbirliği daha iyi olacaktır.

Burada herhangi bir çatışma görmüyorum. Anladığım kadarıyla, tüm EA (sanırım görkemli bir başlık olarak) yapmak anlamına gelir QA. Herkes bunun farkında olmalı.

Sen o, düşünmelisiniz herhangi gereksinimleri toplama bunun yinelemeli veya ayarlıyoruz olsun, çok önemli bir adımdır geliştirme metodolojisi (yani biri olarak kabul ediliyor hak ediyor).

Bu gereksinimlerin bazıları şirket politikası tarafından belirlenir. Ve bunlar temel kuralları belirler:

• Takım, diğer gereksinimler gibi onlara uymak zorunda kalacaktır. Politikaya meydan okumak o zaman proje kapsamı dışındadır ve ayrı olarak ele alınmalıdır.
• EA'nın işi bu gereksinimleri uygulamak ve kişisel fantezi empoze etmektir. X'i sevmiyorlar, o zaman bu onların kişisel görüşü. Ne fazla ne eksik. Başka bir görüş gibi davranın. Bununla birlikte, EA, X'i kullanmanın mevcut bir gereksinimi ihlal ettiğini gösterebilirse, X'in kullanımını yasaklama hakkına sahiptirler ve uygulanabilir bir alternatif biliyorlarsa ve ekip bunu yapmazsa, bunu uygulama hakları vardır.

Ancak her iki durumda da, bir gereklilik karşılanır veya karşılanmaz. Bu kararlılığın yapılması zorsa, gereksinim eksiktir ve gerçekten daha test edilebilir hale gelmesi için (daha geniş anlamda) tekrarlamanız gerekir. Bunu herhangi bir gereklilik yinelemesi olarak ele almalısınız.

Mimarınız çevik ekipleriniz tarafından alınan kararları geçersiz kılmamalıdır. Mimarınız bunları ekiplere iletilen gereksinimlere / hikayelere dahil etmelidir. Projenin manzarası değiştiğinde ve yeni birlikte çalışabilirlik gereksinimleri getirildiğinde ekipleri güncel tutmalıdırlar.

Emir veren ve teknik kararlar veren mimarlar kültürel bir kusurdur. Kendilerini sadece paylaşılan bir hedefi / vizyonu sürdürmek ve ayrı takımları aynı sayfada tutmak yerine "patron" olarak görürler. Çevik metodolojiler iletişim ve iletişime dayanır. Mimarlarınız kararlar verilinceye kadar dahil olmazlarsa, çevik olarak başarısız olurlar.

Martin, bence kendi kendini düzenleyen bir ekibin çevresinde nasıl işlediğine dair bir yanılgıya sahip olabilirsin.

Scrum Rehberinden alıntı yaptınız: "Hiç kimse (Scrum Master bile değil) Geliştirme Ekibine Ürün İş Listesini potansiyel olarak serbest bırakılabilir işlevselliğin artışlarına nasıl dönüştüreceğini söylemiyor."

Bu, Scrum ekibinin şirketin bir bütün olarak teknoloji ve iş ihtiyaçlarına ve diğer ekiplerin ihtiyaçlarına bakmadan istediği her şeyi yapması için bir lisans değildir.

Tabii paydaşlar etkilerini kötüye kullanabilirler. Bu, işbirliğinin zorluklarından biridir ve kesinlikle EA ile sınırlı değildir. Ancak işbirliği, ekibin sınırında bitmez.

Şelale veya Scrum (bu, evet, işe yaramayacak olan ikisini karıştırmak gibi görünüyor), ilk başta bana oldukça anlamsız bir yönetim katmanı gibi geliyor. Teknoloji kararları alan yöneticiler, geliştiricilerin, uygulamanızı tercihlerini uygulamanızın teknik tercihlere dönüştürmesini engellemek için geliştirme genel müdürü ve bütçesinin potansiyel faturaya dayanması gereken lider geliştiriciler olmalıdır.

Hiçbir şey beni geliştirici olmayanlar gibi, bu kararların sonuçlarına maruz kalmak zorunda olan gerçek insanlara bile danışmadan teknoloji kararları vermek için safraya sahip gibi görünmez.