Talk is cheap, show me YY

当初曾经特别喜欢阅读《xx本质论》系列丛书，当图灵的1月新书《软件开发本质论》上架时，果断买下，选一个并不忙碌的周末，倾听《敏捷宣言》发起者Ron Jeffies 的文字，并记下自己的随感。

软件本质.jpg

本质论似乎还是有译文标题党的嫌疑，原名《The nature of software development》，核心观点是keep it simple，make it valuable，build it piece by piece。和敏捷思想的核心一致，保持简洁，追求价值，循序渐进。从终极的目标看，软件开发和其他非软件产品一样，都是为了尽早提供价值，持续提供价值。

价值第一

价值是what you want，是那些我们想要的东西。通常，软件的价值都与金钱有关，因为软件能够帮助人们节省时间或金钱。只有当软件发布的时候，价值才能体现，所以要找到一种方法尽早地交付价值。由于二八法则的存在，大部分用户并不会使用软件中所有的功能特性，想知道哪些特性是用户所必需的即方向是否正确，一个好方法就是尽早发布产品的小版本，所以必须看到并理解产品的各个部分。

价值包括商业价值、客户价值等不同维度，可能是信息，金钱，运行速度，开发进度，持续能力等等，不同类型的价值不具备可比性。价值的衡量在于共识。实现价值的途径就是构建软件并查看它的运行效果。
根据功能特性来划分价值，高度代表价值，宽带代表成本，价值的增长取决于我们选择做什么。价值的最大化在于频繁交付小的并以价值为中心的功能特性。

业务团队

要正视我们并不能实现所有的功能特性，进行引导而不是任其发展。事情很少会按计划发展，基于活动阶段的产品是一块搬不动的巨石。根据功能特性交付产品更具有可预见性，能够提供更好的信息和指导，也容易产生更好的效果。

了解康威定律，根据功能特性构建团队，就是“two pizza team” 或者全栈小团队，组建横向的实践社区，这样的功能特性团队使得“水平扩张”很容易。专家的高薪不仅因为他是专家，更重要的是能够帮助他人成为专家。一个强大的团队，目的来源于具体业务，自主能够给整个团队带来责任感，专精来自于迭代的过程。

计划本身是无用的，但做计划是必要的。根据功能特性进行计划，目标小而明确，开发能够以更好的方式进行。详细的计划往往是无效的，需要通过持续的计划分解功能特性。每个功能特性（user story）最好在2～3天内完成。工作量由团队自己作出，会更加投入。估算过程可能是，确定预算和截止日期，找一位产品负责人来决定功能特性的开发顺序，并组建能随时交付软件的团队，估算是有风险的。根据挑战性的目标制订计划，危害性很大。赶工会带来更多bug，糟糕的代码同样影响进度，压力大多数时间具有破坏性。估算会将注意力放到成本上，而忽略价值。

产品迭代

采用短周期迭代方法开发完整的小产品，细化产品的愿景，总是将价值可能最大的任务列为下一个目标。任务拆分的标准是：团队成员认为自己能够把握整个模块并且能够在一周完成。确定真实的进展，淘汰测试修复的收尾方式。为了确保没有bug，必须随时对一切进行检测，通过观察开发速度的变化，调整设计的程度。

产品需要坚实的基础，没有基础架构，构建功能特性往往无从谈起。基础优先意味着能够进入市场的功能特性太少，每次构建包括基础服务的功能特性同样意味着能够进入市场的功能特性太少，所以首先构建简单实用的版本MVP，在多次迭代中逐渐完善功能特性，构建够用的基础，为在交付日期前获得尽可能好的结果而努力。

测试开发

良好的过程控制可以有效地减少代码中的bug，产品的构建是由数量不断增长的能够正确运行的功能特性组成。bug 是拙劣的功能特性，使进展变得不确定，修复bug会带来不确定性的时间延迟，随时发现bug随时修复，只有消除bug，才清楚真正完成了哪些功能特性。出现了一两个bug，就意味着很多，必须尽最大的努力避免bug。这需要持续全面的测试，业务测试和开发者自测都需要自动化技术的支撑，开发自测需要以更快的频率进行。测试并未减少开发速度，反而更快。

设计容易退化，需要与时俱进。 每次改动都可能会破坏当前的设计，放任设计慢慢退化是不可取的。改进措施是预留空间或feature的重新处理，在改变设计的同时保持其良好状态，重构是一项必备技能。测试与重构结合，使增量开发成为可能。遵循营地规则可能是最好的选择：离开露营地时，要让它比你来的时候更好。

敏捷管理

管理层从总体上决定要做什么，由谁来做，控制好自己所参与的产品和项目的数量。没有固定的目标，一切都是为了能够获得最好的结果。努力将比较小的组织决策权力下放到基层，通过预算控制任务规模的大小，尽最大的可能以结果为导向来评价工作的好坏。

了解现有团队成员的价值，同时，团队对总体格局了解越多，工作就会做到越好。支持和指导是确保产品与企业的宗旨保持一致，向团队提供帮助和培训，优先提高团队的工作效率，然后才是个人，为提升技能提供真正的机会。能力是提高速度的前提，不要被迅猛当作高效，速度最快的团队总是平稳优雅地前进。

你并不能够总是得到你想要的东西，敏捷很简单，但是做到并不容易。Scrum 结合其他的技术实践就是极限编程，框架要轻，且不要被框架掌控，保持流程的改变贴近团队的实际，把学习放在首要的位置，多思考。大规模敏捷同样是简单的，敏捷团队是通过测试进行协调配合的。

Talk is cheap， show me the test。

wechat_footer.jpg