ความเหนื่อยหน่ายอาจเกิดขึ้นได้เมื่อทำ Scrum sprints อย่างต่อเนื่อง? [ปิด]


93

ฉันมีการเริ่มต้นที่ค่อนข้างเล็กและเราเริ่มใช้รูปแบบของวงจรการพัฒนา Scrum / Agile

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

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

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


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

12
หากสิ่งนี้ไม่สร้างสรรค์จะอยู่ที่ไหนในระบบนิเวศของ Stackexchange ที่ดีที่สุด?
Ryan Schultz

2
บางทีprogrammers.stackexchange.com ... ไม่แน่ใจ
Kevin Krumwiede

22
คำถามกับ 53 upvotes ตอบรับ 49. ปิดว่าไม่สร้างสรรค์ เห็นได้ชัดว่า "ผู้ดูแล" ที่เห็นแก่ตัวบางคนเลิกใช้ยาของตนแล้ว อีกครั้ง.
SzG

เห็นด้วยคำถามอยู่รอบ ๆ ข้อกำหนดสำหรับการวางแผนกำลังการผลิตและคำตอบที่เลือกก็เช่นกัน
charo

คำตอบ:


68

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

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

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

Henrik Kniberg พูดถึงสิ่งนี้:

ปัจจัยโฟกัส "เริ่มต้น" ที่ฉันใช้สำหรับทีมใหม่มักจะอยู่ที่ 70% เนื่องจากนั่นคือจุดที่ทีมอื่น ๆ ของเราส่วนใหญ่จบลงเมื่อเวลาผ่านไป

http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf

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

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

3
Kniberg พูดกับตัวเองว่า: "focus factor เป็นสิ่งหนึ่งที่ฉันอยากจะตัดออกจากหนังสือหยุดใช้ทันทีหลังจากเขียนหนังสือ ... " - twitter.com/henrikkniberg/status/207853426967715841
MPV

24

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

พวกเขาอาจมีภาพไอคอนของ Scrum ถัดจากคำจำกัดความของความเหนื่อยหน่าย

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

IMHO ควรห้าม Scrum สั้น ๆ 2 สัปดาห์ยกเว้นในขนาดเล็กไม่เกิน 4-8 ติดต่อกัน ใช้เป็นเครื่องมือสำหรับสิ่งพิเศษหรือวิกฤตไม่ใช่ทำอย่างต่อเนื่อง ใช้สามัญสำนึก.


3
นี่เป็น FUD ที่ไร้สาระการต่อสู้ไม่ได้เกี่ยวกับการที่ผู้คนถูกไฟไหม้การวิ่งระยะสั้นไม่เกี่ยวกับการทำงาน 80 ต่อสัปดาห์
Pascal Thivent

7
นี่อยู่ตรงเครื่องหมาย เป็นเรื่องตลกที่คนรักการต่อสู้ปกป้องมันด้วยเทพนิยายว่ามัน 'ควร' จะทำอย่างไร แต่นักพัฒนาส่วนใหญ่สัมผัสกับสิ่งที่ OP พูดถึง
kirk.burleson

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

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

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

14

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


11

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

สิ่งนี้ช่วยให้ฉันไม่รู้สึกเหนื่อยหน่าย


10

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


10

Sprint ไม่ใช่เส้นประ 100 หลา มันเป็นหนึ่ง (สุ่ม) ไมล์ในการวิ่งมาราธอนนั่นคือก้าวที่คุณสามารถรักษาได้อย่างไม่มีกำหนด

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

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

สำหรับ "... เวลาในสภาพแวดล้อมการต่อสู้ที่ไม่ได้มอบหมาย / ไม่ถูกติดตามเพื่อทำสิ่งเล็กน้อยและเคลียร์หัวของคุณ" ให้รักษาความมุ่งมั่นของทีมไว้ที่ x% ของความสามารถที่มีอยู่ (คะแนนควรใช้ แต่ชั่วโมงสามารถใช้ได้ หากจำเป็นไม่ว่าในกรณีใดฉันพบบางสิ่งในช่วง 60-70% ดูเหมือนว่าเป็นบรรทัดฐาน) เป็นกุญแจสำคัญในการพัฒนาอย่างยั่งยืนภายใน Sprint และ 'วันรหัสฟรี' เป็นครั้งคราวใช้ได้ดีกับ Sprints ภายนอก


21
บางทีพวกเขาไม่ควรเรียกมันว่า Sprint ใช่มั้ย? ควรเรียกมันว่าตัก
Alex Baranosky

4
ฉันเชื่อว่าพวกเขาเรียกมันว่า Sprint เพื่อป้องกันไม่ให้คนนอกทีมแทรกแซง Sprint ดูเหมือนเป็นสิ่งที่คุณไม่ควรขัดจังหวะ
Paul Tevis

รอบหมายถึงไม่มีเป้าหมายมันเป็นเพียงหนึ่งในอีกหลาย ๆ ครั้งการวิ่งจะกำหนด 'วิ่งไปสู่เป้าหมาย' ซึ่งsprintท้ายที่สุดก็คือ คำศัพท์เป็นเสียง IMHO
Jakub

2
เพียงแค่ใช้ "การวนซ้ำ" สำหรับพวกเราส่วนใหญ่คำนี้มีความหมายเหมือนกันอยู่แล้ว แต่การ "วนซ้ำ" ขาดความหมายแฝงทั้งหมด "วิ่งจนกว่าคุณจะหมดแรง"
mindcrime

8

ทางออกหนึ่งคือการลดจำนวนชั่วโมงในวันที่ใช้ไปกับการวิ่ง

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

นั่นอาจดูรุนแรงไปหน่อย แต่ถ้าฉันจำไม่ผิดมันเป็น บริษัท ที่ทำกำไรได้จนกระทั่งเกิดการช็อกทางเศรษฐกิจอย่างกว้างขวางเมื่อเร็ว ๆ นี้


1
ฉันคิดว่าตอนนี้เรากำหนดไว้ที่ 6 ชั่วโมงของการวิ่งต่อวัน บางทีนั่นอาจจะเกินไปหน่อย
mmcdole

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

ทีมของฉันวางแผนโดยใช้เวลาทำงาน 5 ชั่วโมงต่อวัน และ TBH ฉันคิดว่า 4.5 ชั่วโมงน่าจะเหมาะกับเรามากกว่า ดังนั้นฉันคิดว่า 6 ชั่วโมงการผลิตต่อวันเป็นจำนวนมาก
John Rayner

6

คุณอยู่ในระยะที่ 18 ของคุณ!?

เมื่อพิจารณา 2 สัปดาห์ต่อการวิ่งนั่นหมายความว่า 36 สัปดาห์ไม่หยุดทำงานในโครงการเดียวกัน คุณยังแสดงความคิดเห็นว่าทำงานประมาณ 6 ชั่วโมงในแต่ละวัน เสียงเหมือนมาก!

ฉันไม่รู้เกี่ยวกับวิธีการแบบ Agile (แม้ว่าเราจะใช้ Scrum ในโครงการปัจจุบันของเรา) แต่มีหลักการเกี่ยวกับชั่วโมงการทำงานของคุณ (ฉันหมายถึงระยะเวลาที่คุณใช้ในการทำงาน) ควรเป็น 60% ~ 70% ตอนนี้ทำตัวเลขอีกครั้งถ้าวันแรงงานของคุณยาว 8 ชั่วโมงและคุณใช้เวลาทำงาน 6 ชั่วโมงคุณจะใช้เวลาทำงานประมาณ 75% นี่อาจเป็นการเบี่ยงเบนเล็กน้อยที่ทำให้คุณมีความรู้สึกนั้นในที่สุด

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

Agile ไม่ใช่หินที่มีการแกะสลัก: "ทำงานได้เร็วขึ้น / แข็งแรงขึ้น / ดีขึ้น / ยากขึ้น" เหมือนท้องฟ้าสีครามที่มีเมฆสีขาวที่อ่านว่า "ทำงานได้ดีสวยงามมีประสิทธิผลมากขึ้น" (ฮ่า ๆ เล็กน้อยในตอนท้ายได้รับความอนุเคราะห์จาก daft punk + radiohead)


6

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

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

นอกจากนี้หากคุณบอกว่าวิธีการและการวิ่งแบบว่องไวเหล่านี้ไม่ได้มีประสิทธิภาพ / ประสิทธิผลมากขึ้นทำไมคุณถึงใช้มันเลย? ทำไมคุณถึงคิดว่า บริษัท ต่างๆต้องการใช้วิธีการเหล่านี้เลย? ไม่ใช่เพราะพวกเขาสนุก ....

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

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

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

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

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


2

การก้าวอย่างยั่งยืนเป็นหลักการสำคัญของความคล่องตัว เมื่อทำแนวปฏิบัติด้านการจัดการ (SCRUM) ควบคู่ไปกับแนวปฏิบัติด้านวิศวกรรม (XP) ทีมสามารถส่งสปรินต์หลังจากวิ่งไปเรื่อย ๆ อย่างไรก็ตามเนื่องจากหนึ่งไม่สามารถหมายความว่าควร

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

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


3
บางทีพวกเขาไม่ควรเรียกมันว่า Sprint ใช่มั้ย? ควรเรียกมันว่าตัก
Alex Baranosky

2

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

ฉันเดาว่านั่นคือสิ่งที่เกิดขึ้นกับทีมของคุณ ฉันแนะนำให้อ่านโพสต์เกี่ยวกับ IMHO ของ Highsmith นี้: Velocity is Killing Agility!

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