แบ่งการพัฒนาสแต็ค - ตามแนวทแยง?


11

เรามีโครงการใหม่ที่เกิดขึ้นและในขณะที่นักพัฒนาได้ถูกแบ่งออกเป็นสองทีมทีม A และทีม B โครงการนี้มี 2 ส่วนซึ่งจำเป็นต้องมีการพัฒนาตลอดทั้งกองพัฒนา ตัวอย่างสแต็กของเราที่แสดงด้านล่างง่ายมาก:

ป้อนคำอธิบายรูปภาพที่นี่

แต่ละส่วนของโครงการต้องการการพัฒนาข้ามสแต็คทั้งหมดดังนั้นโดยทั่วไปฉันคาดหวังว่าแนวทางการพัฒนาสแต็คเต็มรูปแบบซึ่งเป็นวิธีที่เราแยกย่อยงานของเราภายในทีม B การออกแบบและการโต้ตอบระหว่างส่วนต่าง ๆ

ป้อนคำอธิบายรูปภาพที่นี่

อย่างไรก็ตามเมื่อเร็ว ๆ นี้ฉันได้เรียนรู้ว่าทีม A ต้องการรับผิดชอบบางส่วนของสแต็กและพวกเขากำลังเสนอการแบ่งแยกระหว่างสองทีมที่ Data Abstraction Layer (และวางเนื้อหาใน Data layer) ถูกจัดการโดย ตัวเองโดยไม่มีการพัฒนาจากทีม B. การแบ่งจะดูคล้ายกับ:

ป้อนคำอธิบายรูปภาพที่นี่

สำหรับฉันแล้วมันรู้สึกไม่เป็นธรรมชาติมาก แต่ละทีมมีวัตถุประสงค์และระยะเวลาที่แตกต่างกันในการบรรลุเป้าหมายเหล่านี้ แต่ทีม B จะต้องพึ่งพาทีม A ในการใช้คุณสมบัติ วิธีแก้ปัญหาที่เสนอคืออินเตอร์เฟสทั่วไปถูกกำหนดไว้ล่วงหน้า (อาจมีระยะเวลา 2 ปีในโครงการเพื่อให้สามารถใช้งานได้จำนวนมาก) ทีม A จะพัฒนาบิตที่ต้องการให้กับอินเทอร์เฟซเหล่านี้ แต่เนิ่นๆแม้ว่าจะมีชุดเป้าหมายเป็นของตัวเองในขณะที่ทีม B จะเรียกสายทั้งหมดในระยะสั้นเพื่อให้พวกเขาสามารถดำเนินการต่อไปได้

ฉันมีความกังวลเกี่ยวกับวิธีการนี้เกี่ยวกับ:

  • อินเทอร์เฟซอาจเปลี่ยนแปลงและทีม A อาจไม่มีแบนด์วิดท์หรือเวลาเพื่อรองรับความต้องการที่เปลี่ยนแปลง
  • ข้อบกพร่องในรหัสของทีม A สามารถป้องกันไม่ให้ทีม B ดำเนินการต่อและอีกครั้งพวกเขาอาจไม่ได้รับความสำคัญในการแก้ไขปัญหาเหล่านี้เนื่องจากทีม A มีคิวจัดลำดับความสำคัญที่แตกต่างกัน
  • การขาดความรู้กระจายไปทั่วทั้งทีม - ทีม B อาจไม่เข้าใจอย่างสมบูรณ์ว่าเกิดอะไรขึ้นภายใต้ประทุนและอาจตัดสินใจออกแบบที่ไม่ดีเพราะสิ่งนี้

มีคนแนะนำว่าหลาย บริษัท ในอุตสาหกรรมมีทีมย่อยและต้องสามารถจัดการเรื่องนี้ได้ จากความเข้าใจของฉันโดยทั่วไปแล้วทีมจะแยกตามที่ฉันคาดหวังไว้ตอนแรก (Full Stack) หรือโดยการแบ่งกองเทคโนโลยีดังนี้:

ป้อนคำอธิบายรูปภาพที่นี่

ดังนั้นฉันจึงสนใจที่จะรู้ว่าส่วนที่เหลือของอุตสาหกรรมกำลังทำอะไร แยกแนวตั้ง / แนวนอนได้มากที่สุดหรือไม่ การแบ่งในแนวทแยงทำให้รู้สึกหรือไม่? หากมีการแยกส่วนในแนวทแยงเกิดขึ้นข้อกังวลของฉันดูเหมือนจะใช้ได้และมีสิ่งใดที่ทีมขควรกังวลอีกหรือไม่ หากต้องการทราบว่าฉันอาจจะต้องรับผิดชอบต่อความสำเร็จหรือความล้มเหลวของทีมบี


10
"ส่วนที่เหลือของอุตสาหกรรม" น่าจะทำทุกอย่างที่คุณนึกถึง แต่จริงๆแล้วคุณไม่ได้บอกเราว่าทำไมทีม A ถึงต้องการรับผิดชอบ และมันสร้างความแตกต่างว่าทีมของคุณจะใหญ่ขนาดไหนและถ้าหากพวกเขามีคุณสมบัติเท่าเทียมกัน
Doc Brown

ในภาพประกอบที่สามของคุณงานของทีม A และทีม B คั่นด้วย API ที่ต่างกันหรือไม่ มีขอบเขตที่ชัดเจนและเป็นตรรกะที่กำหนดโดยเส้นแบ่งนั้นหรือไม่? การแบ่งงานไม่ใช่สิ่งใหม่อย่างแน่นอน Stack Exchange มีนักออกแบบเป็นของตัวเอง
Robert Harvey

@DocBrown ฉันเชื่อว่าทีม A ต้องการรับผิดชอบเพราะพวกเขารู้สึกว่า 'พ่อครัวมากเกินไปทำให้น้ำซุปเสีย' หลังจากความล้มเหลวของโครงการก่อนหน้านี้กับทีมที่ใหญ่กว่า - แต่ฉันไม่รู้แน่ชัด ทีมแต่ละทีมมีประมาณ 5 Devs และมีทักษะพอ ๆ กัน
เอียน

1
หากคุณไม่ประสบความสำเร็จในการโน้มน้าวใจพวกเขาในแนวดิ่งคุณอาจต้องการให้ทีม A มุ่งมั่นที่จะจัดการกับคำขอของทีม B ที่มีลำดับความสำคัญสูงกว่าตามคำขอของพวกเขาเอง สิ่งนี้สามารถป้องกันการปิดกั้นและเลือดไม่ดีและดูเหมือนว่าจะจ่ายในราคายุติธรรม
Hans-Peter Störr

1
@hstoerr: น่าสนใจว่านี่เป็นสิ่งที่พันธมิตรการต่อสู้แนะนำทีมองค์ประกอบการบริโภค (ทีมองค์ประกอบที่ใช้หรือ "กิน" การส่งมอบของทีมส่วนประกอบอื่น ๆ ) ทำหน้าที่เป็นเจ้าของผลิตภัณฑ์ของทีมผู้ผลิต นำมาจากscrumalliance.org/community/articles/2012/september/…
เอียน

คำตอบ:


12

ความกังวลของคุณถูกต้องมาก โดยเฉพาะอย่างยิ่งสองจุดแรกเกี่ยวกับทีม A ที่ไม่มีเวลาเพิ่มคุณสมบัติหรือแก้ไขข้อบกพร่องที่ส่งผลกระทบต่อทีม B. ฉันเห็นสิ่งนี้เกิดขึ้นในงานของตัวเองค่อนข้างน้อย

นี่อาจเป็นความคิดที่ดีถ้า:

  • เป็นที่ทราบกันว่าทีม A จะทำงานในโครงการที่ต้องการคุณสมบัติใหม่ในฐานข้อมูลในขณะที่เป้าหมายของทีม B นั้นเป็นสิ่งสำคัญที่จะทำคุณสมบัติ "frontend" เท่านั้น ตัวอย่างเช่นหากทีม B กำลังเขียนแอป iPhone ใหม่ของ บริษัท ของคุณอาจเป็นไปได้ว่าพวกเขาจะไม่เพิ่มเขตข้อมูลฐานข้อมูลใหม่ในขณะที่พวกเขาจำเป็นต้องพอร์ต / ใช้งานคุณลักษณะทั้งหมดของรุ่นเดสก์ท็อปอีกครั้ง

  • "สแต็กเต็ม" มีความซับซ้อนเพียงพอที่ไม่มี dev เดียว (หรือทีม dev) ที่สามารถ "เป็นเจ้าของ" สิ่งทั้งหมดได้อย่างมีประสิทธิภาพ โดย "เจ้าของ" ฉันหมายถึงไม่เพียง แต่เพิ่มคุณสมบัติและแก้ไขข้อบกพร่อง แต่เข้าใจและใส่ใจเกี่ยวกับระบบทั้งหมดจนถึงจุดที่พวกเขาสามารถหลีกเลี่ยงการเพิ่มหนี้ทางเทคนิคมากขึ้นในช่วงเวลา ในกรณีนี้การแบ่ง "ทแยงมุม" เป็นการเคลื่อนไหวที่สมเหตุสมผลหากทีม A เป็นเจ้าของ UI / Web API ที่ง่ายมากหรือหลีกเลี่ยงไม่ได้ในการใช้ DAL / ฐานข้อมูล (อาจเป็นเครื่องมือวินิจฉัยภายในบ้าง) ในขณะที่ทีม B ทุกสิ่งที่ซับซ้อนส่วนหน้าผู้ใช้หันหน้าไปทาง

  • ฝ่ายบริหารเข้าใจถึงความเสี่ยงของการเป็นทีมที่เป็นคอขวดและยินดีที่จะแยกสิ่งต่าง ๆ ออกไปถ้าหากหรือเมื่อความเสี่ยงนี้กลายเป็นปัญหาจริง

ฉันไม่สามารถพูดกับสิ่งที่พบได้บ่อยในอุตสาหกรรม แต่อย่างน้อยที่ฉันทำงานมีความต้องการที่ชัดเจนสำหรับนักพัฒนาแอปพลิเคชันทั้งหมดที่จะ "เต็มสแต็ค" สิ่งที่เรามีคือทีม "โครงสร้างพื้นฐาน" ที่พัฒนา / บำรุงรักษาฐานข้อมูลภายในของเรากรอบบริการเว็บและกรอบ UI ของเรา (ฉันไม่ได้พูดถึง บริษัท ของฉันใหญ่หรือไม่) เพื่อให้แอปพลิเคชันนับร้อย ๆ devs ในขณะที่ บริษัท โดยรวมยังคงสามารถให้บริการที่สอดคล้องและ UI กับบริการทั้งหมดของเรา

เมื่อเร็ว ๆ นี้ บริษัท ของเรากำลังสร้างเฟรมเวิร์ก UI ใหม่ล่าสุดดังนั้นจึงมีช่วงเวลาที่แอพใหม่ของเราบางส่วนถูกบล็อกอย่างไม่ดีนักเกี่ยวกับข้อบกพร่องและคุณสมบัติที่ขาดหายไปในเฟรมเวิร์กใหม่ นี่ไม่ใช่กรณีอีกต่อไปแล้วส่วนใหญ่เป็นเพราะพวกเราบางคนได้รับอนุญาตให้ส่งคำขอดึงไปยังทีมที่เป็นเจ้าของเฟรมเวิร์ก (ไม่ใช่ "de-diagonalization" แต่คุณเข้าใจแล้ว)


2
ในจุดที่สองของคุณนี่เป็นเรื่องจริงสำหรับแอปพลิเคชันทางธุรกิจที่มีขนาดพอสมควร ไลบรารีที่มี API ที่กำหนดไว้อย่างดีนั้นดูเหมือนว่าจะเป็นขอบเขตแบบลอจิคัลเนื่องจากมีขนาดไม่ใหญ่เกินไป
Robert Harvey
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.