Technical Debt
http://www.scrumlabs.com/tag/technical-debt/
Technical Debt 是由Ward Cunningham 在1992中的一份experience report所提到的:
Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite.... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.
之後在agile的領域中常常出現這個term, 為什麼呢? 因為在agile中有iteration, sprint等東西, 因此你就會常常聽到engineer說, 這些東西下個iteration再做, 現在已經擠不進去. 以前不是agile的時候, 這個藉口也是常用, 只是因為周期較長, 以前在中後期比較會聽到這樣的事情. 但是現在會每次的iteration都會聽到一次:
* ‘We’ll do it in the next release’ – that never comes.
* The project got delivered – along with a maintenance team.
* We did it for good business reasons.
* “The architecture - let me see - I have a single power-point somewhere with a picture on it”.
* “To get anything released to production is a nightmare - we have to regression test the whole system”.
以下有兩篇好的文章, 在探討Technical Debt, 作者推薦大家可以參考一下:
An excellent article on Technical Debt by Kane Mar :
http://kanemar.com/2006/07/23/technical-debt-and-the-death-of-design-part-1/
And another excellent article by Steve McConnell:
http://forums.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx
作者也提到, 有一個方法可以mitigate這個問題, 那就是在幾個business focused 的sprints後, 加一個technical debt, 這樣可以幫助你之後的velocity, 還可以維持一定的水準, 不會被日積月累的負債給拖垮. 需知道當你有巨大的債務時, 即使光付利息也是會讓你喘不過氣來.
當然啦, 如果可以在每個release中減少technical debt, 那還是比排一個做refacoring 的TD sprint. 因為每天運動, 一定比假日或是有空運動, 效果要好的多, 代價也不會太多. 很多道理就是相通的.
http://www.scrumlabs.com/tag/technical-debt/
Technical Debt 是由Ward Cunningham 在1992中的一份experience report所提到的:
Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite.... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.
之後在agile的領域中常常出現這個term, 為什麼呢? 因為在agile中有iteration, sprint等東西, 因此你就會常常聽到engineer說, 這些東西下個iteration再做, 現在已經擠不進去. 以前不是agile的時候, 這個藉口也是常用, 只是因為周期較長, 以前在中後期比較會聽到這樣的事情. 但是現在會每次的iteration都會聽到一次:
* ‘We’ll do it in the next release’ – that never comes.
* The project got delivered – along with a maintenance team.
* We did it for good business reasons.
* “The architecture - let me see - I have a single power-point somewhere with a picture on it”.
* “To get anything released to production is a nightmare - we have to regression test the whole system”.
以下有兩篇好的文章, 在探討Technical Debt, 作者推薦大家可以參考一下:
An excellent article on Technical Debt by Kane Mar :
http://kanemar.com/2006/07/23/technical-debt-and-the-death-of-design-part-1/
And another excellent article by Steve McConnell:
http://forums.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx
作者也提到, 有一個方法可以mitigate這個問題, 那就是在幾個business focused 的sprints後, 加一個technical debt, 這樣可以幫助你之後的velocity, 還可以維持一定的水準, 不會被日積月累的負債給拖垮. 需知道當你有巨大的債務時, 即使光付利息也是會讓你喘不過氣來.
當然啦, 如果可以在每個release中減少technical debt, 那還是比排一個做refacoring 的TD sprint. 因為每天運動, 一定比假日或是有空運動, 效果要好的多, 代價也不會太多. 很多道理就是相通的.
全站熱搜
留言列表
