Bir takımda tasarım, diğerinde kodlama

Tüm yazılım tasarımının yerel bir ekip tarafından yapıldığı ve bu tasarımların kodlama için bir denizaşırı ekibine gönderildiği bir projede yer alacağım.

Bu, bu özelliklere sahip bir projeyle ilk karşılaştığımda ve benim için garip hissettiriyor: Yöneticiler, çok detaylı tasarım belgeleri yapmamızı bekliyorlar; bu nedenle offshore ekibi için hataya yer yok; Benim bakış açımdan bir IDE'de yapabilirken kağıda kodlama yapıyorlar.

Öyleyse benim sorum şu, bu yaklaşım iyi mi, kanıtlanmış mı? Yazılım sürecimizin projemizde başarılı olması için sahip olması gereken ana hususlar nelerdir?

Benim fikrim:

Eğer denizaşırı insanlara vereceğiniz her şey belgeler ve şemalar ise, çok fazla yanlış anlaşılma ve hayal kırıklığı yaşarsınız .

Benim önerim

• Onlara kadar çok belge, daha ziyade vermeyin arabirimleri ve soyut sınıflar için tasarım hedefleri içine deli gömleği .

• Bilinen bir adlandırma standardını kullanmalarını isteyin.

• Birim testlerini kullanmalarını isteyin.

• Süreci denetlemek için tasarımcılarınızdan / mimarlarınızdan birisini kendi tesislerine gönderin, kurum içinde kodlamaktan daha ucuz olacak, ancak daha iyi sonuçlar alacaksınız.

Adı Big Design Up Front, Şelalesi. Çok başarılı bir metodoloji olarak kabul edilmiyor. Ama ben işe yaradığını gördüm ve işe yaradığında çok iyi çalışıyor. Doğru yapmak çok pahalı.

Aynı zamanda işvereninizin sizden yapmasını istediği şey.

Açık deniz takımları, kıyı ekiplerinin yaptığı gibi çalışmaz. Tam olarak ne istediğin konusunda çok spesifik olmalısın, yoksa istediğini elde edemezsin.

Son projede yazılım tasarımcısıydım. Bütün gelişme denizden çıktı. Başarılı olduk. Böylece bu işlem işe yarayabilir.

Çok fazla dökümantasyon yaptım fakat bu hiçbir şekilde kapsamlı değildi ve adım adım talimatlar vererek veya sınıf isimleri, fonksiyon isimleri vb. İle detaylandırılmıyordu. diragramlar, gerektiğinde daha detaylı bir tasarım dokümantasyonu.

Bu gerçekten deniz gelişmesine ne kadar güvendiğinize bağlı. Yeterli geliştiriciler olmak için offshore ekibime güveniyorum. Bu, genel bir yön verdim, ancak offshore ekibinin hoş bir şekilde tatmin edici bulduğu uygulamaları uygulamalarına yer verdim. Geçmişte daha fazla mikro yönetiliyorlardı. Bazı durumlarda, onları tasarım desenlerini gerektiği gibi kullanmalarına yönlendiririm. Ayrıca düzenli olarak kod incelemeleri ve yazdıkları kod üzerinde analizler yaptım ve yeniden düzenleme veya temizleme çabaları konusunda tavsiyelerde bulunacağım. Ayrıca, ekibin bir kısmı eğlence araçlarıyla kaza geçirdiğinden, bazı kaynaklar konusunda yetersiz kaldığımız için uygulama sırasında bazı öyküleri kodladım.

Ek olarak, bu sürecin gerçekten sadece teknik lider (ler) inizin projedeki gücünün ve işletme, tasarımcı, potansiyel müşteriler ve geliştiriciler arasındaki iletişim üzerinde başarılı olduğunu düşünüyorum. Her bir özelliğe ve hikayeye göz gezdirmek için çok zaman harcadık ve açık denizdeki liderlerin / kaynakların gereksinimlerin neler olduğuna iyi karar verdik. Özelliğin / hikayenin gözden geçirilmesi sırasında soru sormuyorlarsa, o zaman bazı sorunları bekleyin. Ayrıca iş imzalanıncaya kadar da iş tamamlanmış sayılmaz. Böylece her şey çevik kalkınmayı yöneten bir araçta takip edildiğinden beri herkesin sorumlu olmasını sağladı.

Diğer cevaplardan biri çoktan atfedildiği gibi, geliştirme süreci, adlandırma standartlarını (yerleşik yeniden yapılandırma kuralları), test senaryosunun kapsamını (TDD, Mocking vb. Kullandı) içeriyordu. başarılı bir proje için şansınızı.

Açık deniz kalkınmasının en büyük maliyeti iletişimdir. Belgelendirme iletişimin bir yoludur, ancak belgeler genellikle tüm ayrıntıları ve olası değişiklikleri kapsayamaz.

Projenizin ne kadar büyük olduğundan emin değilim. Büyük olduğunu düşünüyorum, aksi takdirde açık deniz geliştirme ekibini kullanmak değerli değildir. Böylece benim deneyimim

1. İskelet kodunu, genel arayüzü, servis arayüzünü vb. Tanımlayın ve birlikte gözden geçirin
2. Kabul testlerini diğer tarafla tanımlayın
3. Büyük belgeyi küçük hikayelere ayırın, küçük hikayelere dayalı çalışın. Büyük belge tüm sistemin sadece büyük bir resmi
4. Hikayelerin kontrol noktalarını bir hafta veya iki hafta olarak ayarlayın

1 ve 2 aslında gelişme ile ilgilidir, diğer tarafın gereksinimi iyi anladığından emin olmak için ve her iki taraf da aynı düzeni kullanıyor. Şekil 3 ve 4, çevik kalkınma metodolojisinin bir parçasıdır, ancak açık deniz gelişimi için tam çevik süreci kullanmak zordur.

Bir dereceye kadar hepimizin böyle çalıştığını düşünüyorum. Bir yerde birileri bir şeyler tasarlar ve sistemin parçası olan veya onunla çalışan bir şeyi kodlarız. Örnekler, mobil cihazlardaki oyun dışı uygulamalar gibi bir çerçeveye dayalı uygulamalar oluşturmaktır. Çerçeveyi yapan kişilerin tasarım ekibi tarafından birçok kullanıcı arayüzü kararı verilmiştir. Bir uygulama yazmaya, uygulamanızı satmaya kadar öğrenmekten her şeyi kontrol ettiler. Bu modelin neden başarılı olduğunu görmek istiyorsanız, sadece bazı satıcılar tarafından sağlanan dokümantasyon ve araçların miktarına bakın.

Diğer bir örnek, REST tarzını uygulamaya çalışan çok sayıda web uygulamasıdır. Bu, gerçekten HTTP'nin nasıl kullanılacağına ilişkin spesifikasyonlar olmasına rağmen, nasıl bir şeyler uygulanacağını anlatmaz. Her neyse, izlenmesi gereken şartnameler ve yol gösterici ilkeler var. Yığın değiş tokuşunda veya işyerinde REST uygulaması hakkındaki tartışmaların miktarını görürseniz, insanlara bir şeyi belirli şekillerde uygulamalarını söyleyen bir mimar varmış gibi. Hala başarılı bir model, bence, tarzı takip eden birçok insan var.

Bu iki örnekten, tasarımların nasıl yayıldığını görebilirsiniz, bazıları kâğıt özellikleri olarak, diğerleri kitaplarla, araçlarla ve örneklerle gelir. İnsanların nasıl bir soru sorduğunu (hacimce), hangi standartları / tasarımları takip etmeye çalıştıklarına bağlı olarak farklı derecelerde anlayışı doğru anlamaya çalıştığını görebilirsiniz. Sadece yığın akışına gidin ve izleyin;)

Bana şartnamenizi verirseniz soracağım. Bana ünite testi yaparsan, kodlar ve test ederim.