หากทั้งสองทีมต่อสู้กันโดยใช้ส่วนประกอบซอฟต์แวร์เดียวกันใครเป็นผู้รับผิดชอบในการจัดหาวิสัยทัศน์ทางสถาปัตยกรรมที่ชัดเจนของส่วนประกอบนั้นและรักษา / พัฒนาวิสัยทัศน์นี้เมื่อฐานรหัสวิวัฒนาการ ใน Scrum คุณควรจะมีกรรมสิทธิ์รหัสแบบรวมดังนั้นวิธีการตรวจสอบให้แน่ใจว่าการพัฒนาที่ทำโดยทีม A ไม่ได้ยุ่งเกี่ยวกับการพัฒนาที่ทำโดยทีม B
คำตอบ:
ฉันไม่ใช่ผู้เชี่ยวชาญ Scrum แต่ AFAIK "ความเป็นเจ้าของรหัสส่วนรวม" นั้นมีไว้สำหรับทีมงานและต่อผลิตภัณฑ์ (และฉันคิดว่าคำถามของคุณไม่เฉพาะกับ Scrum มันสามารถนำไปใช้กับกระบวนการพัฒนา "รหัสที่ใช้ร่วมกัน")
หากคุณมีสองทีม A, B, สองผลิตภัณฑ์ A, B และคอมโพเนนต์ที่แชร์ C จะมีสถานการณ์ที่แตกต่างกัน บางทีองค์ประกอบที่ใช้ร่วมกันเป็นหลักในผลิตภัณฑ์ A (และเพิ่งนำมาใช้ใหม่ แต่ไม่ได้รับการพัฒนาโดยทีมงานสำหรับผลิตภัณฑ์ B) ในสถานการณ์นี้ทีม A มีหน้าที่รับผิดชอบในการมองเห็นสถาปัตยกรรมอย่างชัดเจน หรือในทางกลับกัน: เป็นของผลิตภัณฑ์ B อย่างชัดเจน - ดังนั้นความรับผิดชอบจึงอยู่ที่นั่น หากทีม A มีความรับผิดชอบทีม B อาจใช้ทางแยกขององค์ประกอบเพื่ออนุญาตการแก้ไขข้อบกพร่องอย่างเร่งด่วน (ควรมีวิธีที่จะรวมพวกมันกลับเข้าไปในสายหลักของ C) แต่ B ควรหลีกเลี่ยงการพัฒนาส่วนประกอบที่ใหญ่กว่า
อย่างไรก็ตามหากทั้งสองผลิตภัณฑ์ A และ B มี "ข้อกำหนดการขับขี่" สำหรับ C จำนวนมากคุณควรจัดการ C เป็นผลิตภัณฑ์ที่แยกจากกันอย่างสมบูรณ์พร้อมการกำหนดเวอร์ชันการจัดการการปล่อยการจัดการการเปลี่ยนแปลงการทดสอบหน่วย ฯลฯ และทีมแยกต่างหากที่มี ความรับผิดชอบสำหรับองค์ประกอบนั้น ทีมนั้นอาจเป็นเพียง "ทีมเสมือนจริง" ซึ่งประกอบด้วย devs แยกจากทีม A, B หรือทั้งสองอย่าง ทีมนี้มี "ความเป็นเจ้าของรหัสที่ใช้ร่วมกัน" สำหรับ C และความรับผิดชอบสำหรับ "วิสัยทัศน์ด้านสถาปัตยกรรม" แค่คิดว่า C beeing ส่วนประกอบที่จัดส่งโดยผู้ขายบุคคลที่สาม
ไม่มีแนวคิดของ "การมองเห็นสถาปัตยกรรมที่ชัดเจน" ในการต่อสู้หรือเปรียว!
ฉันเป็นสถาปนิกมานานและเป็นที่ชัดเจนว่าสำหรับการมีวิสัยทัศน์ทางสถาปัตยกรรมเราจำเป็นต้องมีมุมมองที่ชัดเจนเกี่ยวกับข้อกำหนดในอนาคต เนื่องจากในกรณีส่วนใหญ่ข้อกำหนดไม่ชัดเจนเลยมันไม่มีเหตุผลที่จะมีวิสัยทัศน์ที่แน่นอน
สิ่งที่จำเป็นคือการมีสถาปัตยกรรมที่สามารถปรับให้เข้ากับความต้องการที่เปลี่ยนแปลงได้ กล่าวอีกนัยหนึ่งการเปลี่ยนแปลงสิ่งต่าง ๆ และการเปลี่ยนแปลงทางสถาปัตยกรรม - ฉันไม่ได้สนับสนุนสถาปัตยกรรม "อ่อน" ที่สามารถกำหนดค่าใหม่ได้ ฉันกำลังพูดถึงการยอมรับว่าสถาปัตยกรรมที่มีอยู่ในปัจจุบันจะล้าสมัยเร็ว ๆ นี้และจะต้องมีการเปลี่ยนแปลงดังนั้นจึงไม่มีใครควร "แต่งงาน" กับมัน
การเป็นเจ้าของรหัสแบบรวมหมายความว่าทุกคนควรในทางทฤษฎีสามารถเปลี่ยนแปลงอะไรก็ได้ สิ่งนี้จะต้องเข้าใจว่าเป็น "ตรงกันข้ามกับไซโล" กล่าวอีกนัยหนึ่งอาจมีอุปสรรคในการทำงานซึ่งเป็นเรื่องปกติและคาดว่าไม่ใช่ทุกคนเป็น DBA ที่มีประสบการณ์ที่สามารถปรับคิวรี SQL เพื่อปรับตัวอย่าง - แต่จากนี้มันไม่เป็นไปตามที่ DBA เท่านั้นที่สามารถทำได้ การเพิ่มประสิทธิภาพการค้นหาด้วยมือ จะมี "ผู้เชี่ยวชาญด้านโดเมนคุณสมบัติ" ที่สามารถช่วยให้คนอื่นมีความเชี่ยวชาญ แต่งานก็ยังควรตกอยู่กับทุกคน
ตัวอย่างเช่น: หากฉันเป็นผู้เชี่ยวชาญด้านโดเมนในฟีเจอร์ "A" ฉันก็ยังคาดหวังว่าคนอื่นจะทำงานเกี่ยวกับคุณสมบัติ "A" แต่ฉันมีแนวโน้มที่จะได้รับการพิจารณาเมื่อการเปลี่ยนแปลงที่สำคัญเกิดขึ้นหรือผู้คนต้องการความช่วยเหลือ คุณสมบัติ "A" จะไม่ใช่คุณสมบัติของฉันอย่างแน่นอน มันจะเป็นคุณสมบัติที่ฉันรู้ดี ฉันจะสนใจที่จะทราบคุณสมบัติอื่น ๆ อีกมากมายและความสนใจของผู้อื่นที่จะรู้คุณลักษณะนี้
ในการสังเคราะห์: สถาปัตยกรรมได้รับการออกแบบและออกแบบใหม่หลายครั้งโดยผู้พัฒนาเนื่องจากความต้องการเกิดขึ้นและเปลี่ยนแปลง ทุกคนคาดว่าจะทำการเปลี่ยนแปลงที่จำเป็นตามทักษะของพวกเขาและรู้ว่าเมื่อไหร่ที่จะขอความช่วยเหลือ ไม่มีวิสัยทัศน์ระยะยาวกับสถาปัตยกรรมเพราะเป็นเราไว้วางใจคนและเราไม่ไว้วางใจความต้องการ
ตัวอย่างเช่น spotify ใช้บทบาทชื่อ "เจ้าของระบบ" เพื่อแก้ปัญหาโดยตรงจากเอกสาร:
ในทางเทคนิคทุกคนได้รับอนุญาตให้แก้ไขระบบใด ๆ เนื่องจากทีมเป็นทีมที่มีประสิทธิภาพพวกเขาจึงต้องอัปเดตหลายระบบเพื่อให้ได้คุณสมบัติใหม่ในการผลิต ความเสี่ยงกับรุ่นนี้คือสถาปัตยกรรมของระบบเกิดความสับสนหากไม่มีใครมุ่งความสมบูรณ์ของระบบโดยรวม
เพื่อลดความเสี่ยงนี้เรามีบทบาทที่เรียกว่า "เจ้าของระบบ" ระบบทั้งหมดมีเจ้าของระบบหรือเป็นเจ้าของระบบ (เราขอแนะนำให้จับคู่) สำหรับระบบที่มีความสำคัญในการดำเนินการเจ้าของระบบคือคู่ Dev-Ops นั่นคือบุคคลหนึ่งที่มีมุมมองนักพัฒนาและอีกหนึ่งคนที่มีมุมมองการดำเนินงาน
เจ้าของระบบคือบุคคล“ ไปที่” สำหรับปัญหาด้านเทคนิคหรือสถาปัตยกรรมใด ๆ ที่เกี่ยวข้องกับระบบนั้น เขาเป็นผู้ประสานงานและแนะนำผู้ที่ใช้รหัสในระบบนั้นเพื่อให้แน่ใจว่าพวกเขาจะไม่สะดุดกัน เขามุ่งเน้นไปที่สิ่งต่าง ๆ เช่นคุณภาพเอกสารหนี้สินทางเทคนิคความมั่นคงความสามารถในการปรับขนาดและกระบวนการเผยแพร่
เจ้าของระบบไม่ใช่สถาปนิกคอขวดหรือหอคอยงาช้าง เขาไม่จำเป็นต้องทำการตัดสินใจทั้งหมดเองหรือเขียนรหัสทั้งหมดหรือเผยแพร่ทั้งหมด เขามักจะเป็นสมาชิกทีมหรือหัวหน้าบทที่มีความรับผิดชอบแบบวันต่อวันนอกเหนือจากการเป็นเจ้าของระบบ อย่างไรก็ตามในบางครั้งเขาจะใช้ "วันเจ้าของระบบ" และทำงานทำความสะอาดในระบบนั้น โดยปกติเราพยายามรักษาความเป็นเจ้าของระบบนี้ให้น้อยกว่าหนึ่งในสิบของเวลาของบุคคล แต่มันก็แตกต่างกันมากระหว่างระบบของหลักสูตร
ฉันชอบความคิดนี้การมีประโยชน์หรือการเป็นเจ้าของรหัสโดยรวมในระดับ บริษัท (ไม่เพียง แต่ในระดับทีม) แต่ด้วยเจ้าของระบบนี้พยายามที่จะรับประกันความสมบูรณ์ของสถาปัตยกรรม
ลิงก์ไปยังเอกสารฉบับสมบูรณ์: https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdfเอกสารฉบับสั้น แต่น่าสนใจมากซึ่งมีประสบการณ์จริงเกี่ยวกับการปรับขนาด
มันเป็นปัญหาที่ยากที่จะแก้ไขและแน่นอนว่ามันไม่ได้ถูกแก้ไขโดย Scrum ซึ่งเป็นวิธีการจัดการโครงการไม่ใช่วิธีการพัฒนา
โซลูชันที่มีประสิทธิภาพที่สุดที่ฉันพบคือการจัดการแพ็คเกจที่ดี (nuget / gem / ฯลฯ ) และการกำหนดเวอร์ชัน อย่าบังคับให้มีการเปลี่ยนแปลงในทีมอื่นจนกว่าพวกเขาจะพร้อมที่จะบริโภค ปล่อยให้พวกเขาใช้งานบิลด์เก่าต่อไปในขณะที่คุณย้ายไปที่ใหม่
ตรวจสอบให้แน่ใจว่าคุณมีกลยุทธ์การกำหนดเวอร์ชันที่ทำให้ชัดเจนว่าการเปลี่ยนแปลงใดที่กำลังทำลายและเป็นส่วนขยาย
นอกจากนี้เมื่อคุณทำการเปลี่ยนแปลงให้ส่งบทวิจารณ์รหัสให้กับใครสักคนในแต่ละทีม ให้พวกเขาดูว่ามันมีแนวโน้มที่จะส่งผลกระทบต่อพวกเขาอย่างไรก่อนที่พวกเขาจะถูกบังคับให้บริโภคมันเพื่อที่พวกเขาจะสามารถดำเนินการเปลี่ยนแปลงของตัวเองได้
และเมื่อสิ่งต่าง ๆ ยุ่งเหยิงจริงๆ เมื่อทีมหนึ่งต้องการเปลี่ยนแปลงและไม่สามารถใช้การเปลี่ยนแปลงอื่น ๆ ได้ง่าย (นี่ควรเป็นกรณีที่หายากจริงๆ) ให้ทำการแยกรหัสทำให้มันเป็นแพ็คเกจที่แตกต่างกันโดยสิ้นเชิง ช่วยให้
คำตอบที่ไม่ชัดเจนเท่าที่ควรคือให้ทีมตัดสินใจว่าจะแบ่งปันองค์ประกอบที่กำหนดได้อย่างไร
ตัวอย่างเช่นทีมของฉันเพิ่งเริ่มพัฒนาสายผลิตภัณฑ์ใหม่ที่ใช้รหัสร่วมกันจำนวนมากร่วมกับอีกสองทีมที่พัฒนาผลิตภัณฑ์ที่คล้ายกันมาเป็นเวลานาน ผลิตภัณฑ์ของเรามีความแตกต่างกันในบางวิธีดังนั้นบางครั้งเราต้องหาวิธีเพิ่มคะแนนการปรับแต่งให้กับรหัสทั่วไป
เรามีการปะทะกันเกี่ยวกับรหัสนั้นและลองวิธีเฉพาะกิจหลายวิธีในการจัดการกับความเป็นเจ้าของร่วมกัน จากนั้นเมื่อมีฟีเจอร์ใหม่ขนาดใหญ่ขึ้นมาเราตัดสินใจว่าเราจะต้องรวมทีมทั้งหมดเข้าด้วยกันเพื่อให้ได้หน้าเดียวกันซึ่งส่งผลให้กลุ่มเล็ก ๆ ประกอบด้วยสมาชิกสองคนจากแต่ละทีมที่ทำรายละเอียด
วิธีแก้ปัญหาที่ทีมของเราออกมาอาจไม่ทำงานในสถานการณ์อื่น คุณอาจต้องการอะไรที่ง่ายกว่านี้หรืออะไรที่เป็นทางการมากกว่า ประเด็นก็คือคุณรับกรรมสิทธิ์ร่วมและหาว่าอะไรเหมาะกับคุณ
ฉันจะแสดงความคิดเห็น:
หากสมมติฐานข้างต้นถูกต้องแล้วบางครั้งก็ควรมีเวลาเมื่อทั้งสองทีมจะรบกวนซึ่งกันและกัน พวกเขาสามารถแก้ไขได้โดยใช้วิธีต่อไปนี้: