เราจะลดเวลาหยุดทำงานเมื่อสิ้นสุดการทำซ้ำได้อย่างไร


56

ฉันทำงานที่ไหนเราฝึกฝนความคล่องแคล่วว่องไวด้วยการทำซ้ำ 3 สัปดาห์ ใช่มันคงจะดีถ้าการทำซ้ำสั้นลง แต่การเปลี่ยนแปลงนั้นไม่ใช่ตัวเลือกในขณะนี้

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

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


3
ฉันลงคะแนนเพื่อเริ่มต้น นั่นคือสิ่งที่เราทำ
งาน

14
ฉันโหวตให้กลับบ้านเร็ว นั่นคือสิ่งที่ฉันจะทำ
kirk.burleson

@ Kirk 11 โมงเช้าอาจจะเร็วไปหน่อย ;)
Adam Lear

หากการหวนกลับใช้เวลาเพียง 1 (ชั่วโมง ((11.00 น. - 8.00 น.) / การประชุม 2 ครั้ง) บางทีคุณน่าจะสนุกกว่านี้ :)
bzlm

คำตอบ:


68

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

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

ตัวอย่าง:

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

อะไรก็ตามที่เป็นแรงบันดาลใจให้โปรแกรมเมอร์ทำให้พวกเขามีแรงจูงใจในการส่งมอบงานตรงเวลา


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

1
สำหรับสิ่งที่น่าสนใจในสิ่งที่คล้ายกับตัวอย่างของคุณมากวัน fedex ( blogs.atlassian.com/rebelutionary/archives/000495.html ) เป็นแนวคิดที่น่าสนใจมาก สร้างทุกสิ่งที่คุณต้องการ แต่ส่งมอบใน 24 ชั่วโมง
Steven Evers

การเรียนรู้สิ่งใหม่ ๆ สามารถเพิ่มขวัญกำลังใจได้อย่างมาก ตรวจสอบให้แน่ใจว่าอยู่ในขอบเขตที่ค่อนข้างเกี่ยวข้องกับธุรกิจของ บริษัท
Rudolf Olah

22

หยุดวัน คุณทำงานที่คุณควรจะทำดังนั้นทำไมคุณยังทำงานอยู่

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


8
เพราะเชื่อฉันเมื่อ sprints ต้องการให้คุณทำงานช้า - คุณจะทำงานช้า :)
Spedge

14

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


7

แม้ว่าเรื่องราวของผู้ใช้ของเราจะเสร็จสิ้นเกือบตลอดเวลาเมื่อสิ้นสุดการทำซ้ำเรามักจะมีรายการ "nice-to-haves" ที่ยาวที่สุดในตอนท้ายพร้อมด้วยรายการข้อผิดพลาดที่รู้จัก ดังนั้นเมื่อผู้คนจบเรื่องราวของพวกเขามักจะมีกิจกรรมให้ทำมากมาย

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

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

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


5

การทำซ้ำของเราเสร็จสิ้นในวันพฤหัสบดีเพื่อแก้ไขปัญหาในนาทีสุดท้ายของวันศุกร์ แต่วันศุกร์เหล่านั้น (หนึ่งทุก 2 สัปดาห์) ตรงกับวันศุกร์เบียร์ของเราดังนั้นเราจึงพยายามที่จะทำมันอย่างสงบ แก้ไขข้อบกพร่องเล็ก ๆ น้อย ๆ ใช้เวลาอ่านสิ่งต่าง ๆ (หนังสือ StackExchange บล็อก ฯลฯ ) และผ่อนคลายด้วยเบียร์ในตอนท้ายของวัน มิฉะนั้นคุณจะไม่รู้สึกถึงความสมบูรณ์หรือการปิดและแทนที่จะรู้สึกเหมือนหนูแฮมสเตอร์กำลังหมุนอยู่ในวงล้อไม่หยุด


5

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

Ken Schwaber ระบุในบล็อกของเขาที่http://kenschwaber.wordpress.com/2010/06/10/waterfall-leankanban-and-scrum-2/

"พระเจ้าช่วยเราผู้คนค้นพบหนทางที่จะหย่อนในน้ำตกเพื่อพักผ่อนและมีความคิดสร้างสรรค์กับ Lean และ Kanban สถานที่หลบซ่อนเหล่านั้นจะถูกลบออกตอนนี้เรามีความก้าวหน้าในเดือนมีนาคม


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

3

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

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


ดี - สิ่งที่คุณเรียกพวกเขาว่ามันควรจะชัดเจนว่านี่เป็นงานพิเศษ ไม่มีอะไรเลวร้ายไปกว่าการมีป้ายกำกับการวิ่งที่ล้มเหลวเนื่องจากงานที่สัญญาไว้ไม่เสร็จสิ้น
Robbie Dee

2

นักพัฒนาทั้งหมดในทีมของฉันใช้เวลาว่างในตอนท้ายของการวิ่ง (โดยมีภารกิจการวิ่งทั้งหมดเสร็จสิ้น) เป็น 'เวลาของ Google'

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


2

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

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

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


1

นี่คือหนึ่งในเหตุผลที่เราเปลี่ยนมาใช้ Kanban ผลประโยชน์ทั้งหมดของการต่อสู้โดยไม่ต้องแยกออกจากโครงการ


0

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

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


0

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

ตอนนี้แทนที่จะมีการย้อนหลังนักพัฒนาซอฟต์แวร์แต่ละคู่เลือกรายการที่โดดเด่นจาก Backlog ย้อนหลังที่มีอยู่และทำงานกับมัน

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

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


ใช้เวลานานแค่ไหนที่คุณจะทิ้งปัญหาย้อนหลังทั่วไป (เรื่องราวไม่ดีการประมาณค่า) คุณไม่เคยหวนกลับย้ายการอภิปรายทั้งหมดไปสู่การอภิปรายเล็ก ๆ ตลอดทั้งการวิ่งหรือไม่?
ประจบประแจง

-1

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

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