อาจารย์ต่อสู้สามารถจัดสรรงานได้หรือไม่?


19

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


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

+1 มาร์ติน - แน่นอน มันเป็นกรอบ ไม่จำเป็นต้องเป็นคนดื้อรั้นหรือเจ้าระเบียบในแนวทางของคุณ
Agile Scout

4
@Scout: ScrumMaster ที่ทำหน้าที่เป็นผู้จัดการโครงการควบคุมและสั่งการไม่ใช่ Scrum หรือเปรียว
Martin Wickman

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

คำตอบ:


19

ตามที่Wikipedia บทความเกี่ยวกับการต่อสู้งาน Sprint ไม่ได้รับมอบหมายจาก ScrumMaster:

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

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

ScrumMaster ผู้รับผิดชอบกระบวนการการแย่งชิงกันทำให้แน่ใจว่ามีการใช้อย่างถูกต้องและเพิ่มประโยชน์สูงสุด

ScrumMaster ไม่ได้มอบหมายงานธรรมดาและเรียบง่าย ทีมมีการจัดระเบียบตนเองและการตัดสินใจว่าใครทำงานกับสิ่งที่ทีมตัดสินใจ

นี่คือการต่อสู้ที่แท้จริง แน่นอนว่าหลาย ๆ องค์กรอาจใช้รูปแบบนี้


ใช่. ลำดับความสำคัญ PO สมาชิกในทีมประเมินและเลือก เรียบง่ายและมีประสิทธิภาพ
Martin Wickman

8

นั่นคือวิธีที่มันควรจะทำงาน แต่เช่นเดียวกับทุกสิ่งที่ทำงานได้ดีในทางทฤษฎี ... มันไม่ได้ทำงานจริง

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

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

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

กล่าวอีกนัยหนึ่งไม่เพียงทำเพราะกระบวนการพูดว่า ทำงานอะไร สกรูที่เหลือ

แน่นอนว่ายังมีข้อเท็จจริงพื้นฐานอื่น ๆ เกี่ยวกับการมีอยู่ของมนุษย์ .... บางทีคุณอาจไม่รู้ด้วยซ้ำว่า Scrum Master คือใคร อาจไม่ใช่คนที่มีชื่อนั้น บางทีคุณอาจไม่มีแม้แต่


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

4

ไม่เคย

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

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

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


3

เช่นเดียวกับอุดมการณ์มีหลายครั้งที่ต้องทิ้งกฎกติกาหรือละเว้นอย่างระมัดระวัง

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

มีความแตกต่างใหญ่ระหว่างการจัดสรรงานตามคำสั่ง (คุณจะต้อง X) และการจัดสรรโดยการอภิปรายและข้อตกลง บางครั้งข้อตกลงอาจไม่อบอุ่น

จากนั้นอีกครั้งบางทีทีมต้องการผู้กำกับ ... มันยากที่จะรู้

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


การคิดเป็นเรื่องยากและฉันทำได้มากต่อวันเท่านั้น อาจปล่อยให้บางสิ่งบางอย่างหรือคนอื่นคิดเกี่ยวกับสิ่งเล็ก ๆ น้อย ๆ
Edward Strange

1
ในการต่อสู้คุณมอบหมายความรับผิดชอบนี้ให้กับทีม คุณไม่หยุดคิด ในความเป็นจริงคุณคิดโดยรวม ดังนั้นการตัดสินใจดีกว่า

2
ฉันผ่านกรณีที่ไม่มีใครในทีมจะดึงงาน แม้จะมีความพยายามซ้ำ ๆ เพื่อสนับสนุนความคิดริเริ่มที่จะเพิ่งคว้าการ์ดจากกระดานงานก็จะหยุดจนกว่าฉันจะดึงการ์ดและส่งมอบมัน ฉันคิดว่าเกิดจากความคิดการเปลี่ยนแปลง เมื่อวิศวกรคุ้นเคยกับการมอบหมายงานให้กับจานของพวกเขามันก็ยากที่จะหันหลังกลับ
smithco

2

ในความคิดของฉัน scummaster ไม่ควรทำอย่างนั้นสมาชิกในทีมควรรับงาน หาก scrummaster ทำการบริหารเท่านั้นตามกรณีในทีมของเราจะไม่มีปัญหา ต้นแบบการต่อสู้ของเราทำให้แน่ใจว่ากระดานต่อสู้กระดาษยังคงซิงค์กับไฟล์ excel บทบาทของอาจารย์ต่อสู้ควรเป็นผู้อำนวยความสะดวกที่เรา / เธอทำให้แน่ใจว่าคุณสามารถทำงานของคุณได้ไม่ จำกัด นี่คือวิธีที่เราทำงาน คุณรู้หรือไม่ว่าทำไม scrummaster ของคุณถึงทำสิ่งนี้ เขาเป็นผู้จัดการโครงการกลัวที่จะล้าสมัยหรือไม่? เขากลัวว่าทีมจะไม่ทำงานเองใช่ไหม? มันอาจเป็นความคิดที่ดีที่จะพูดคุยเรื่องนี้ระหว่างการหวนกลับ


1

ฉันเคยเป็นอาจารย์การต่อสู้ในสภาพแวดล้อมทั้งสองประเภท (ที่ฉันผลักงานให้กับบุคคลและที่บุคคลดึงงาน)

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

วิธีการดึงทำงานได้ดีในทีมที่สามารถรับงานใด ๆ โดยทรัพยากรใด ๆ แต่ฉันไม่สามารถวางแผนกำลังการผลิตส่วนบุคคลในระหว่างช่วงการวางแผนได้ แต่ฉันต้องพึ่งความเร็วเฉลี่ยเพื่อทราบว่าเพียงพอหรือไม่ (ใช้เวลาประมาณ 3-4 sprints ก่อนที่เราจะมีความคิดที่ดีเกี่ยวกับความเร็ว)

ฉันเจอบทความที่น่าสนใจโดยสรุปข้อดี / ข้อเสียของ Push vs. Pull

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