生产

软件开发本质论

价值

• 首先构建简单而试用的版本 —— 最小可行产品MVP(Minimum Viable Product)
• 当软件发布时，它的价值才能够体现 —— 总是将价值可能最大的任务列为下一个目标
• 价值的最大化在于频繁交付小的、以价值为中心的功能特性
• 功能特性的开发顺序不同会导致不同的价值收益，优先做性价比最高的功能特性
• 根据功能特性交付项目更具有可预见性——风险前置
• 没有功能特性交付的重构迭代是没有产生价值的 —— 管理层无法接受 —— 在功能特性迭代里做最有必要的微重构
• 如何衡量价值 —— 不同类型的价值具有可比性，抓主要矛盾，忽略次要矛盾。

管理

• 根据功能特性组织团队

  团队内的成员写作足以完成整个功能特性

• 根据功能特性进行计划

  做计划是必要的，详细的计划是无用的。 —— 计划本身是无用的，但做计划是必要的（艾森豪威尔）—— 常做计划，确定下一步要做的事情，不要吃太多 更好的方法：1）确定项目的时间期限和开支预算；2）优先开发那些最优价值的功能特性；3）确保产品能够随时发布、并在时间结束时立刻停止 每个迭代开始前，我们需要做好计划，为了确定每个迭代（2周左右）能够承担多少工作，需要理解要进行的工作。 持续计划：分解功能特性。
  估算有风险 —— 估算结果很可能会是错误的，而且它会使我们将注意力集中在成本上，而忽略价值。 根据"挑战性的目标"制定计划，危害性很大 —— 赶工会遗漏测试，给整个项目带来更多的缺陷，修复缺陷会影响进度。—— 尽量避免向团队施压

• 根据功能特性构建产品

  同时功能特性与基础 在每一个短周期内，完整地构建一个小的产品 —— 细化产品愿景

• 确定真实的进展

  为在交付日期到来时获得尽可能好的结果而努力 完成的定义 —— 完成了90% = 未完成 淘汰测试再修复的收尾方式 —— 无法预知截止日期，不断向后延期 —— 从根源上解决问题：开发人员全面测试

• 缺陷与测试

  缺陷使项目进展变得不确定，只有消除缺陷，我们才清楚真正完成了哪些功能特性。 修复缺陷会带来不确定的时间延迟。随时发现缺陷随时修复，这样才能清楚知道完成了哪些功能特性。 缺陷会导致延迟交付，出现缺陷是难免的，所以需要进行持续的、全面的测试 —— 业务测试和开发人员测试 开发人员测试需要以更快的频率进行 —— 更快的发现错误，提升开发速度 每次提交代码都确保经过测试，随时可发布

• 随着系统的功能特性越来越多，设计也需要进行相应的扩展 —— 任何时候都需要有高质量的设计

• 自然软件开发的管理之道

  管理主要就是确保项目能够正常地进行 —— 随时关注价值，要不停地思考下一件最有价值的事情是什么 尽最大可能以结果未导向来评价工作的好坏。至于要做什么、怎样做，则交给最接近实际工作的人员负责。 授权 —— 努力将比较小的组织决策权力下放到基层，通过预算来控制任务规模的大小。 管理层选定产品推动人、人事职员 产品推动人选择团队的核心人员 剩下的人员由整个团队来选择 在这一组织框架内，产品推动人与团队为了将工作做好而自发组织起来

• 能力是提高速度的前提

  不要把迅猛当做高效 —— 速度最快的团队总是平稳、优雅地前进。 为了加快开发速度，我们能做的最有价值的事情就是提高团队成员的技能。 减少浪费在修复缺陷上的时间，开发过程会更加顺畅，

敏捷

• 使用五卡法进行初步的预测 —— 拆分功能特性

  第一步，列出 3至5个史诗级组成部分 —— 大模块，一句话总结 第二步，将每个史诗级模块细化到 3至5个功能特性 —— 更具体、更明确 第三步，重复第二步，使每个卡片上的功能特性的大小都差不多 —— 团队成员认为能够在一周之内完成开发

• 重构

  露营地规则 —— 在离开露营地时，要让它比你来的时候更好。 在相关的地方做少量的代码清理工作并不会使速度变慢，因为大部分代码依然保持不变。而我们投入大量工作的那些代码由于受到更多的关注，自然很快就变得整洁了。 拒绝重构的诱惑。

• 关于框架

  框架并非越多越好 —— 个体和交互胜过流程和工具 框架要尽量轻 掌控框架，而不要被框架掌控 保持流程的改变贴近团队的实际 把学习放在首要的位置 思考 —— 构建有价值的产品是很复杂的工作，采取行动之前应做思考