“DDD เป็นสิ่งที่ฝ่ายขวา!”

เบื้องหลังข้อความยั่วยุนี้ (เหมาะสำหรับการเสนอขายในเซสชั่นที่ไม่เปิดเผยและมีผู้ร่วมงาน) Simon Chaveneauต้องการถามตัวเองเกี่ยวกับผลกระทบของ Domain Driven Design (DDD) ต่อองค์กรของเรา (Product-Tech) เพื่อผลิตซอฟต์แวร์ สิ่งนี้เกิดขึ้นระหว่างการประชุมครั้งแรกของเราที่ Agicap ซึ่งจัดขึ้นเพื่อให้ผลิตภัณฑ์และบุคลากรด้านเทคโนโลยีได้มาพบปะเพื่อพูดคุย เรียนรู้ แบ่งปัน หัวเราะ แต่เหนือสิ่งอื่นใดคือความยิ่งใหญ่ที่เกี่ยวข้องกับชีวิตประจำวันของเรา

ในระหว่างการประชุม ผู้ชมเป็นผู้กำหนดโปรแกรม เสร็จสิ้นในช่วงเริ่มต้นของ “Market Place” ในช่วงเช้า ในช่วงแรกของวันนี้ ทุกคนสามารถคว้าไม้เท้า ปากกามาร์คเกอร์ แล้วแสดงเซสชันของตนต่อหน้าทุกคน จากนั้นผู้คนก็วางตำแหน่งพวกเขาในรายการของวัน (สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ unconference นี้มีหัวข้อ Twitter นี้ )

แต่ขอกลับไปที่หัวข้อและเซสชันที่น่าสนใจที่เสนอโดยไซมอน

ครองสมบัติส่วนตัว?

ในการสรุปสำนวนการขายเบื้องต้นของไซมอน: หากส่วนต่างๆ ของ IS ของเราเป็นของทีม — แต่ละทีมรับผิดชอบในบริบทที่มีขอบเขต (BC) อย่างน้อยหนึ่งรายการ — เราจะไม่ต้องเผชิญกับเวอร์ชันซอฟต์แวร์ของทรัพย์สินส่วนตัว (ที่มีลวดหนามรอบๆ BCs ฯลฯ .)? ดังนั้นการยั่วยุของเขา “ DDD เป็นสิ่งที่ฝ่ายขวา! ”

และด้วยคำถามรอง: “เราจะไม่มีประสิทธิภาพมากขึ้นกับองค์กรที่อิงตามฟีเจอร์ทีมหรือ? (โดยทุกคนสามารถทำงานกับ BC ทั้งหมดได้ระหว่างทางไปสู่กรณีการใช้งานของพวกเขา)”

อืม… ฉันต้องยอมรับว่าเซสชันนี้มีผลมากกว่าที่ฉันคาดไว้ในตอนแรกมาก เพราะมีการอภิปรายที่น่าสนใจเกี่ยวกับโหมดองค์กรผลิตภัณฑ์/เทคโนโลยีของเรา

แต่แทนที่จะให้รายละเอียดเกี่ยวกับเส้นทางของเซสชันนี้ที่เราไปกันมากมาย (แน่นอนว่าน่าสนใจที่จะอธิบายในบริบทของโพสต์อื่น) ฉันจะอธิบายโดยตรงถึงสิ่งที่ฉันได้เก็บไว้และคิดเกี่ยวกับหัวข้อนี้

ข้อสังเกตบางประการ

• ซอฟต์แวร์ที่มีประสิทธิภาพคือซอฟต์แวร์ที่สอดคล้องกับความท้าทายทางธุรกิจ เราหมายถึงซอฟต์แวร์ที่ยืมคำศัพท์ที่ถูกต้องจากช่องโดเมน ซึ่งแสดงแนวคิดหลักของธุรกิจได้อย่างถูกต้อง และเรียกใช้ความซับซ้อนโดยบังเอิญที่เกิดจากปัญหาทางเทคนิคให้น้อยที่สุดเท่าที่จะเป็นไปได้ นี่เป็นหนึ่งในความท้าทายหลักของ Domain Driven Design (DDD) ดังที่จะอธิบายใน 3 นาทีนี้
• กฎของคอนเวย์ไม่ใช่ทางเลือกที่เราจะเลือกไม่ใช้ ‍♂️มันทำหน้าที่คล้ายกับกฎทางกายภาพบางอย่าง เช่น แรงดึงดูดของแรงโน้มถ่วง เราสามารถพยายามต่อสู้กับมันได้ ;-) แต่ก็ยังใช้ได้บนโลก กฎของคอนเวย์คือกฎหมายปี 1967 ที่ระบุว่า
  "องค์กรใดๆ ที่ออกแบบระบบ (กำหนดอย่างกว้างๆ) จะสร้างการออกแบบที่มีโครงสร้างเป็นสำเนาของโครงสร้างการสื่อสารขององค์กร"
  กล่าวอีกนัยหนึ่ง สถาปัตยกรรมของซอฟต์แวร์จำเป็นต้องเป็นผลมาจากรูปแบบการสื่อสารของผู้ที่เกี่ยวข้องกับการออกแบบ ตัวอย่างเช่น คอมไพเลอร์ที่พัฒนาโดย 3 ทีมมักจะทำงานใน 3 รอบหรือมี 3 โมดูลที่แตกต่างกัน
• Inverse Conway Maneuver (ICM) ทำให้คุณคิดว่าเราสามารถควบคุมกฎของคอนเวย์ได้ ในขั้นต้น แผนการผกผันนี้แนะนำอย่างชาญฉลาดเพื่อ " ทลายไซโลที่จำกัดความสามารถของทีมในการทำงานร่วมกันอย่างมีประสิทธิภาพ" แต่ในช่วงหลายปีที่ผ่านมาได้เปลี่ยนมาเป็นคำแนะนำโง่ๆ ที่ว่า “ เปลี่ยนองค์กรของคุณเพื่อไปให้ถึงสถาปัตยกรรมเป้าหมายของคุณ ” โง่เพราะจำไว้ว่า: “วัฒนธรรมกินกลยุทธ์ในมื้อเช้า” ข้อมูลเพิ่มเติมที่นี่ในหัวข้อที่น่าสนใจนั้น
• การออกแบบที่ขับเคลื่อนด้วยโดเมนไม่ได้กำหนดองค์กรใด ๆ มันให้กุญแจในการอยู่รอด รวมถึงในกรณีขององค์กรที่ไม่สมบูรณ์ (กับทีมที่ทำสงครามหรือเพิกเฉยต่อกันและกัน) DDD ช่วยให้เราเข้าใจประเด็นของอำนาจและประเด็นทางสังคมระหว่างทีม เป็นผลให้มันค่อนข้างเป็นเครื่องมือในการปลดปล่อยจากปัจจัยกำหนดของเรา ( ดังนั้นฉันจะบอกว่า เป็นเครื่องมือฝ่ายซ้าย ;-)
• ในทางกลับกันDDD ให้เครื่องมือแก่เราเพื่อให้สามารถออกแบบซอฟต์แวร์ที่มีประสิทธิภาพซึ่งสอดคล้องกับโดเมนมากที่สุด ท่ามกลางแนวคิดของบริบทที่มีขอบเขต (BC) ซึ่งเสนอให้เราออกแบบแบบจำลองสำหรับการใช้งาน และล้อมรอบสิ่งเหล่านั้น และป้องกันความสับสน/เพื่อนที่เข้าใจผิด/ความเข้าใจผิดที่เกิดจากบริบทอื่นๆ
• เพื่อให้สอดคล้องและมีประสิทธิภาพมากขึ้นDDD ยังแนะนำอย่างยิ่งให้เราท้าทายวิสัยทัศน์และการสร้างแบบจำลองของโซลูชันของเราเป็นประจำ นอกจากนี้ยังหมายถึงการปฏิวัติและการเปลี่ยนแปลงโมเดลเป็นครั้งคราวตามช่วงเวลายูเรก้า (เรียกว่าDesign Breakthrough ) นั่นเป็นเหตุผลที่เรามีเซสชันการแมปบริบทเป็นประจำที่นี่เพื่อปรับแต่งวิสัยทัศน์ของเราเกี่ยวกับฟิลด์ด้วยบุคลากรผลิตภัณฑ์อย่างต่อเนื่อง
• ทีมผู้พัฒนามียอดคงเหลือที่เปราะบาง การอยู่ร่วมกันและความสัมพันธ์ระหว่างบุคคลใช้เวลาประมาณ 6 เดือนเพื่อให้ทีมพัฒนามีประสิทธิภาพอย่างแท้จริง คุณเพิ่มหรือลบบุคคลคนเดียวออกจากทีมนี้ และคนๆ นั้นจะไม่ใช่ทีมเดิมอีกต่อไป (ดูที่ Dynamic Reteaming ) ในแง่ของประสิทธิภาพ ฉันชอบทีมที่อยู่ร่วมกันและเปลี่ยนหัวข้อ มากกว่าทีมที่แตกกระจาย/กระจายตามหัวข้อ แน่นอน ถ้ามีคนเบื่อทีมหรือเรื่องของพวกเขา ควรทำทุกอย่างเพื่อให้เป็นไปได้สำหรับพวกเขาที่จะเปลี่ยนทีม (การมีบุคลิกภาพที่ดีนั้นสำคัญยิ่งกว่าสำหรับประสิทธิภาพโดยรวมของเรา)
• องค์กรปัจจุบันของเราและทีมงานของเราที่นี่ที่ Agicap ค่อนข้างจะเกี่ยวข้องกับบริบทที่มีขอบเขตอย่างน้อยหนึ่งรายการ เพื่อที่จะคำนึงถึงความซับซ้อนของปัญหาและใช้ประโยชน์จากความเชี่ยวชาญทางธุรกิจที่เกี่ยวข้องของเราให้น้อยที่สุด ในบางครั้ง ทีมบางทีมอาจมีขอบเขตที่กว้างเกินไป และเราจำเป็นต้องตัดและกำหนดบริบทที่มีขอบเขตของเราให้ดียิ่งขึ้น ในทางกลับกัน แผนก BCs นี้จะต้องเชื่อมโยงกับแนวคิดทางธุรกิจ (อย่าลืม DDD)
• ไม่มีสิ่งใดห้ามไม่ให้มีทีมฟีเจอร์ในองค์กรที่ทำ DDDตราบใดที่ทุกคนเคารพขอบเขตของบริบทที่มีขอบเขต
• ในขณะนี้ เราชอบวิธีปฏิบัติของ Swarming เป็นอย่างมาก (กลุ่มงานประเภทหนึ่งที่จัดตั้งขึ้นด้วยผู้คนจากหลายทีม แต่ที่ซึ่งความรับผิดชอบและความเป็นเจ้าของของสิ่งประดิษฐ์ขั้นสุดท้าย (เครื่องมือ, api, ไลบรารี่) ถูกกำหนดตั้งแต่เริ่มต้น มันช่วยได้ เพื่อหลีกเลี่ยงกลุ่มอาการที่ว่า “ก็ดีนะ เราเคยทำอะไรด้วยกันมาแล้ว แต่ใครจะรักษามันไว้ล่ะ!?”) นอกเหนือจากประสิทธิภาพในการหาคนที่เหมาะสมเพื่อทำงานร่วมกันตามหัวข้อแล้วการจับกลุ่มยังนำทุนทางสังคมจำนวนมากมาสู่องค์กรของเราด้วยการส่งเสริมความสัมพันธ์ระหว่างบุคคลระหว่างทีมเป็นการชั่วคราว (มีประโยชน์อย่างยิ่งสำหรับอนาคตเมื่อทุกคนกลับมาที่ทีมของตน)
• องค์กรผลิตภัณฑ์ปัจจุบันของเราถูกกำหนดให้เป็น 1 Product Manager (PM) ต่อทีมพัฒนา แต่บางทีอาจเป็นเรื่องที่น่าสนใจหาก PMs เกี่ยวข้องกับเรื่องธุรกิจมากกว่ากับทีมของพวกเขา

สุดท้าย ฉันจะบอกว่าไม่มีกระสุนเงินในองค์กรมากไปกว่าที่เรามีใน dev ข้อเสนอแนะ การตั้งคำถาม และการทดลองอย่างต่อเนื่องเป็นเพื่อนร่วมทางของเราในเส้นทางแห่งการปรับปรุงอย่างต่อเนื่องเพื่อสร้างซอฟต์แวร์ที่เกี่ยวข้องกับผู้ใช้ของเราอย่างมีประสิทธิภาพ

หมายเหตุ: โพสต์นี้เป็นการแปลบทความภาษาฝรั่งเศสที่เขียนเมื่อสัปดาห์ที่แล้ว (14 ตุลาคม 2565)

หากต้องการทราบข้อมูลเพิ่มเติมเกี่ยวกับ Agicap:

• แสดงโดเมนของคุณให้ฉันเห็น ( เซสชันการมอนิเตอร์กระแสเงินสด & การคาดการณ์แผนที่บริบท )
• https://agicap.com/
• https://career.agicap.com/