"DDD sağcı bir şey!"

Simon Chaveneau , bu kışkırtıcı ifadenin arkasında (konuşma dışı bir oturum başlatmak ve insanlara sahip olmak için ideal), Domain Driven Design'ın (DDD) yazılım üretmek için kuruluşumuz (Product-Tech) üzerindeki etkisinin sorusunu kendine sormak istedi. Bu, Agicap'ta, Ürün ve Teknoloji insanlarının bir araya gelerek tartışmak, öğrenmek, paylaşmak, gülmek ama her şeyden önce günlük hayatlarımızla ilgili olarak yükseklik kazanması için düzenlenen ilk konferans dışı toplantımız sırasında gerçekleşti.

Konferans dışı bir program sırasında, program izleyiciler tarafından oluşturulur. Sabah ilk “Pazar Yeri” seansı sırasında yapılır. Günün bu ilk genel kurulu sırasında, herkes yapışkan notlar, bir işaretleyici alabilir ve ardından oturumlarını herkesin önünde sunabilir. Daha sonra insanlar onları günün programına göre konumlandırıyor (bu konferans hakkında daha fazla bilgi için bu twitter dizisi var )

Ama konuya ve Simon tarafından önerilen ilgi çekici oturuma geri dönelim.

Özel mülkiyetin saltanatı mı?

Simon'ın ilk adımını özetlemek gerekirse: IS'mizin tüm bölümleri ekiplere aitse - her biri bir veya daha fazla Sınırlı Bağlamdan (BC) sorumlu - özel mülkün bir yazılım sürümüyle (BC'lerin etrafında dikenli teller vb.) karşı karşıya değil miyiz? .)? Bu nedenle kışkırtıcı “ DDD sağcı bir şeydir! ”

Ve yardımcı soruyla birlikte: “Özellik ekiplerine dayalı bir organizasyonla daha verimli olmaz mıydık? (kullanım durumlarına giden yolda tüm BC'ler üzerinde çalışabilen herkesle)”

Pekala… İtiraf etmeliyim ki bu oturum başlangıçta umduğumdan çok daha verimli geçti çünkü Ürün/Teknoloji organizasyon modumuz hakkında gerçekten büyüleyici bir tartışma başladı.

Ancak, çok sayıda olduğumuz (başka bir gönderi bağlamında anlatmak kesinlikle ilginç) bu oturumda alınan yolu detaylandırmak yerine, konuyla ilgili aklımda kalanları ve düşündüklerimi doğrudan açıklayacağım.

Birkaç gözlem

• Etkili yazılım, iş zorluklarıyla uyumlu yazılımdır . Hizalanmış derken, alan alanından doğru terimleri ödünç alan, işin temel kavramlarını doğru bir şekilde ifade eden ve teknik sorunların neden olduğu tesadüfi karmaşıklığı mümkün olduğunca az çağıran yazılımları kastediyoruz. Bu, burada 3 dakika içinde açıklandığı gibi, Etki Alanına Dayalı Tasarımın (DDD) ana zorluklarından biridir .
• Conway Yasası, kişinin almamayı seçebileceği bir seçenek değildir.‍♂️ Yerçekimi çekimi gibi belirli fiziksel yasalar gibi davranır. Buna karşı savaşmayı deneyebiliriz ;-) ama bu dünya üzerinde hala geçerli. Conway Yasası,
  "Bir sistem tasarlayan herhangi bir kuruluş (geniş olarak tanımlanır), yapısı kuruluşun iletişim yapısının bir kopyası olan bir tasarım üretecektir" diyen 1967 yasasıdır.
  Başka bir deyişle, bir yazılımın mimarisi, zorunlu olarak onu tasarlamaya dahil olan insanların iletişim biçimlerinin sonucudur. Örneğin, 3 ekip tarafından geliştirilen bir derleyici büyük olasılıkla 3 geçişte çalışacak veya 3 farklı modüle sahip olacaktır.
• Ters Conway Manevrası (ICM), birinin Conway yasasını kontrol edebileceğini düşünmenizi sağlar. Başlangıçta bu ters manevra akıllıca bir şekilde “ ekiplerin etkili bir şekilde işbirliği yapma yeteneğini kısıtlayan siloları yıkmayı” tavsiye etti. Ancak yıllar geçtikçe aptalca bir tavsiyeye dönüştü: “ hedef mimarinize ulaşmak için organizasyonunuzu değiştirin ”. Aptalca çünkü unutmayın: "Kültür stratejiyi kahvaltıda yer". Daha fazla bilgi burada bu ilginç iş parçacığında.
• Etki Alanına Yönelik Tasarım, herhangi bir organizasyon dayatmaz. İşlevsiz organizasyonlar (savaşta olan veya birbirini görmezden gelen ekiplerle) durumları da dahil olmak üzere, hayatta kalmayı sağlamak için anahtarlar verir. DDD, ekipler arasındaki güç sorunlarını ve sosyal sorunları anlamamıza yardımcı olur. Sonuç olarak, determinizmlerimize karşı bir özgürleşme aracıdır ( dolayısıyla solcu bir araç diyebilirim ;-)
• Öte yandan, DDD, etki alanına göre mümkün olduğunca uyumlu, verimli yazılımlar tasarlayabilmemiz için bize araçlar sunar. Bunların arasında, kullanımlar için modeller tasarlamamızı ve onları çevrelememizi ve diğer bağlamlardan kaynaklanan kafa karışıklıklarına/yanlış arkadaşlara/yanlış anlamalara karşı koruma sağlamamızı öneren Sınırlı Bağlam (BC) kavramı.
• Daha fazla uyum ve verimlilik için DDD ayrıca vizyonumuzu ve çözüm modellememizi düzenli olarak sorgulamamızı şiddetle tavsiye eder. Aynı zamanda, bir eureka anını ( Tasarım Atılımı olarak adlandırılır) takiben zaman zaman modellerde devrim yapmak ve değiştirmek anlamına gelir . Bu nedenle, burada düzenli olarak Ürün çalışanları ile sahaya ilişkin vizyonumuzu geliştiren Bağlam haritası oturumları düzenliyoruz.
• Geliştirici ekiplerin hassas dengeleri vardır. Bir geliştirme ekibinin gerçekten etkili olabilmesi için birlikte yaşama ve kişiler arası ilişkiler yaklaşık 6 ay sürer. Bu takıma tek bir kişi ekler veya çıkarırsınız ve bu artık aynı takım değildir (bkz . Dinamik Yeniden Takım Oluşturma ). Verimlilik açısından, konulara göre patlatılan/yeniden dağıtılan takımlardansa, bir arada durup konu değiştiren takımları tercih ederim. Elbette takımından veya konularından bıkmış biri varsa, takım değiştirmesi için her şey yapılmalı (kişisel olarak iyi olmak kollektif verimliliğimiz için daha da önemlidir)
• Agicap'taki mevcut organizasyonumuz ve ekiplerimiz, sorunun karmaşıklığını hesaba katmak ve ilgili iş uzmanlığımızdan minimum düzeyde yararlanmak için bir veya daha fazla Sınırlı Bağlamla bağlantılıdır. Zaman zaman bazı ekiplerin kapsamı çok geniş olabilir ve Sınırlı Bağlamımızı daha iyi kesip atamamız gerekir. Öte yandan, BC'lerin bu bölümü iş kavramlarıyla bağlantılı kalmalıdır (DDD'yi hatırlayın)
• Herkes Sınırlı Bağlamların sınırlarına saygı duyduğu sürece , DDD yapan bir kuruluşta özellik ekiplerine sahip olmayı hiçbir şey yasaklamaz .
• Şimdilik, Swarming uygulamasını (birkaç ekipten insanlarla kurulan ancak nihai eserin (araç, api, kitaplık) sorumluluğunun ve sahipliğinin baştan tanımlandığı bir tür görev gücü) uygulamasını büyük ölçüde tercih ediyoruz. “Güzel, birlikte bir şeyler yaptık ama şimdi bunu kim sürdürecek?!?” sendromundan kaçınmak için). Sürü oluşturma, konuya bağlı olarak doğru kişilerin işbirliği yapmasını sağlamadaki etkinliğinin ötesinde, ekipler arası kişilerarası ilişkileri geçici olarak teşvik ederek kuruluşumuza çok fazla sosyal sermaye getirir (herkes ekibine döndüğünde gelecek için çok yararlıdır).
• Mevcut Ürün organizasyonumuz, geliştirme ekibi başına 1 Ürün Yöneticisi (PM) olarak ayarlanmıştır, ancak PM'lerin kendi ekiplerinden çok iş konularıyla ilişkili olması ilginç olabilir mi?

Son olarak, organizasyonda dev'de sahip olduğumuzdan daha fazla sihirli değnek olmadığını söyleyebilirim. Sürekli geri bildirim, sorgulama ve deneyler, kullanıcılarımızla alakalı yazılımları etkili bir şekilde yapmak için bu sürekli iyileştirme yolunda yol arkadaşlarımızdır.

Not: Bu yazı geçen hafta (14 Ekim 2022) yazılan Fransızca bir makalenin çevirisidir.

Agicap hakkında daha fazla bilgi için:

• Bana Etki Alanınızı gösterin ( Nakit Akışı izleme ve bağlam haritası tahmini oturumu )
• https://agicap.com/
• https://career.agicap.com/