สถาปนิกสามารถทำงานกับทีม Scrum ที่จัดระเบียบตัวเองได้อย่างไร

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

ตัวอย่างเช่นทีมอาจต้องการใช้ไลบรารี X หรือต้องการใช้ REST แทน SOAP แต่ EA ไม่เห็นด้วย

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

คู่มือการแย่งชิงกันมีนี้จะพูดเกี่ยวกับมัน

การจัดระเบียบตนเอง: ไม่มีใคร (ไม่ใช่แม้แต่ Scrum Master) บอกทีมพัฒนาถึงวิธีเปลี่ยน Backlog ผลิตภัณฑ์ให้เป็นหน้าที่การทำงานที่เพิ่มขึ้นได้

นั่นสมเหตุสมผลหรือไม่ ทีม EA ควรถูกยกเลิกหรือไม่ ทีมควรปฏิเสธหรือปฏิบัติตามเพียง?

ทีมพัฒนาประกอบด้วยบุคคล 3-9 คนที่มีทักษะการทำงานข้ามสายงานซึ่งทำงานจริง

Scrum Master ควรเชิญ "Enterprise Architect" เป็นส่วนหนึ่งของทีมงานโครงการ จากนั้นการสื่อสารระหว่างสถาปนิกและโปรแกรมเมอร์จะยอดเยี่ยม

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

สถาปนิกพูดเพื่อระบบและ codebase เพราะระบบและ codebase ไม่สามารถพูดได้ด้วยตนเอง การมีสถาปนิกโดยทั่วไปแล้วจะเป็นผลประโยชน์ที่ดีที่สุดในระยะยาวของ บริษัท โดยเฉพาะอย่างยิ่งสิ่งที่ต้องอาศัยซอฟต์แวร์ที่สร้างขึ้นเอง

สถาปนิกไม่ได้บอกนักพัฒนาถึงวิธีเปลี่ยนงานค้างเป็นทีละน้อย (sprints) พวกเขากำลังบอกว่าเทคโนโลยีใดที่สามารถและไม่สามารถใช้ได้ คุณกำลังพูดถึงสองประเด็นที่แตกต่างกัน

ทางออกคือไม่มีอะไรเปลี่ยนแปลง หากทีมของคุณรู้สึกท้อแท้เพราะสถาปนิกมีข้อ จำกัด หรือเกินกำลังเกินไปนั่นเป็นปัญหาของบุคลากรที่ไม่มีส่วนเกี่ยวข้องกับ SCRUM และควรได้รับการจัดการกับผู้มีส่วนได้เสียทางธุรกิจในเรื่องของความพึงพอใจของพนักงานและถ้าเป็นไปได้ ("เราใช้เวลาx%ในการพัฒนาคุณลักษณะนานขึ้นyเนื่องจากสถาปนิกzไม่ให้เราใช้ Turbo Pascal")

สิ่งนี้จำเป็นต้องรักษาสมดุลระหว่างความต้องการทีมใหญ่เพื่อให้โครงการสำเร็จลุล่วงและความต้องการให้ทีมเล็กคล่องตัว

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

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

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

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

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

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

กลุ่มที่Scaled Agile Frameworkพูดถึงสิ่งนี้ได้ดีจริงๆ พวกเราส่วนใหญ่จัดการที่ระดับทีม แต่เมื่อไต่ขึ้นเราต้องตระหนักว่ามีบทบาทที่จะเล่นในระดับโปรแกรมและผลงานเช่นกัน การตัดสินใจทางสถาปัตยกรรมจะต้องมีการดำเนินการทั่วทั้งองค์กรและสิ่งที่ควรป้อนเข้าไปในสิ่งที่เกิดขึ้นในระดับล่างขององค์กร ไม่มีอะไรผิดปกติกับการตัดสินใจทางสถาปัตยกรรม!

ที่เกี่ยวข้องกับเรื่องนี้หนังสือเล่มล่าสุดของ Dean Leffingwell เกี่ยวกับความต้องการซอฟต์แวร์ Agileเป็นการอ่านที่ดีในหัวข้อนี้ฉันได้อ่านด้วยตัวเองแล้ว

นอกจากนี้เรายังมีทีมที่คล่องแคล่วว่องไว (บางคนมี Kanban, Scrum บางคน) และสถาปนิก สถาปนิกมีหน้าที่รับผิดชอบโครงสร้างพื้นฐานที่ครอบคลุมผลิตภัณฑ์ทั้งหมดของเรา (ห้องสมุดผู้ช่วยการพิสูจน์ตัวตนการสร้างโครงสร้างพื้นฐาน) ฯลฯ พวกเขาตัดสินใจทางเทคนิค แต่ยังใช้สิ่งต่าง ๆ ซึ่งส่วนใหญ่เป็นส่วนประกอบโครงสร้างพื้นฐาน

วิธีนี้ใช้ได้ดีและมักจะไม่มีข้อขัดแย้ง ฉันเชื่อว่าจุดสำคัญอย่างหนึ่งคือ:

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

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

ฉันไม่เห็นความขัดแย้งใด ๆ ที่นี่ จากสิ่งที่ฉันเข้าใจ EA ทั้งหมด (ตามชื่อที่ฉันคิดว่าเป็นแบบนั้น) มีเจตนาที่จะทำคือ QA ทุกคนควรตระหนักถึงสิ่งนั้น

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

ข้อกำหนดเหล่านี้บางอย่างถูกกำหนดโดยนโยบายของ บริษัท และตั้งกฎพื้นฐาน:

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

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

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

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

มาร์ตินฉันคิดว่าคุณอาจเข้าใจผิดว่าทีมจัดระเบียบตัวเองทำงานอย่างไรในสภาพแวดล้อมของมัน

คุณยกคำแนะนำการแย่งชิงกัน: "ไม่มีใคร (ไม่ใช่แม้แต่อาจารย์การแย่งชิง) บอกทีมพัฒนาถึงวิธีการเปลี่ยนผลิตภัณฑ์ที่ค้างไว้ให้เป็นการเพิ่มความสามารถในการทำงานที่สามารถกู้คืนได้"

นี่ไม่ใช่ใบอนุญาตสำหรับทีม Scrum ที่จะทำสิ่งที่ต้องการ (ตราบเท่าที่มีให้) โดยไม่คำนึงถึงความต้องการด้านเทคโนโลยีและธุรกิจของ บริษัท โดยรวมและความต้องการของทีมอื่น ๆ

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

Waterfall หรือ Scrum (ดูเหมือนว่าการผสมสองอย่างซึ่งใช่จะไม่ไปทำงาน) ซึ่งฟังดูเหมือนชั้นที่ไม่มีจุดหมายในการจัดการสำหรับฉันตั้งแต่แรก Gatekeepers เกี่ยวกับการตัดสินใจทางเทคโนโลยีควรเป็นผู้นำของ devs ผู้จัดการโดยรวมของการพัฒนาที่มีหน้าที่ในการป้องกันการตั้งค่า dev จากการเปลี่ยนแอปของคุณให้กลายเป็นทางเลือกด้านเทคโนโลยีที่หลากหลายและงบประมาณของใครก็ตาม

ไม่มีอะไรที่จะทำให้ฉันประหลาดใจอย่างต่อเนื่องเหมือนผู้ที่ไม่ได้เป็น devs จริง ๆ มี gall ในการตัดสินใจทางเทคโนโลยีโดยไม่ต้องแม้แต่การปรึกษากับคนจริงที่ต้องประสบผลของการตัดสินใจเหล่านั้น