ข้อผิดพลาดของเวิร์กโฟลว์ในทีม agile / Scrum ของคุณคืออะไร?

ข้อผิดพลาดของเวิร์กโฟลว์ในทีม agile / Scrum ของคุณคืออะไร?

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

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

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

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

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

ฉันคิดว่าวิธีที่ดีที่สุดในการเข้าถึงสิ่งนี้คือการพิจารณาสิ่งที่คุณต้องการพิจารณา Bug ก่อน

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

บริษัท ของฉันใช้วิธีการต่อไปนี้เพื่อพิจารณาว่าควรแก้ไขข้อบกพร่องเมื่อใด:

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

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

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

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

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

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

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

ข้อบกพร่องที่พบในช่วง Sprint นั้นเป็นเพียงส่วนหนึ่งของการพัฒนา

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