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

ความคิดบางอย่าง:

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

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

มันเป็นคุณสมบัติ

As a [Developer], 
I want to [refactor the whizbang library] 
in order to [simplify maintenance and speed execution]

มันถูกกำหนดและกำหนดเวลาและติดตามเช่นเดียวกับคุณสมบัติอื่น ๆ

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

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

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

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

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

ฉันแค่เรียกมันว่าเป็นงานบำรุงรักษา ในโครงการพัฒนาใด ๆ มีงานดังกล่าวจำนวนมากเช่นการตั้งค่าสภาพแวดล้อม dev / ทดสอบการรวบรวมข้อมูลการทดสอบการรวมสาขาใน SCM เป็นต้นไม่มีสิ่งใดที่ผู้ใช้สามารถสังเกตเห็นได้โดยตรง ต้นทุนและอัตราบั๊กในระยะยาว

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

improvementฉันจะเรียกมันว่า

ไม่ใช่ข้อผิดพลาดเพราะไม่มีอะไรเสียหาย

หรือคุณลักษณะเนื่องจากการเปลี่ยนโครงสร้างจะไม่เป็นคำขอของลูกค้าของคุณ (เพราะมันใช้งานได้!)

ระบบติดตามส่วนใหญ่จะรองรับประเภทของปัญหาimprovementตามค่าเริ่มต้นหากไม่ใช่คุณอาจจะสามารถแก้ไขประเภทได้