จะหยุด / หลีกเลี่ยงการต่อเวลากับทีมการต่อสู้ได้อย่างไร?

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

คำถามทางการของฉันคือ / คือ:

1. นอกเหนือจากการพูดคุยเกี่ยวกับการประชุมย้อนหลัง; คุณคิดว่าเป็นความคิดที่ดีที่จะใช้ฮาร์ดบล็อคเพื่อหลีกเลี่ยงช่วงเวลาหรือไม่?

2. ถ้าเป็นเช่นนั้นคุณแนะนำเทคนิคหรือเครื่องมืออะไร?

   • ระบบควบคุมการแก้ไข (SVN, GIT, HG, ฯลฯ ... ), บล็อกต่อชั่วโมง (8 ถึง 5)
   • บล็อกสถานีงานตามชั่วโมง (8 ถึง 5) หรือชั่วโมงสะสม (มากถึง 8 ชม. / วัน)?
   • อื่น ๆ (s) ...

3. หรือบางทีอย่าปิดกั้นสิ่งนี้ แต่ใช้"ระบบการลงโทษ"สำหรับชั่วโมงที่ไม่ยุติธรรมเพิ่มหรือไม่

@Baqueta (และคนอื่น ๆ ที่มีคำถามคล้ายกัน): ไม่มีการจ่ายเงินสำหรับชั่วโมงพิเศษ คำแนะนำแรกของฉันสำหรับพวกเขาคือการทบทวนการประเมินของพวกเขาเพราะบางทีพวกเขาดูถูกดูแคลน นี่คือคำแนะนำโปรดของฉัน:

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

นอกจากนี้ฉันคิดว่าปัญหาราก (สำหรับทีมนี้) เป็นการรวมกันของสิ่งต่อไปนี้:

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

สรุป:ฉันจะคุยกับทีมเพื่อตรวจสอบการประมาณของพวกเขาและกับ PO เพราะฉันรู้สึกว่าพวกเขาไม่ได้รับการปรึกษาหารือเกี่ยวกับขอบเขตดังที่คุณกล่าวไว้

ตรงไปตรงมาบรรดา "บล็อกยาก" ที่คุณพูดถึงใน # 2 เป็นความคิดที่แย่ที่สุดที่ฉันเคยได้ยินมานาน จะเกิดอะไรขึ้นหากพบข้อบกพร่องที่มีลำดับความสำคัญสูงสุดในเวลา 16.45 น. และคนที่มีความสามารถในการลบล้างบล็อกของคุณนั้นไม่สบาย สำหรับ # 3 - คุณกำลังบอกลงโทษคนทำงานของพวกเขา

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

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

หากมีงานมากเกินไปที่จะเข้าสู่การวิ่งนี่เป็นหนึ่งในสามเหตุผล:

1. นักพัฒนากำลังได้รับการบอกในสิ่งที่พวกเขาต้องประสบความสำเร็จในการวิ่ง / ไม่ได้รับคำปรึกษาเกี่ยวกับสิ่งที่ทำได้ / ถูกมองข้ามเมื่อพวกเขาบอกว่ามีงานมากเกินไป
2. นักพัฒนาประเมินอย่างต่อเนื่องว่าจะใช้เวลาเท่าใดในการทำงาน / จำนวนหน่วยงานที่เกี่ยวข้องในแต่ละงาน
3. นักพัฒนาซอฟต์แวร์ถูกดึงเข้าสู่ภารกิจที่ไม่ได้เป็นส่วนหนึ่งของการต่อสู้

ถ้ามัน # 1 คุณกำลังทำมันผิด ไม่มีสองวิธีเกี่ยวกับมัน!

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

ถ้ามันเป็นอันดับ 3 คุณต้องเริ่มแยกตัวประกอบในงานอื่น ๆ เหล่านั้น หากมันสอดคล้องกันก็ควรจะง่ายต่อการบัญชี (ดู # 2 ด้านบน) ถ้ามันบ่อย แต่คาดเดาไม่ได้ คุณต้องการดูว่าทำไมมันถึงเกิดขึ้น (เช่นข้อบกพร่องร้ายแรงใน 'live' code => มีการทดสอบของคุณอย่างละเอียดเพียงพอหรือไม่) แต่หากไม่สามารถแก้ไขได้ในที่สุดการทะเลาะกันอาจไม่ใช่วิธีที่เหมาะสม ทีมของฉันเปลี่ยนไปใช้ Kanban ด้วยเหตุผลนี้มาก ...

แก้ไข: อธิบายการวิจารณ์ของฉันเกี่ยวกับแนวคิดที่นำเสนอในคำถาม

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

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

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

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

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

ฉันคิดว่าปัญหาเป็นพื้นฐานมากขึ้น - ทีมมีแรงจูงใจ (หรือเชื่อว่าพวกเขามีแรงจูงใจ) ในการทำงานล่วงเวลา

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

เพียงบอกทีมไม่ให้ทำงานล่วงเวลา ระยะเวลา

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

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

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

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

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

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

แผนภูมิการไหลสะสมในอุดมคติควรมีลักษณะเช่นนี้หากทุกคนทำสองเรื่องต่อการทำซ้ำ:

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

เพื่อหลีกเลี่ยงการทำงานล่วงเวลาคุณต้องตัดขอบเขตของโครงการ

แผนภูมิต่อไปนี้แสดงตำแหน่งที่ความไม่แน่นอนอยู่ในโครงการ:

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

ฉันเดิมพันว่าไม่มีงานใดทำเสร็จแล้วเพราะพวกเขามีขนาดใหญ่เกินไปและไม่ได้ระบุและมีงานมากเกินไป

หากทีมของคุณสามารถจัดการตั๋ว 10 ใบใน 5 วันและพวกเขาได้รับตั๋ว 20 ใบลดจำนวนลงแล้วเตะมันให้เจ้าของผลิตภัณฑ์ / ผู้จัดการโครงการ / ผู้จัดการ / ลูกค้าและบอกให้พวกเขาจัดลำดับความสำคัญ

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

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

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

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

เหตุผลในการทำงานล่วงเวลาเป็นภาระงานอย่างแท้จริงหรือเป็นเหตุผลที่เกี่ยวข้องกับวัฒนธรรมหรือความคาดหวังมากกว่า

เหตุผลอาจเป็นภาระ

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

ความคาดหวังอาจจะ

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