อะไรคือวิธีที่ดีที่สุดในการขยายและแยกทีมเปรียวที่สร้างแอปพลิเคชันบนเว็บ

เมื่อเร็ว ๆ นี้ฉันได้เข้าร่วม บริษัท ที่ฉันทำงานเป็นอาจารย์การต่อสู้ในโครงการพัฒนาแบบว่องไวที่สร้างแอปพลิเคชันเว็บ

ทีมกำลังจะมีขนาดสูงสุดสำหรับทีมเปรียว (คาดว่า 9 สัปดาห์หน้า) เราได้พูดคุยเกี่ยวกับการแยกทีมออกเป็นสองทีมไม่มากนักที่จะทำให้สั้นลง (ซึ่งไม่มากเกินไปในขณะนี้) แต่เพื่อหยุดยั้งผู้คนจากการเบื่อในการวางแผนการวิ่งอย่างรวดเร็ว

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

ใครบ้างมีประสบการณ์ในการจัดการกับสิ่งนี้?

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

ฉันชอบแนวตั้งสำหรับทีมของฉันเสมอ UI ควรฟังสิ่งที่คนทางเทคนิคพูดเพราะพวกเขาเป็นคนที่สามารถช่วยให้งานของพวกเขาง่ายขึ้น (โอ้วิดเจ็ตนั้นจะทำให้คุณทำสิ่งนี้ถ้าเราใช้เครื่องมือนี้แทน)

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

อย่างที่คนอื่นพูดทีมควรได้รับอนุญาตให้จัดระเบียบตนเองเพื่อกำหนดโครงสร้างใหม่ ประสบการณ์ที่ผ่านมาสอนให้ฉันการจัดระเบียบตัวเองสามารถทำงานได้จริง ๆ เมื่อทุกคนเกี่ยวข้องกับทีมมากกว่าที่จะมีวินัยหรือความสนใจของตัวเอง

ไชโย!

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

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

หลังจากนั้นแต่ละทีมสามารถแยกการประชุมการต่อสู้และผู้นำของทีมอื่น ๆ สามารถนำเสนอ วิธีนี้คุณจะลดจำนวนผู้ที่ "เบื่อ" แต่ยังคงทีมจะรู้ว่าคนอื่นกำลังทำงานอะไรและจะสามารถทำงานร่วมกันได้สำเร็จ

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

ลักษณะสำคัญของการต่อสู้คือการจัดระเบียบตัวเอง

ฉันขอแนะนำให้คุณอภิปรายคำถามกับทีมและให้พวกเขาแก้ปัญหา

ความกังวลของคุณนั้นได้รับการก่อตั้งมาอย่างดี แต่โปรดจำไว้ว่าในฐานะ Scrum Master งานของคุณคือการโค้ชและอำนวยความสะดวก ดังนั้นให้ถามพวกเขาว่าพวกเขาจะแก้ปัญหาเหล่านี้อย่างไร พวกเขาจะเป็นเจ้าของโซลูชั่นและทำให้มันใช้งานได้

ฉันจะเพิ่ม: โดยทั่วไปทีมข้ามสายงานเป็นวิธีที่จะไป

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

1. ส่วนหน้าไกลจากแบ็กเอนด์ไกลแค่ไหน? คาดว่าการแยกเป็นคำแนะนำที่ดีก็ต่อเมื่อระยะทางไกลเกินไป

   • หากแบ็กเอนด์พูดเกี่ยวกับคีมาฐานข้อมูลนี้เป็นไม่ไกลเกินไป ทั้ง front-end และ backend จำเป็นต้องฟังการสนทนาเกี่ยวกับ schema ของฐานข้อมูล

   • ถ้าแบ็กเอนด์พูดถึงการใช้เศษ, หน่วยความจำแคช, เวลาแฝงดิสก์, ฯลฯ นี่ก็ไกลไปหน่อย (ซึ่งแบ็กเอนด์มุ่งเน้นไปที่ความเห็นอกเห็นใจทางกลและการปรับให้เหมาะสมที่สุด

2. มีอินเตอร์เฟสการเขียนโปรแกรมที่เสถียรและไม่คลุมเครือระหว่าง front-end และ backend หรือไม่?

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

   • ทีมงานแบ็กเอนด์จำเป็นต้องจัดเตรียม API ที่ดีและการใช้งานจำลองในช่วงต้นและหลังจากนั้นก็เริ่มการพัฒนาที่แท้จริง

   • สิ่งนี้ไม่ได้บอกว่าควรตั้งค่า API ด้วยหิน นี่เป็นเพียงการลดผลของการแยกทีมออกเป็นสองทีม

3. ทำไมบทความว่องไวจำนวนมากจึงแนะนำให้มีชิ้นตามแนวตั้ง นี่คือข้อมูลพื้นหลังบางส่วน:

   • บทความเปรียวส่วนใหญ่แนะนำให้หลีกเลี่ยงงานแบ็กเอนด์จากมุมมองด้านต้นทุน

   • นอกจากนี้อย่าลืมว่าบางส่วนของบทความเปรียวมีอคติโดยนัยต่อ บริษัท เริ่มต้น

   • และอย่าลืมความจริงที่โหดร้ายของการตลาด - ลูกค้าส่วนใหญ่จ่ายเฉพาะส่วนหน้าเท่านั้น

   • งานแบ็กเอนด์มักจะมีค่าใช้จ่ายสูงและมีการจ่ายผลตอบแทนช้า หาก บริษัท ไม่ได้จัดตั้งขึ้นมาแล้วในระยะยาวและสร้างผลกำไรที่ดีกว่าจะเป็นการดีกว่าที่จะ "แบ็กเอนด์" ภายนอกด้วยการใช้เทคโนโลยีที่ล้าสมัยและห้องสมุดโอเพ่นซอร์ส

   • บทความที่ว่องไวส่วนใหญ่ยังแนะนำให้ใช้ส่วนหน้าเพื่อให้สามารถอยู่รอดได้ด้วยสวิตช์แบ็กเอนด์ คำแนะนำนี้ควบคู่ไปกับสิ่งที่ผ่านมา: หากเทคโนโลยีแบบนอกชั้นวางไม่เป็นไปตามข้อกำหนดทั้งหมดให้ลองทำแบบอื่น

4. วิธีปฏิบัติที่สามารถลดผลกระทบที่ไม่ดีจากการแบ่งทีม

   • back-end เสถียร
   • API ที่เสถียร
   • back-rate ที่มีข้อบกพร่องต่ำ
     • เหตุผล: เพื่อหลีกเลี่ยงความไม่พอใจ
     • วิธี: การทดสอบหน่วย
     • ไม่ได้หมายความว่า: ประสิทธิภาพหรือการเพิ่มประสิทธิภาพ; มันแค่ต้องถูกต้องตามหน้าที่
   • บูรณาการอย่างต่อเนื่อง
   • ความโปร่งใสในการสื่อสารความก้าวหน้าและการตัดสินใจ
   • สนับสนุนให้มีการพูดคุยอย่างไม่เป็นทางการในทั้งสองทีม
   • ส่งเสริมให้สมาชิกในทีม (ผู้ที่ไม่ได้แบ่งเขต) เพื่อเข้าร่วมการประชุมของทีมอื่น
   • ตั้งค่าการประชุมร่วมเป็นครั้งคราวและย้อนหลังร่วมกัน
   • กิจกรรมการสร้างทีมอื่น ๆ

เช่นเดียวกับคนอื่น ๆ ฉันขอแนะนำให้ไปกับชิ้นส่วนแนวตั้ง บางครั้งเรียกว่า "ฟีเจอร์ของทีม" ฉันขอแนะนำให้อ่านข้อดี / ข้อเสียที่ไซต์ Scaled Agile Framework: http://scaledagileframework.com/scaled-agile-framework/team/features-components/

ในตอนแรกเมื่อคุณแยกเจ้าของผลิตภัณฑ์และ SDF Master ของคุณอาจจัดการ Release Backlog สำหรับทั้งสองทีมรวมถึง backlogs ส่วนบุคคลสำหรับแต่ละฟีเจอร์ ในขณะที่คุณเติบโตคุณอาจต้องใช้งานคุณลักษณะของผลิตภัณฑ์ที่ค้างอยู่ซึ่งจะถูกป้อนเข้าสู่ทีมเปรียวหลายทีมที่ปล่อย backlogs เมื่อคุณขยายไปถึงระดับดังกล่าวคุณจะต้องมีทีมแยกต่างหากในการจัดการคุณลักษณะค้าง (Backlog) ของคุณสมบัติแล้วนำคุณลักษณะเหล่านั้นมาใช้กับแต่ละทีมเพื่อนำไปใช้งาน ในโครงสร้างนั้นคุณอาจมีสิ่งนี้:

1. Agile Team 1: SM, PO, ทีมข้ามสายงาน มีงานในมือของทีมสำหรับเรื่องราวของพวกเขา
2. Agile Team 2: SM, PO, ทีมข้ามสายงาน มีงานในมือของทีมสำหรับเรื่องราวของพวกเขา
3. ทีมผู้บริหารโครงการ:ผู้จัดการผลิตภัณฑ์, ผู้จัดการปล่อย, สถาปนิกองค์กร มีโปรแกรมในมือของตัวเองในระดับที่สูงขึ้นและคุณสมบัติที่จะจัดระเบียบวิเคราะห์และป้อนลงในทีม

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