Posted on 2010-12-23 23:55
mingj 阅读(6388)
评论(2) 编辑 收藏 所属分类:
agile 敏捷 、
PM 项目管理
作为技术人员，我们经常需要跟客户、业务分析人员等非技术人员沟通软件设计方面的问题。如何比较直观地向这些非技术人员解释设计、软件质量对项目的
影响，解释糟糕设计、不干净代码给项目带来的风险，解释我们必须开始关注软家设计问题？这里有两个概念（metaphor）可以帮助我们达到这一点：
技术债（Technical Debt）
“技术债”指的是，团队为了更早交付软件、更快交付客户价值或者其他一些考虑，被迫放弃良好的设计和干净的代码，从而对软件未来的扩展和维护欠下了“债
务”。技术债就像财务上的欠债一样，在前期债务较少的时候，投入时间和精力来解决技术债或许不如尽快交付的价值高。但随着债务的增多，必然会影响新需求的
交付和既有代码的维护，反而会延迟软件的交付。而且，技术债也具有财务债的特点，就是随着时间会像“滚雪球”一样指数上升。
设计偿还底线（Design Payoff Line）
与技术债对应的的概念是设计偿还底线（Design Payoff Line），指的是可以通过牺牲设计质量来获得上市速度（Time to
Market）的功能数量。当系统功能少于这个数量时，我们还能继续选择承担债务，但一旦超出这个数目时，债务就将影响软件的上线速度。可惜的是，这个值
更多的是一个经验值，团队很难预判项目的设计偿还底线在哪里，但是有一个后置评判标准是：当团队成员觉得无法忍受代码的设计质量时，或者当客户频繁听到代
码质量影响交付速度时，团队肯定已经突破了这条底线。