新闻资讯   News
联系我们   Contact
搜索   Search
你的位置:首页 > 新闻资讯 > 文章博客

软件开发公司中软件开发过程的几种浪费情况[Z]

2015-03-06 20:52:36      点击:

软件开发公司中软件开发过程的7大浪费

[转]

软件开发公司,深圳软件公司,软件定制设计

1. 软件开发中额外的功能特性

根据Standish Group的调查报告,传统的软件开发公司的过程制造了大量人们不需要的功能特性(7% always used,13% often used,16% sometimes used,19% rarely used,45% never used)。每个功能的实现,都要经历软件开发的整个生命周期:需求分析、设计、编码、测试、发布和维护,这需要耗费大量软件公司的团队的人力、物力和财力,如果最终人 们将不会用到这些功能,那么所有的投入都变成了浪费。而这还没有考虑过多的功能特性带来的系统复杂度所增加的开销。所以额外的功能特性是软件开发过程中最 大的浪费。


2. 软件开发的部分完成的工作(存货)

在Lean Thinking这本书里面,Mary Poppendieck把制造业的七大浪费之一“存货”对应于软件开发中的需求列表,她这种判断所处的环境是软件需求被写得非常细致,细致到可以直接用于 编程的程度,同时这些细化了的需求又不会立马被拿去实现,相反它们会在需求列表中等待相当长的一段时间。当然,毫无疑问这是软件开发中的“存货”之一,然 而我认为这并不是全部存货。另外还有一些常见的现象是大部分“已编码完成”的功能不得不等待很长一段时间才会被测试,而被测试了的功能会等待相当长一段时 间才拿去被客户验收,这些通通都是软件开发过程中的存货。它们是第二大的浪费。


3. 系统设计额外的步骤(过度处理)

很多时候,公司的开发设计团队会存在过度处理的情况,这种浪费在Lean Thinking中被识别为对需求的过多细化以及不必要的文档工作,我也认同这种说法。同样我也认为这种说法并不全面,因为额外的步骤(过度处理)不仅仅 存在于需求中,还存在于代码中。不少程序员会在代码中去做很多“预防性”工作,譬如预见可能发生的变化或者可能出现的情况,为了为这些变数留有余地,结果 通常是在代码中写一些额外的代码。这种做法一方面增加了不必要的复杂性,另外一方面如果“可能的”情况永远没有发生,这些代码就成了负债。设计模式的出现 可能会让这种问题缓解很多,然而我们还是要处处留意在开发过程中是否进行了过度的处理。


4. 寻找信息(上下文切换)

在企业的软件开发过程中,经常要找软件产品的最终客户确认或者澄清需求,要向开发者传达设计思路和技术要点,要找团队成员了解项目进展情况,要彼此反应遇到的问题以及解 决办法等等,总而言之就是干系人之间彼此需要大量的沟通,所有这些沟通都是信息传递的过程,所以及时准确地传达信息是非常重要的。与此同时,软件开发公司团队经常 面临的境地是很难找到客户进行需求沟通和确认,或者不得不花费很多时间和精力去寻找各种需要的信息,也经常遇到由误解造成的尴尬和浪费。团队用在寻找信息 上面的时间,并不直接创造软件的价值,所以是一种浪费,应当努力去减少。

我在一些社区中也看到有些人把上下文切换定义为七大浪费之一,仔细思考之后,我认为上下文切换的过程其实也就是及时找到另一类信息,并且进入状态的过程,所以它跟寻找信息的含义是一致的。


5. 公司软件产品缺陷(Defects)

在软件系统设计 中,Bug创造价值么?不,没有Bug才是客户所期望的。Bug产生开销么?是,发现Bug、报告Bug、定位Bug、修复Bug、验证Bug等都要花 费开销。Bug是可以避免的么?大多数Bug都是可以避免的。所以软件中的缺陷真是彻头彻尾的浪费,如果能采取适当的措施减少Bug的出现,那必定会节省 下来很多用来处理Bug的时间,然后把这些时间用在有价值的事情上面,这一正一负会产生巨大的差别。


6. 等待客户反馈

等待也包括让客户等待。无论是客户的等待,还是开发团队内部的互相等待,都是没有价值的事情。等待也会推迟问题的暴露和解决时间,所以减少等待就是减少浪费。


7. 移交软件产品(Handoffs)

据研究一个人若表达能力尚可,大概能表达出70%左右的意思,若对方理解能力尚可,大概能理解70%~80%的意思。若真如此,设想信息从一个人手 里传递到另一个人手里,然后再传递到下一个人手里,再往下传,还剩多少了?工作的交接也是一样的道理,经手的人越多,需要交接的地方越多,花费的代价就越 高。所以减少交接就是减少浪费。