“DDD là một thứ cánh hữu!”

Đằng sau tuyên bố khiêu khích này (lý tưởng để giới thiệu một phiên không thú nhận và có mọi người), Simon Chaveneau muốn tự đặt câu hỏi về tác động của Thiết kế hướng miền (DDD) đối với tổ chức của chúng tôi (Công nghệ sản phẩm) để sản xuất phần mềm. Điều này xảy ra trong lần đầu tiên chúng tôi không tổ chức hội nghị tại Agicap, được tổ chức để cho phép những người Sản phẩm và Công nghệ gặp nhau để thảo luận, học hỏi, chia sẻ, cười đùa, nhưng trên hết là tăng chiều cao liên quan đến cuộc sống hàng ngày của chúng tôi.

Trong thời gian không hội nghị, chương trình được thiết lập bởi khán giả. Nó được thực hiện trong phiên “Thị trường” đầu tiên vào buổi sáng. Trong buổi họp toàn thể đầu tiên trong ngày này, mỗi người và mọi người có thể lấy giấy dán, bút đánh dấu và sau đó trình bày phần của mình trước mặt mọi người. Sau đó, mọi người định vị chúng trên chương trình trong ngày (để biết thêm thông tin về sự không hợp lý này, có chủ đề twitter này )

Nhưng hãy quay lại chủ đề và phiên họp hấp dẫn do Simon đề xuất.

Sự thống trị của tài sản tư nhân?

Tóm lại ý kiến ​​ban đầu của Simon: nếu toàn bộ phần IS của chúng ta thuộc về các nhóm — mỗi nhóm chịu trách nhiệm về một hoặc nhiều Bounded Context (BC) — chẳng phải chúng ta đang đối mặt với một phiên bản phần mềm của tài sản cá nhân (với dây thép gai xung quanh BC, v.v. .) ? Do đó, lời khiêu khích của anh ấy “ DDD là thứ của cánh hữu! ”

Và với câu hỏi phụ: “Chúng ta sẽ không hiệu quả hơn với một tổ chức dựa trên các nhóm tính năng sao? (với mọi người có thể làm việc trên tất cả các BC trên đường đến trường hợp sử dụng của họ)”

Chà… Tôi phải thừa nhận rằng phiên họp này hóa ra lại hiệu quả hơn nhiều so với những gì tôi mong đợi ban đầu vì một cuộc thảo luận thực sự hấp dẫn đã diễn ra sau đó về chế độ tổ chức Sản phẩm/Công nghệ của chúng tôi.

Nhưng thay vì trình bày chi tiết lộ trình của phiên họp này, nơi chúng tôi có rất nhiều người (chắc chắn sẽ thú vị khi mô tả trong ngữ cảnh của một bài đăng khác), tôi sẽ mô tả trực tiếp những gì tôi đã giữ lại và suy nghĩ về chủ đề này.

Một vài quan sát

• Phần mềm hiệu quả là phần mềm phù hợp với những thách thức kinh doanh . Bằng cách căn chỉnh, chúng tôi muốn nói đến phần mềm mượn các thuật ngữ phù hợp từ trường tên miền, trình bày chính xác các khái niệm chính của doanh nghiệp và triệu tập ít nhất có thể sự phức tạp ngẫu nhiên do các vấn đề kỹ thuật mang lại. Đây là một trong những thách thức chính của Thiết kế hướng miền (DDD), như được giải thích ở đây trong 3 phút .
• Định luật Conway không phải là một lựa chọn mà người ta có thể chọn không thực hiện.‍♂️ Nó hoạt động hơi giống một số định luật vật lý, chẳng hạn như lực hấp dẫn. Chúng ta có thể cố gắng chống lại nó ;-) nhưng nó vẫn còn giá trị trên trái đất. Luật Conway là luật năm 1967 quy định rằng
  “Bất kỳ tổ chức nào thiết kế một hệ thống (được định nghĩa rộng rãi) sẽ tạo ra một thiết kế có cấu trúc là một bản sao của cấu trúc truyền thông của tổ chức.”
  Nói cách khác, kiến ​​trúc của một phần mềm nhất thiết phải là kết quả của các phương thức giao tiếp của những người tham gia thiết kế nó. Chẳng hạn, một trình biên dịch được phát triển bởi 3 nhóm rất có thể sẽ hoạt động trong 3 lượt hoặc có 3 mô-đun riêng biệt.
• Nghịch đảo Conway Maneuver (ICM) cho phép bạn nghĩ rằng một người có thể kiểm soát luật của Conway. Ban đầu, thao tác nghịch đảo này được khuyến nghị một cách khôn ngoan để “ phá vỡ các rào cản hạn chế khả năng cộng tác hiệu quả của nhóm”. Nhưng đã được biến đổi qua nhiều năm thành một khuyến nghị ngớ ngẩn: “ hãy thay đổi tổ chức của bạn để đạt được kiến ​​trúc mục tiêu của bạn ”. Ngớ ngẩn vì hãy nhớ rằng: “Văn hóa ăn chiến lược vào bữa sáng”. Thêm thông tin ở đây trong chủ đề thú vị đó.
• Domain Driven Design không áp đặt bất kỳ tổ chức nào. Nó cung cấp các chìa khóa để có thể tồn tại, kể cả trong trường hợp các tổ chức bị rối loạn chức năng (với các đội đang có chiến tranh hoặc phớt lờ lẫn nhau). DDD giúp chúng ta hiểu các vấn đề về quyền lực và các vấn đề xã hội giữa các nhóm. Kết quả là, nó đúng hơn là một công cụ giải phóng chống lại các thuyết tất định của chúng ta ( do đó tôi có thể nói là một công cụ cánh tả ;-)
• Mặt khác, DDD cung cấp cho chúng tôi các công cụ để có thể thiết kế phần mềm hiệu quả phù hợp nhất có thể với miền. Trong số đó có khái niệm Bối cảnh có giới hạn (BC), đề xuất chúng tôi thiết kế các mô hình để sử dụng, bao quanh chúng và bảo vệ khỏi sự nhầm lẫn/bạn giả/hiểu nhầm do các bối cảnh khác.
• Để có sự liên kết và hiệu quả hơn, DDD cũng đặc biệt khuyến nghị chúng ta nên thường xuyên thử thách tầm nhìn và mô hình hóa giải pháp của mình. Điều đó cũng có nghĩa là thỉnh thoảng phải cách mạng hóa và thay đổi các mô hình sau khoảnh khắc eureka (được gọi là Đột phá về thiết kế ). Đó là lý do tại sao chúng tôi thường xuyên có các phiên bản đồ Ngữ cảnh ở đây để liên tục tinh chỉnh tầm nhìn của chúng tôi về lĩnh vực này với những người Sản phẩm.
• Các nhóm nhà phát triển có sự cân bằng mong manh. Mất khoảng 6 tháng sống cùng nhau và các mối quan hệ giữa các cá nhân để một nhóm phát triển thực sự hiệu quả. Bạn thêm hoặc xóa một người khỏi nhóm này và nó không còn là cùng một nhóm nữa (xem Dynamic Reteaming ). Về hiệu quả, tôi thích các đội ở cùng nhau và thay đổi chủ đề hơn là các đội chỉ bùng nổ / phân bổ lại theo chủ đề. Tất nhiên, nếu ai đó chán ngấy với nhóm của họ hoặc đối tượng của họ, mọi thứ nên được thực hiện để họ có thể thay đổi nhóm (cá nhân khỏe mạnh thậm chí còn quan trọng hơn đối với hiệu quả tập thể của chúng ta)
• Tổ chức hiện tại của chúng tôi và các nhóm của chúng tôi ở đây tại Agicap khá liên kết với một hoặc nhiều Bối cảnh có giới hạn để tính đến mức độ phức tạp của vấn đề và tận dụng tối thiểu chuyên môn kinh doanh tương ứng của chúng tôi. Đôi khi, một số nhóm có thể có phạm vi quá lớn và chúng tôi cần cắt giảm và chỉ định Bối cảnh giới hạn tốt hơn. Mặt khác, bộ phận BC này phải được liên kết với các khái niệm kinh doanh (hãy nhớ DDD)
• Không có gì cấm việc có các nhóm tính năng trong một tổ chức thực hiện DDD , miễn là mọi người tôn trọng ranh giới của Bối cảnh có giới hạn.
• Hiện tại, chúng tôi rất thích thực hành Swarming (một loại lực lượng đặc nhiệm được thành lập với những người từ một số nhóm nhưng trong đó trách nhiệm giải trình và quyền sở hữu vật phẩm cuối cùng (công cụ, api, thư viện) được xác định ngay từ đầu. Nó giúp để tránh hội chứng “Tốt, chúng ta đã làm gì đó cùng nhau, nhưng ai sẽ duy trì nó bây giờ?!?”). Ngoài hiệu quả của nó trong việc thu hút đúng người cộng tác tùy theo chủ đề, bầy đàn mang lại rất nhiều vốn xã hội cho tổ chức của chúng tôi bằng cách tạm thời thúc đẩy các mối quan hệ giữa các cá nhân trong nhóm (siêu hữu ích cho tương lai khi mọi người quay trở lại nhóm của họ).
• Tổ chức Sản phẩm hiện tại của chúng tôi được đặt trên 1 Người quản lý sản phẩm (PM) cho mỗi nhóm nhà phát triển, nhưng có lẽ sẽ rất thú vị nếu các PM được liên kết nhiều hơn với các chủ đề kinh doanh hơn là với nhóm của họ?

Cuối cùng, tôi muốn nói rằng không có viên đạn bạc nào trong tổ chức hơn chúng ta có trong nhà phát triển. Phản hồi, đặt câu hỏi và thử nghiệm liên tục là những người bạn đồng hành của chúng tôi trên con đường cải tiến liên tục này để tạo ra phần mềm hiệu quả phù hợp với người dùng của chúng tôi.

Lưu ý: bài viết này là bản dịch của một bài báo tiếng Pháp được viết vào tuần trước (14/10/2022)

Để biết thêm về Agicap:

• Cho tôi xem Tên miền của bạn ( Phiên bản đồ bối cảnh dự báo và theo dõi dòng tiền )
• https://agicap.com/
• https://career.agicap.com/