Geliştirme Yığını Dilimleme - çapraz mı?

Devam eden yeni bir projemiz var ve şu anda geliştiriciler A ekibine ve B ekibine iki takıma ayrıldı. Bu projenin geliştirme yığını boyunca geliştirme gerektiren 2 bölümü var. Aşağıda gösterilen yığımızın çok basitleştirilmiş örneği:

Projenin her bir parçası tüm yığın boyunca gelişime ihtiyaç duyar, bu yüzden tam bir yığın geliştirici yaklaşımı beklerdim, bu yüzden B takımı içindeki çalışmamızı nasıl bozduğumuzu, farklı parçalar arasındaki etkileşimleri tasarlayıp çalıştığımızı düşünüyoruz.

Ancak yakın zamanda öğrendim ki, A takımı yığının belirli kısımlarından sorumlu olmak istiyor ve Veri Soyutlama Katmanı'nın (ve Veri katmanına içerik koymanın) işlendiği iki takım arasında bir bölünme öneriyorlar. B Takımından hiçbir gelişme olmadan kendilerini ayırırlardı.

Bana göre bu çok doğal değil. Her takımın bunları başarmak için farklı hedefleri ve zaman çizelgeleri vardır, ancak B Takımı, özellikleri uygulamak için A Takımına bağımlı olacaktır. Önerilen çözüm, ortak arayüzlerin önceden tanımlanmış olmasıdır (projede muhtemelen çok sayıda olabilmeleri için 2 yıllık bir zaman ölçeği vardır). A takımı daha sonra kendi hedefleri olmasına rağmen bu arayüzler için gereken bitleri erken geliştirirken, B Takımı ilerleyebilmeleri için tüm kısa vadeli çağrıları iptal eder.

Bu yaklaşımla ilgili endişelerim var:

• Arabirimler değişebilir ve A Takımı değişen gereksinimleri karşılamak için bant genişliğine veya zamana sahip olmayabilir.
• A Takımının kodundaki hatalar, B Takımının ilerlemesini engelleyebilir ve yine A Takımının farklı bir öncelik sırasına sahip olması nedeniyle bunları düzeltmek için öncelik olmayabilir.
• Ekipler arasında bilgi eksikliği - B Takımı, kaputun altında neler olup bittiğini tam olarak anlamayabilir ve bu nedenle kötü tasarım kararları verebilir.

Endüstrideki birçok şirketin alt ekipleri olduğu ve bunun üstesinden gelebilmesi önerildi. Anladığım kadarıyla, ekipler ya başlangıçta nasıl beklediğimi (Full Stack) ya da aşağıdaki gibi teknoloji yığınını parçalayarak bölerler:

Bu yüzden endüstrinin geri kalanının ne yaptığını bilmekle ilgileniyorum. Bölmelerin çoğu dikey / yatay mı? Çapraz bir ayrım mantıklı mı? Diyagonal bir bölünme olursa endişelerim geçerli görünüyor mu ve B Takımının endişe etmesi gereken başka bir şey var mı? Büyük olasılıkla B Takımının başarısından veya başarısızlığından sorumlu olacağımı belirtmek isterim.

Endişeleriniz son derece geçerli. Özellikle A Takımı ile ilgili ilk iki nokta, B Takımını etkileyen özellikler eklemek veya hataları düzeltmek için zaman bulamıyor. Bunun kendi işimde birkaç kez olduğunu gördüm.

Bu, aşağıdaki durumlarda iyi bir fikir olabilir:

• Takım A'nın veritabanında yeni özellikler gerektiren projeler üzerinde çalışacağı, Takım B'nin amacının esasen "sadece ön uç" özelliklerini yapmak olduğu bilinmektedir. Örneğin, B Ekibi şirketinizin yeni iPhone uygulamasını yazıyorsa, muhtemelen bir süredir yeni veritabanı alanları eklemeyeceklerdir, çünkü masaüstü sürümünün tüm özelliklerini taşımaları / yeniden uygulamaları gerekir.

• "Dolu yığın", tek bir geliştiricinin (ya da geliştirici ekibin) etkin bir şekilde her şeye "sahip" olamayacağı kadar karmaşık hale geldi. "Kendi" derken, sadece özellikler eklemek ve hataları düzeltmekle kalmayıp, zaman içinde daha fazla teknik borç eklemekten kaçınabilecekleri noktaya kadar tüm sistemi anlayın ve bakım yapın. Bu durumda, A Takımı, DAL / veritabanı uygulamasına (belki de bazı dahili teşhis araçlarına?) Son derece basit veya kaçınılmaz olarak sıkıca bağlı bir UI / Web API'sine sahipse "çapraz" bölünme mantıklı harekettir. tüm karmaşık kullanıcı arayüz ön uç şeyler.

• Yönetim, A Takımının bir darboğaz haline gelme riskini anlar ve bu risk gerçek bir soruna dönüştüğünde ya da olduğunda, köşegenleştirmeye istekli olacaktır.

Endüstride az ya da çok yaygın olan şeylerle konuşamıyorum, ama en azından çalıştığım yerde, tüm uygulama geliştiricilerinin "tam yığın" olması için açık bir ihtiyaç var. Sahip olduğumuz şey, şirket içi veritabanımızı, web hizmet çerçevemizi ve UI çerçevemizi (şirketimin çok büyük olduğunu söylemiş miydim?) Geliştiren / koruyan "altyapı" ekipleridir, böylece yüzlerce uygulamamızın tamamı yığın halinde olabilir devs ise şirket bir bütün olarak tüm hizmetlerimize tutarlı bir performans ve kullanıcı arayüzü sağlayabilir.

Son zamanlarda şirketimiz yepyeni bir UI çerçevesi yapıyor, bu nedenle yeni uygulamalarımızın bazılarının yeni çerçevedeki hatalar ve eksik özellikler üzerinde oldukça kötü bir şekilde engellendiği bir dönem vardı. Bu artık geçerli değil, çünkü bazılarımıza çerçevenin sahibi olan takıma çekme talepleri gönderme izni verildi (oldukça "köşegenleştirme" değil, fikri anladınız).