精益价值、原则和软件实践
2019-12-25
来源：软件乌托邦 吴雪峰
会体现在交付速度上，做的好的软件交付速度会越来越快。因为该做的基础工作都逐渐完善，开发人员的领域知识和开发技能也逐渐提高。
然而很不幸的，能逐渐提升交付速度的团队很少，理由往往是需求越来越复杂啊，以前都没提有这样的需求现在要大改啊什么的。而且没人正在度量交付速度，所以只是开发人员和客户都抱怨罢了。
减少浪费
以前西方流行的精益观念认为“减少浪费”是精益思想的精髓，然后有非常全面的识别和消除浪费的方法。
我觉得减少浪费是精益思想的很小一部分，就像我们想增加收入要做开源节流。不能认为节流能增加收入就当做主要手段用，导致影响开源。但很不幸的是节流比开源要容易很多，所以很多企业在危机时刻很容易选择节流而导致开源不利。
比如只从业务功能角度讲，搭CI/CD所花的时间是浪费掉的，因为没有直接产出业务价值。
减少浪费的观念确实非常有用，能有效指导消除不必要的工作。
响应客户需求 优于 创造库存
我发现开发团队很喜欢创造库存，有一些原因：
库存带来安全感；因为开发团队总是被客户挑战，手上拿几个已完工的需求会觉得到时候有货交差会很好。
库存里的东西不用马上验证，自己认为总是对的；
库存里面堆什么可以自己决定；人总是会倾向做自己熟悉或感兴趣的事情，而总是响应客户需求的话可能会被迫出舒适区。比如很多业务系统一上来就做个用户管理模块，虽然看起来这些基础模块是必须的，但在一开始的时候对客户业务人员来说真的是必须的吗，如果只有一两个用户明显可以工作，那硬写在代码里就可以了。
管理者不想让开发人员闲着；尽管当前没有明确的客户需求，管理者为了不让开发人员闲着，也会要求做一些有的没的需求，号称以后用的上。
客户不愿意频繁接收需求；这种情况多是因为客户接低质量的需求接怕了，所以拒绝频繁接，以为让完工的软件在库存里多呆一会质量会自动提高；第二是可以一鼓作气去应对低质量的需求，集中时间处理麻烦事。
敏捷宣言用了很大的比重来强调拥抱变化响应客户需求，很好地改变了软件开发团队和客户之间的信任关系。但是并没有什么方法很好的去响应客户需求，要不然Scrum这种固定时间盒的方法也不会大行其道了。
精益的拉动式流管理是完全面向客户的，利用客户需求驱动团队工作。而且只有需求交付到客户手上才算是完成了，使得软件尽早产生业务价值，这也是MVP思想的来源。
价值五：质量是结果而不是活动
内建质量
持续学习和改进
追求完美
内建质量
内建质量就不多说了，是我们倡导的实践口号，只是需要配合质量度量和持续改进，不然就只是口号了。
持续学习和改进
除了交付客户所需的价值，对我们来说更重要的是团队个人能力的提升。因为软件交付给客户价值后，对我们的价值(钱)也就结束了，唯有团队个人在交付的过程中不断提升，才能提升公司的整体价值和竞争力。
在敏捷管理里面设置回顾会议以支持持续改进，而且更关注问题和解决问题。为什么要等一个月或两个星期才做一次回顾会议呢？ 固定时间、固定任务、做固定的事情好处是能有一种仪式感，容易协调不同人的时间和工作内容。但因为反馈周期太长，算不上持续，只能说是断断续续的学习和改进。
其实最好的学习和改进机会是做到on demand，发现问题及时处理问题，如果处理不了及时提出来引起团队的注意。另外每日站会和每日code re
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
