ປະຕິບັດຢ່າງລະມັດລະວັງ

"Whatever you undertake, act with prudence and consider the consequences" Anon
"ອັນໃດເຈົ້າຮັບຜິດຊອບ, ປະຕິບັດຢ່າງລະມັດລະວັງ ແລະ ພິດຈາລະນາຜົນກະທົບ" ບໍ່ຮູ້

No matter how comfortable a schedule looks at the beginning of an iteration, you can't avoid being under pressure some of the time. If you find yourself having to choose between "doing it right" and "doing it quick" it is often appealing to "do it quick" on the understanding that you'll come back and fix it later. When you make this promise to yourself, your team, and your customer, you mean it. But all too often the next iteration brings new problems and you become focused on them. This sort of deferred work is known as technical debt and it is not your friend. Specifically, Martin Fowler calls this deliberate technical debt in his taxonomy of technical debt, which should not be confused with inadvertent technical debt.
ໂດຍບໍ່ສົນໃຈແຜນເປັນຕາວ່າງແນວໃດທຳອິດ, ເຈົ້າຊິຮູ້ສືກກົດກັນບານຄັ້ງ. ໃນກໍລະນີເຈົ້າຈຳເປັນເລືອກອັນໜຶ່ງໃນສອງອັນ "ເຮັດຢ່າງຖືກຕ້ອງ" ຫຼື "ເຮັດຢ່າງໄວ", ມັກເລືອກ "ເຮັດຢ່າງໄວ" ຄຶດເອງວ່າຊິແກ້ໄຂຈັກໜ້ອຍ. ເວລາເຈົ້າສາບານນີ້ຕົນເອງ, ໝື່ວຽກ, ແລະ ລູກຄ້າ, ເຈົ້າຄຶດນັ້ນຢ່າງເອົາຈິງເອົາຈັງ. ແຕ່ວ່າການພັດທະນາໃໝ່ເກີດຂຶ້ນບັນຫາໃໝ່ເລື້ອຍໆ ແລະ ເຈົ້າຈຳເປັນເອົາໃຈໃສ່ບັນຫານັ້ນ. ວຽກຊັກຊ້າແບບນີ້ເປັນທີ່ຮູ້ຈັກເປັນ technical debt (ໜີ້ສິນວິສະວະກຳ) ແລະ ອັນນີ້ບໍ່ແມ່ນໝູ່ເຈົ້າ. ໂດຍສະເພາະ, ທ່ານ ມາທິນ ຝາວຫຼ້າ (Martin Fowler) ເອີ້ນ technical debt ນີ້ວ່າ deliberate technical debt (ໜີ້ສິນວິສະວະກຳຢ່າງຕັ້ງໃຈ) ໃນ ເວັບໄຊ້ຂອງລາວ taxonomy of technical debt. deliberate technical debt ນັ້ນແມ່ນຕ່າງກັນກັບ inadvertent technical debt (ໜີ້ສິນວິສະວະກຳໂດຍບໍ່ຮູ້ສຶກ).

Technical debt is like a loan: You benefit from it in the short-term, but you have to pay interest on it until it is fully paid off. Shortcuts in the code make it harder to add features or refactor your code. They are breeding grounds for defects and brittle test cases. The longer you leave it, the worse it gets. By the time you get around to undertaking the original fix there may be a whole stack of not-quite-right design choices layered on top of the original problem making the code much harder to refactor and correct. In fact, it is often only when things have got so bad that you must fix it, that you actually do go back to fix it. And by then it is often so hard to fix that you really can't afford the time or the risk.​

Technical debt (ໜີ້ສິນວິສະວະກຳ) ຄ້າຍຄືການຢືມເງິນ: ເຈົ້າໄດ້ຜົນກຳໄລຈາກນັ້ນໃນໄລຍະສັ້ນ, ແຕ່ວ່າເຈົ້າຈຳເປັນຈ່າຍດອກເບ້ຍຂອງໜີ້ສິນນັ້ນເຖິງຈ່າຍທັງໝົດແລ້ວ. ທາງລັດໃນໂປຼແກຼມຊິເຮັດໃຫ້ການເຕື່ມຄວາມສາມາດ ຫຼື ການປັບປຸງໂຄດຍາກ. ເຫຼົ່ານີ້ແມ່ນຮັງຂອງບົກຜ່ອງ ແລະ test cases (ການເສັງກໍລະນີ) ຢ່າງອ່ອນແອ. ດົນກ່ວາເຈົ້າຖິ້ມນັ້ນໄວ້, ມັນຊິເປັນຮ້າຍແຮງກວ່າເກົ່າ. ເວລາເຈົ້າສາມາດເລີ່ມແກ້ໄຂບັນຫານັ້ນ, ເຈົ້າອາດຈະມີແຕ່ທາງເລືອກຂອງການອອກແບບຢ່າງບໍ່ຖືກເທິງບັນຫາທໍາອິດ. ມັນເຮັດໃຫ້ໂຄດປັບປຸງຍາກ. ຄວາມຈິງແລ້ວ, ເຈົ້າແກ້ໄຂບັນຫານັ້ນເວລາສະພາບບໍ່ດີ ແລະ ຈຳເປັນແກ້ໄຂບັນຫານັ້ນ. ແລະ ໃນຂໍລະນີນັ້ນ, ບັນຫາຮ້າຍແຮງຂຶ້ນແລ້ວ ແລະ ເຈົ້າບໍ່ມີເວລາ ຫຼື ລອງແກ້ໄຂເບິ່ງບໍ່ໄດ້.

There are times when you must incur technical debt to meet a deadline or implement a thin slice of a feature. Try not to be in this position, but if the situation absolutely demands it, then go ahead. But (and this is a big BUT) you must track technical debt and pay it back quickly or things go rapidly downhill. As soon as you make the decision to compromise, write a task card or log it in your issue tracking system to ensure that it does not get forgotten. If you schedule repayment of the debt in the next iteration, the cost will be minimal. Leaving the debt unpaid will accrue interest and that interest should be tracked to make the cost visible. This will emphasize the effect on business value of the project's technical debt and enables appropriate prioritization of the repayment. The choice of how to calculate and track the interest will depend on the particular project, but track it you must. Pay off technical debt as soon as possible. It would be imprudent to do otherwise.

ມີກໍລະນີເຈົ້າຈຳເປັນຮັບTechnical debt (ໜີ້ສິນວິສະວະກຳ) ເພືອທັນການສິ້ນກຳນົດ ຫຼື ພັດທະນາຄວາມສາມາດໜ້ອຍ.
ຫຼີກລ່ຽງກໍລະນີນີ້, ແຕ່ວ່າຖ້າສະພາບຮ້ອງຂໍນັ້ນ, ເຊີນລອງຮັບTechnical debt (ໜີ້ສິນວິສະວະກຳ). ແຕ່ວ່າ (ແຕ່ວ່າແທ້ໆ) ເຈົ້າຈຳເປັນໄລ່ Technical debt (ໜີ້ສິນວິສະວະກຳ) ແລະ ສົ່ງຄືນຢ່າງໄວໆ ຫຼື ສະພາບຮ້າຍແຮງຂຶ້ນຢ່າງໄວໆ. ທັນທີທີ່ເຈົ້າຕັດສິນການຮັບ Technical debt (ໜີ້ສິນວິສະວະກຳ), ຂຽນບັດວຽກງານ ຫຼື ລົງທະບຽນນັ້ນໃສໃນລະບົບ Issue Tracking System (ລະບົບທີ່ຈັດການບັນຫາຕົວຢ່າງ Redmine, JIRA) ເພື່ອບໍ່ລືມນັ້ນ. ສົມມຸດວ່າເຈົ້າວາງແຜນສົ່ງຄືນ Technical debt (ໜີ້ສິນວິສະວະກຳ) ໃນໄລຍພັດທະນາຕໍ່ໄປ (ມັນຖືກເອີ້ນວ່າ iteration ໃນການພັດທະນາຢ່າງວ່ອງໄວ agile), ຄ່າໃຊ້ຈ່າຍຊິເປັນໜ້ອຍທີ່ສູດ. ການບໍ່ສົ່ງຄືນ Technical debt (ໜີ້ສິນວິສະວະກຳ) ໄດ້ດອກເບ້ຍ ແລະ ດອກເບ້ຍນັ້ນຄວນເປັນຖືກບັນທຶກໄວ້ເພື່ອເຮັດຄ່າໃຊ້ຈ່າຍເຫັນໄດ້. ການເລືອກຄຳນວນ ແລະ ທັນທຶກດອກເບ້ຍແນວໃດແລ້ວແຕ່ໂຄງການ, ແຕ່ວ່າການບັນທຶກແມ່ນຄວາມຈຳເປັນ. ສົ່ງຄືນ Technical debt (ໜີ້ສິນວິສະວະກຳ) ໄວ​ທີ່​ສຸດ​ເທົ່າ​ທີ່​ຈະ​ໄວ​ໄດ້. ຖ້າວ່າບໍໄດ້ເຮັດສຳນັ້ນ, ມັນເປັນຄວາມບໍ່ຮອບຄອບ.

By Seb Rose