读完《敏捷软件开发工具——精益开发方法》，我对“消除浪费”深有感触。
消除浪费是最为基本的精益原则，它是所有其他原则必须遵守的首要原则。实施精益开发的第一步是学会识别浪费。第二步是揭示最大的浪费源并消除它们。下一步是揭示最大的剩余浪费源并消除它们。再下一步是重复上述步骤。
软件开发中的7种浪费：部分完成的工作、额外过程、额外特性、任务调换、等待、移动、缺陷。
不以交付为目的实施的敏捷都是“假敏捷”，都是在“耍流氓”。在我的理解里这就是“部分完成的工作”，每次迭代不能交付，不能上线，得不到客户的体验反馈，没有经历市场真正的检验，系统存在“颠簸”的风险。这是根深蒂固的银行体制传统IT“瀑布开发模型”在作怪，一时半会也没法改变。这也是和真正互联网IT公司的最大差距所在。这需要自上而下的观念转变，从高层到业务部门、IT部门，那样才是真正的拥抱互联网，接纳敏捷。
针对自身项目，由于专业测试人员角色的缺失（这本该是项目启动前组建团队该完成的工作，淡化测试份量的思想蔓延作怪），往往团队成员完成开发将故事移入“故事完成”泳道就认为工作完成了，但实际这也是“部分完成的工作”，以及造成了“等待”。如果我们画价值流图就会更加深刻体会到该故事的价值在测试这个环节等待了好几天，而且造成了故事的堆积，对测试和UAT验收造成了一定程度的工作压力。“故事完成”后要立即启动测试以及UAT验收，让故事不停留最短实际到达“待上线”的泳道，这样才能消除浪费达到敏捷高效。
书中提及“一个好的文档价值检测方法是了解是否有人在等待当前正在编写的东西。那么该文书工作是一种增值活动。”非常认同，为什么在线协作编辑的wiki里编写设计推不动，原因很简单，因为部分合作公司人员没有云桌面，他们看不到，没法通过wiki进行指导开发，所以文档传递还是需要word，xls进行传阅。故设计人员避免浪费也就没习惯在wiki里进行接口设计等了，这就是减除“额外过程”，但这也造成了另外一种浪费：多个设计人员不能并行设计，存在文档的反复更新以及重复复制粘贴，以便保持文档始终最新。这个问题的解决方案最好的就是让所有开发人员都有云桌面或者在云外能推行wiki，让大家从习惯的所谓word/xls的“舒适区”里走出来，接收“学习区”的wiki，久而久之，把wiki变成大家舒适区中的一部分。
再谈谈“任务调换”，如果一个人手头并行做几个开发任务（甚至还是不同故事的），看板“doing”泳道就能很清晰的体现，那么他就存在“任务调换”浪费的可能性。如何避免？串行开发，分配任务的同事要做做好把控，最高效的敏捷是“doing”泳道里这个人始终都在，且只在做一件事。
最后简单提提“移动”，在软件开发过程中，将制品从一个团队移交到另一个团队是产生巨大浪费的根源。一个团队具备端到端的交付能力，正是消除“移动”这种浪费。很庆幸，我们团队做到了。
精益思想的起源源自制造业的神话“丰田”汽车制造公司，他的核心思想就是“消除浪费”。对于制造业而言，仓库是浪费，运输是浪费，等待下一道工序是浪费，额外加工是浪费，返工是浪费，等等。任何不能为顾客创造价值的事物都是一种浪费。IT行业共勉。
