ใน Scrum คุณควรแยก backlog ใน backlog ที่ใช้งานได้และ backlog ด้านเทคนิคหรือไม่?

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

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

แนวทางที่ดีที่สุดคืออะไร หนึ่งหรือสองค้าง?

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

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

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

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

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

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

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

ฉันเห็นด้วยกับ Onno ว่าควรมีหนึ่ง Backlog หนึ่งรายการต่อโครงการ ไม่เช่นนั้นทีมจะต้องตัดสินใจด้วยตนเองซึ่งเป็นของเจ้าของผลิตภัณฑ์อย่างถูกต้อง

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

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

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

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

ฉันเห็นด้วยกับ MelR หากมีอะไรที่เป็น 'เทคนิค' เราต้องดูว่าทำไมเราถึงทำ - หรือแม้แต่สาเหตุและผลระยะสั้นและระยะยาว(สำหรับผู้ใช้) คืออะไร?

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

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

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

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

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

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

หากเรื่องราวของคุณเกี่ยวกับการสร้างหน้าจอเข้าสู่ระบบตัวอย่างเช่นคุณจะต้องพิจารณาการสร้างฐานข้อมูลด้วยหากยังไม่ได้สร้าง

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