精益价值、原则和软件实践
2019-12-25
来源：软件乌托邦 吴雪峰
所谓精益思想的价值和原则非常多，我这里引用ThoughtWorks同事Jonny Schneider即将出版的《Understanding Design Thinking,Lean,and Agile》， 试图通过日常软件开发实践来补充这些看起来很虚的价值和原则，希望能推广精益成为更好的软件开发指导思想。
价值一: 学习和适应 优于 分析和预测
原则:
通过实践验证假设，而不是分析和计划
延迟决策到最后一刻
刻意练习科学思维
通过实践验证假设，而不是分析和计划
我们都知道邓小平说“实践是检验真理的唯一标准”，但在软件开发的时候往往都忘了这句话。
软件开发是一个需要高度协作的工作，涉及到想法提出、需求分析、设计和实现、测试和交付、价值验证，又因为每个环节被要求做到最好，结果就很容易陷入局部打转，进行低效的分析和计划中。
比如领导提出的一个想法，就马上变成正式需求进行大规模实施，然而没有经过验证的想法只是个价值假设，我们需要先把想法进行实践验证才能确定想法是有价值的。但是有更坏的一种情况，就是大家都有想法，但就是一直分析分析而没有任何行动。这种情况比一有想法就进行盲目的行动还要坏得多，盲目行动后至少能知道一条路是不通的，一直在原地打转却是实实在在的浪费精力和时机。
每个项目基本上都会抱怨需求多、需求不稳定，于是就加大对需求的分析投入。但过犹不及，开发团队有时候会没有具体的需求做，因为需求还在分析中。然而我又没见过一个需求分析能做到完全清晰不需要在开发阶段再进行分析和澄清的，所以INVEST原则的第二条，就是能沟通，而不是要求把需求做到尽善尽美。INVEST原则的最后一条是可测试，来验证"Done"，而不要开发扯皮说“我就是根据你说的做完了啊，怎么这个需求又变了。”
延迟决策到最后一刻
我反对Scrum管理方式的一个原因是Scrum设置了一个所谓的时间盒，在这个时间盒里面开发工作不能被打断。首先我没见过不打破时间盒的实践，第二，时间盒的概念违反敏捷宣言中“欣然面对需求变化”的原则，时间盒只是换了个花样拒绝需求变化而已。
另外Scrum又要求进行工作量评估用来做计划，然而我们知道评估工作量基本上是很扯淡的事情，基本上误差在100%以上。而且团队的产能是固定的，不知道做计划的价值是什么。
我比较同意做粗粒度的时间里程碑规划，用来规划几个特别重要的需求，而对于日常的管理工作完全没必要做计划。
具体来说就是，延迟决策到最后一刻，开发团队什么时候做下一个需求应该由什么时候做完上一个需求决定。先做哪个需求应该等到需求马上就要进入开发状态了再做决定。而不是做个Sprint计划用一天时间把一两个星期的决策都做了。
刻意练习思维方式
用Kata训练思维方式。很多时候我们所谓的知道了，其实只是记住了一些名词和解释，并没有领悟内涵。就像有很多争论的TDD一样，可能很多人没有刻意练习过TDD，并不知道TDD到底好不好，优缺点是什么，只是因为听说TDD好或TDD不可行，就给自己下了个结论。
软件开发中有很多是手艺的问题，需要手脑协同完成。我说应该把重构剥离出TDD，同事杨云说重构是软件开发的习惯，无所谓剥不剥离。就是说重构已经成为杨云进行软件开发的行为习惯，看到bad smell就会自然感觉不爽从而进行重构一把。但是对于新手来说，这不是看完《重构》就能学到的，需要刻意的练习。Pair programming和code review都是新手刻意练习重构的好时机。
价值二: 赋
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
