เป็นผู้จัดการทีมและนักพัฒนาในทีมการต่อสู้

ฉันจัดการทีม 6 คนที่เพิ่งย้ายไปสกัม

เรามี Scrum Master (หนึ่งในนักพัฒนาในทีม) และเจ้าของผลิตภัณฑ์

เนื่องจากฉันมีเวลาว่างค่อนข้างมาก (เนื่องจากงานด้านการจัดการจำนวนมากที่ฉันเคยทำตอนนี้ทำโดย Scrum Master และเจ้าของผลิตภัณฑ์) และเนื่องจากฉันต้องการรักษาความสัมพันธ์ทางเทคนิคฉันจึงทำงานด้านเทคนิคบางอย่าง

ฉันทำหน้าที่เป็นส่วนหนึ่งของทีมพัฒนามุ่งมั่นกับเรื่องราวบางส่วนในแต่ละการวิ่งและมีส่วนร่วมในการประชุมทั้งหมดเป็นส่วนหนึ่งของทีม

คุณคิดว่าเป็นความคิดที่ดีหรือไม่? มันสามารถขัดแย้งกับ "องค์กรตนเอง" ของทีมได้หรือไม่?

อ่านความคิดที่พัฒนาของ Roy Osherove เกี่ยวกับความเป็นผู้นำของทีมในโลก Agile ที่5whys.com

เขาพูดมากเกี่ยวกับสามขั้นตอนสำคัญที่ทีมต้องทำในขณะที่วิวัฒนาการมาจาก Waterfall ถึง Scrum

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

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

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

เมื่อฉันได้พบกับความคิดของ Roy ที่OpenVolcano '10ฉันได้รับความเสียหายอย่างสมบูรณ์ว่าทำไมทีมของฉันถึงหยุดพัฒนา จากนั้นฉันก็ตระหนักว่าทีมได้ข้ามจาก Survival ไปเป็น Learning และฉันไม่ได้เปลี่ยนรูปแบบการจัดการเลย ฉันทำเช่นนั้นและมันช่วยได้มาก

ดังนั้นฉันขอแนะนำให้หาว่าสามขั้นตอนใดที่คุณอยู่และจัดการตามนั้น

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

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

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

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

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

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

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

ฉันเคยผ่านประสบการณ์ที่คล้ายกันมาก่อนนำทีมนักพัฒนา 6 คนในทีมการต่อสู้ นอกจากสิ่งที่ pdr และ GlenH7 พูดถึงแล้วสิ่งที่ช่วย:

1. ผู้ทดสอบที่ดีที่สุดในทีม QA นั้นเก่งในการทำให้เรารับผิดชอบต่อคุณภาพงานของเรารวมถึงงานที่ฉันทำ เมื่อฉันเขียนโค้ด buggy เธอเรียกฉันออกมาในลักษณะที่ยากสำหรับนักพัฒนารายอื่นที่จะทำ
2. ฉันมักจะทำการสาธิตโดยเฉพาะอย่างยิ่งเมื่อเรามีการวิ่งไม่ดี เนื่องจากฉันกำลังสาธิตให้ซีอีโอมันน่าอายเมื่อสิ่งที่ใช้งานไม่ได้ นอกเหนือจากการทำให้แน่ใจว่าฉันเข้าใจคุณสมบัติที่คนอื่นพัฒนาแล้วมันยังหมายถึงสิ่งที่ฉันต้องเป็นของแข็งเช่นเดียวกับคนอื่น
3. ฉันปล่อยให้คนอื่นตัดสินใจ ประสบการณ์ของฉันแตกต่างจากของ GlenH7 ฉันมักจะพบว่ามันเป็นความผิดพลาดในการดึงไพ่คนดี แต่ฉันได้พูดถึงผลที่ตามมาจากการตัดสินใจที่แตกต่างกันและทำให้ชัดเจนว่านักพัฒนาซอฟต์แวร์คนใดเคยทำงานในสิ่งที่ผลที่ตามมาคือสิ่งที่ฉันคิดว่าเป็นวิธีที่ "ผิด" ในการทำอะไรบางอย่าง มีเหตุผลมากมายในการทำสิ่งนี้ แต่สิ่งที่ยิ่งใหญ่ที่สุดคือในฐานะผู้นำทีมคุณไม่มีเวลาที่จะตัดสินใจทั้งหมด
4. การใช้ผลิตภัณฑ์อย่างSonarสามารถทำให้สิ่งต่าง ๆ เช่นคุณภาพของรหัสเป็นไปได้มากขึ้น