การวิ่งแบบแย่งชิงกันหมายถึงการทำงานด้วยความเร็วที่เร็วที่สุด

เมื่อเร็ว ๆ นี้ฉันสัมภาษณ์กับ บริษัท ที่ทำ Agile, Scrum เพื่อความแม่นยำมากขึ้นและมีบางสิ่งที่ไม่เหมือน Agile สำหรับฉัน ฉันจะใช้กรณีหนึ่งที่ฉันสนใจเป็นพิเศษตอนนี้ที่การต่อสู้ของสrum

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

ตอนนี้ฉันยังไม่ได้ทำ Agile ในตอนนี้ (ทำงานกับสถาบันการเงินและหน่วยงานของรัฐซึ่งส่วนใหญ่ยังคงชอบน้ำตก) แต่ความเข้าใจของฉันคือ:

• sprint in Scrum เป็นชื่อสำหรับการทำซ้ำทั่วไปใน Agile;
• ทีมควรทำงานอย่างยั่งยืนและพยายามหลีกเลี่ยงการทำงานล่วงเวลาในระยะยาวเนื่องจากมีผลกระทบเฉพาะในช่วงเวลาสั้น ๆ และผลกระทบจะถูกแคระโดยปัญหาที่เกิดขึ้นในระยะยาว

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

คุณไม่ต้องค้นหาไกลเพื่อดูว่าการปฏิบัติเหล่านี้ขัดกับหลักการที่อยู่เบื้องหลังความคล่องตัว หนึ่งในหลักการเบื้องหลังการประกาศความคล่องตัว:

กระบวนการที่คล่องตัวส่งเสริมการพัฒนาที่ยั่งยืน ผู้สนับสนุนนักพัฒนาและผู้ใช้ควรจะสามารถรักษาอัตราการคงที่อย่างต่อเนื่อง

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

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

หากต้องการตอบคำถามของคุณโดยตรง:

• ใช่ Sprint เป็นชื่อของการวนซ้ำใน Scrum ดูคำตอบนี้สำหรับความแตกต่าง
• ใช่ทีมควรทำงานอย่างยั่งยืน ความแน่นอนของการทำงานล่วงเวลาเพียงอย่างเดียวคือมันจะลดประสิทธิภาพการทำงานของทีมในระยะยาว
• ใช่มันเป็นธงสีแดง!

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

มีสิ่งสำคัญอย่างหนึ่งที่อาจทำให้สิ่งนี้ยอมรับได้: ทีมยอมรับขอบเขตของการวิ่ง

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

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

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

การต่อสู้แบ่งออกเป็น sprints ที่คุณประเมินชุดของงานที่ต้องทำให้เสร็จในช่วงระยะเวลาของการวิ่งนั้น (โดยทั่วไปแล้ว 2 สัปดาห์ แต่ฉันได้เห็นทุกที่ตั้งแต่ 1 วันถึง 4 สัปดาห์) ฉันคิดว่าสิ่งนี้สร้างแรงจูงใจในการทำงานที่ไม่เหมาะสม ใบสั่งซื้อ (เจ้าของผลิตภัณฑ์) ต้องการให้การประมาณการต่ำเพื่อรับภาระผูกพันจำนวนมากต่อการวิ่ง ทีมจะนำการประมาณการขนาดใหญ่มาจัดทำแผนภูมิการเผาไหม้ที่ดีเพื่อให้ PMs เห็น แน่นอนเหล่านี้บ่งบอกถึงองค์กรที่เส็งเคร็ง คุณต้องการได้รับการประมาณการที่ถูกต้องและไม่ต้องกลัวที่จะขาดช่วงสั้น ๆ และเล่าเรื่องราวต่อไปในการวิ่งครั้งต่อไปหรือเสร็จเร็วกว่าเดิมและดึงงานพิเศษออกจากงานในมือ ฉันคิดว่าคำว่า "วิ่ง" สร้างภาพลักษณ์ของคนที่ทำงานเร็วขึ้น

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

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

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

tl; dr: Pace ที่ยั่งยืน การต่อสู้เป็นเรื่องเกี่ยวกับจังหวะบางสิ่งบางอย่างที่ทีมสามารถติดตามได้อย่างไม่มีกำหนด การทำงานล่วงเวลาไม่ได้ ทีมจะทำงานหนักเกินไปงานจะกลายเป็นเลอะเทอะสมาชิกจะโทรมาด้วยอาการป่วยหรือลาออกทั้งหมดและจากนั้นคุณมีปัญหาใหญ่กว่าการวิ่งที่ล้มเหลว

กระบวนการที่คล่องตัวส่งเสริมการพัฒนาที่ยั่งยืน ผู้สนับสนุนนักพัฒนาและผู้ใช้ควรจะสามารถรักษาอัตราการคงที่อย่างต่อเนื่อง

จากกลุ่มคนเปรียว

การทำงานล่วงเวลาตลอดเวลาไม่ได้ทำให้ฉันยั่งยืน

ที่กล่าวว่าฉันไม่เห็นปัญหาใด ๆ กับความมุ่งมั่นของฤดูใบไม้ผลิที่จะเป็นคนเข้มแข็ง (ถ้านั่นคือวิธีที่ทีมต้องการทำงาน) และต้องทำงานล่วงเวลาเมื่อคุณบอกเลิกมากเกินไปหรือประเมินค่าสกรูเป็นแรงจูงใจที่ดี ความคาดหวังของ PO

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

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

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

ฉันเดาคุณรู้คำตอบ ... ;-)