Agile รุ่นของเราไม่ทำงาน เคล็ดลับ?


12

ฉันทำงานกับทีมนักพัฒนา 4 คน เรากำลังใช้งานเวอร์ชันของ Agile ที่ดูเหมือนจะให้ปัญหาเราอย่างต่อเนื่องทุกสัปดาห์และฉันกำลังมองหาคำแนะนำที่สามารถช่วยเราปรับปรุงกระบวนการของเรา

พื้นหลัง:

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

เราเริ่มต้นการวิ่งแต่ละครั้งโดยมอบหมายเรื่องราวที่ผู้จัดการของเราสร้างให้กับเรา บางครั้งเขาก็โยนงานด้วยและเราประเมินพวกเขา เราไม่ใช้คะแนนเนื้อเรื่อง เราใช้ซอฟต์แวร์ Urban Turtle เพื่อ "จัดการ sprints ของเรา" ซึ่งโดยพื้นฐานแล้วเป็นเพียงเรื่องราวและภาระงานและสิ่งที่เกี่ยวข้องก็ลดลง เราไม่ได้วางแผนที่จะปล่อยในตอนท้ายของการวิ่ง

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

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

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

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


8
ไม่จัดสรรเวลา 100% ให้กับเรื่องราวและงานบางทีเพียง 80% ของเวลา? และถ้าคุณทำทุกอย่างเสร็จ (ฟังดูไม่น่าจะ) นำเรื่องอื่นมาจากงานในมือ? หรือสร้างตัวคูณสำหรับการประมาณของคุณ (your_number * 2)?
เควิน

1
ขอบคุณฉันคิดว่าตัวทวีคูณเป็นความคิดที่ดีพร้อมกับกำหนดขอบเขตให้น้อยลง

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

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

1
คุณเลือกเรื่องราวที่ต้องทำในการวิ่งอย่างไร
jk

คำตอบ:


20

เพราะเราอยู่นอกกำหนด

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

หลังจากนี้มันไม่สำคัญว่าคุณประเมินค่าต่ำไปเรื่อย ๆ - ความเร็วของคุณมีอยู่แล้ว

เห็นได้ชัดว่านี่เป็นไปไม่ได้ถ้าคุณใช้เวลาหลายชั่วโมงแทนคะแนน


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

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

4
@DavidWallace แน่นอนว่ามันจะไม่สร้างประมาณการที่แม่นยำต่องานแต่เป้าหมายคือการประมาณการที่แม่นยำยิ่งขึ้นสำหรับการวิ่งทั้งหมด ที่ทฤษฎีก็คือความหลากหลายของงานโดยงานได้รับการเฉลี่ยมากกว่า 3 ซ้ำ + ที่ความเร็วจะถูกคำนวณ
Chris Pitman

12

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

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

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

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


+1 สำหรับการตรวจสอบปัญหาที่ยากและเลื่อนการใช้งานไปยังการวิ่งครั้งต่อไป โปรดทราบว่าสิ่งนี้เรียกกันโดยทั่วไปว่า "วิธีแก้ปัญหาชั่วคราว" (หรือ "แก้ปัญหาชั่วคราว"); extremeprogramming.org/rules/spike.html
sleske

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

6

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

ประการที่สองคูณที่ 6 ชั่วโมง / วันโดย80% ทำไม? เพราะในฐานะมนุษย์เราดูดดื่มว่าจะใช้เวลาเท่าไร บัญชีนี้มีข้อผิดพลาดในการตัดสินของเรา อีกครั้งไม่ใช่กระสอบทรายมันเป็นจริง

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

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

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


5

เกณฑ์การยอมรับที่กำหนดไว้ไม่ดีเมื่อเริ่มวิ่ง

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

เรื่องใหญ่เกินไป

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

ไม่สามารถประมาณได้เนื่องจากคุณไม่มีข้อมูลเพียงพอ

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

ล้มเหลวเร็วขึ้น

และฉันเห็นด้วยกับ @Patrick Hughes - ลองย้ายไปใช้ระยะเวลา 1 สัปดาห์เพื่อให้คุณเห็นปัญหาได้เร็วขึ้น


3

นอกจากคำแนะนำที่ดีโดย @Kevin และ @Patrick ...

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

เรากำลังใช้งานเวอร์ชันของ Agile ที่ดูเหมือนจะให้ปัญหากับเราอย่างต่อเนื่อง

คุณควรเริ่มต้นด้วยวิธีการ "ตามหนังสือ" (การแย่งชิงกันในทุกวันนี้ดูเหมือน) - และทำในสิ่งที่ทีมประสบความสำเร็จคนอื่นทำ ... ทำอย่างนั้นสักสองสามครั้ง ... และจากนั้นก็เริ่มพิจารณา การเปลี่ยนแปลงที่จำเป็นในการปรับให้เหมาะสมสำหรับสภาพท้องถิ่น

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


3

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

ปัจจัยโฟกัส * ที่มนุษย์ใช้งานได้ = ความเร็วโดยประมาณ

ความเร็วโดยประมาณคือผลรวมของค่าประมาณของเรื่องราวที่คุณวางแผนที่จะนำไปใช้ในช่วง Sprint ถัดไป

และหลังจาก Sprint หนึ่งเครื่องคุณคำนวณปัจจัยการโฟกัสของ Sprint ในระยะเวลาดังนี้

ปัจจัยการโฟกัส = ความเร็วจริง / วันมนุษย์ที่มีอยู่

ที่ความเร็วจริงคือผลรวมของการประมาณของเรื่องราวที่คุณนำไปใช้ในการวิ่ง

จากนั้นคุณนำปัจจัยการโฟกัสที่แท้จริงนี้ไปใช้กับ Sprint ถัดไปและหลังจาก Sprint สองสามครั้งคุณจะสามารถแม่นยำยิ่งขึ้นด้วยจำนวนที่คุณสามารถทำได้จริง ๆ ในระหว่าง Sprint ...


+1 สำหรับการพูดถึงการต่อสู้จากสนามเพลาะ คำถามและคำตอบทำให้ฉันคิดถึงหนังสือเล่มนั้น
Buttons840

1

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

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

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

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

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

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