Collaboration (การทำงานร่วมกัน)

บ่อยครั้งเกินไปที่อุตสาหกรรมซอฟต์แวร์มองว่าสถาปัตยกรรมและการพัฒนาเป็นกิจกรรมที่แยกออกจากกันโดยสิ้นเชิง ลองดู Figure 24-1 ซึ่งเปรียบเทียบความรับผิดชอบแบบดั้งเดิมของสถาปนิกกับของนักพัฒนา สถาปนิกมีหน้าที่รับผิดชอบกิจกรรมต่างๆ เช่น การวิเคราะห์ความต้องการทางธุรกิจเพื่อดึงและกำหนดคุณลักษณะทางสถาปัตยกรรม การเลือกแพทเทิร์นและสไตล์สถาปัตยกรรมเพื่อแก้ปัญหาในโดเมนนั้นๆ และการสร้างคอมโพเนนต์เชิงตรรกะ ทีมพัฒนาจะใช้อาร์ติแฟกต์ที่สถาปนิกสร้างขึ้นระหว่างกิจกรรมเหล่านี้เพื่อสร้างไดอะแกรมคลาสสำหรับคอมโพเนนต์ สร้างหน้าจอ UI และเขียนและทดสอบซอร์สโค้ด

Figure 24-1. บทบาทดั้งเดิมของสถาปนิกเทียบกับนักพัฒนา

ภาพใน Figure 24-1 แสดงให้เห็นว่าทำไมแนวทางแบบดั้งเดิมนี้ต่อสถาปัตยกรรมจึงแทบไม่เคยได้ผล ลองดูลูกศรทิศทางเดียวที่ลอดผ่านกำแพงทั้งเสมือนและทางกายภาพ ที่แยกสถาปนิกออกจากนักพัฒนา นั่นแหละคือสิ่งที่ทำให้เกิดปัญหาทั้งหมด การตัดสินใจของสถาปนิกไม่ได้ไปถึงทีมพัฒนาเสมอไป และเมื่อทีมพัฒนาเปลี่ยนแปลงสถาปัตยกรรม มันก็แทบไม่ย้อนกลับไปถึงสถาปนิกเลย ในโมเดลนี้ เพราะสถาปนิกตัดขาดจากทีมพัฒนามากเกินไป สถาปัตยกรรมจึงแทบไม่เคยบรรลุเป้าหมายของมัน

กุญแจสำคัญในการทำให้สถาปัตยกรรมได้ผลคือการทลายกำแพงทั้งทางกายภาพและเสมือนระหว่างสถาปนิกกับนักพัฒนา แล้วสร้างความสัมพันธ์การทำงานร่วมกันแบบสองทิศทางที่แข็งแกร่งขึ้นมาแทน สถาปนิกและทีมพัฒนาต้องอยู่ในทีมเสมือนเดียวกัน เหมือนกับโมเดลการทำงานร่วมกันที่แสดงใน Figure 24-2 โมเดลนี้ไม่เพียงช่วยส่งเสริมการสื่อสารและการทำงานร่วมกันแบบสองทิศทางที่แข็งแกร่งเท่านั้น แต่ยังทำให้สถาปนิกสามารถเป็นเมนเทอร์และโค้ชให้กับนักพัฒนาได้ด้วย

Figure 24-2. การทำให้สถาปัตยกรรมได้ผลผ่านการทำงานร่วมกัน

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

ในส่วนที่เหลือของบทนี้และใน Chapter 25 เราจะแสดงให้คุณเห็นเทคนิคในการสร้างความสัมพันธ์แบบสองทิศทางที่ดีต่อสุขภาพและร่วมมือกัน ซึ่งไม่เพียงทำให้ทีมพัฒนามีประสิทธิภาพมากขึ้น แต่ยังสร้างสถาปัตยกรรมที่แข็งแกร่งและประสบความสำเร็จมากขึ้นด้วย