《知行合一（实现价值驱动的敏捷和精益开发）》读书心得

敏捷开发宣言

敏捷开发框架

本书描述中的敏捷管理活动多以Scrum为核心，而工程活动则多以极限编程的方法为主。

项目管理铁三角

著名的项目铁三角：成本、进度、需求范围；

新的项目管理铁三角（敏捷铁三角）：价值驱动
价值目标、质量目标、约束目标（成本、进度等）
新的项目铁三角要求我们用投资回报分析（return on investment,ROI)作为管理者的决策方式；

需求和技术的不确定性

需求的自然进化：客户对自己真正需求的产品需要一个认识过程，这个过程将产品的愿景（vision）逐步细化到产品特性。需求的自然进化。
需求蔓延：客户单方面随意追加及需求，不做必要的价值分析，不考虑实施成本；

迭代

敏捷开发的两个重要特征是迭代开发和需求特性驱动管理；我相信这句话：看到错误的才知道什么是正确；
迭代的方式：小步快跑，在开发中学习、成长、调整和完善；
1、快速磨合
迭代也是团队从项目开始就有不断磨合的机会；而瀑布方式，只有在项目结束时，整个团队不同只能小组才有一次完整的配合机会；
2、快速反馈

持续集成、构建、自动化测试、自动化部署。（Jenkins）
每次构建都可以生成可发布的代码，修复失败的构建是优先级最高的事情。
80%的测试都是小而快的单元测试；凡是可以自动测的都自动测，手工测试仅覆盖需要人观察接入的测试（例如用户体验）。

技术债务

技术债务：质量目标不仅是科发布（功能正确），同时也是可维护的；技术债务可以看作是设计、开发不足的累积总和，技术债务的管理是决定敏捷成败的一个重要因素，带病迭代是敏捷第一杀手。
盲目的砍掉必要的文档工作会增加技术债务；文档的目的是为了方便沟通、方便运维以及支持沉淀；
有些技术债务也是可以的，毕竟它能够加快开发速度。就像我们用信用卡借钱花一样，有时候我们确实需要超前消费。。关键是要几十还款，否则利息会压垮我们。

精益文化

lean精益文化：流程可视化、持续优化、减少浪费（减少前置时间 lead time）、限制在制品（WIP work in processs）、消除瓶颈、拉动计划系统。

管理变革

著名的成功变革管理的五要素及其某一要素缺失时的后果：

问题

 内部团队开发人员容易做敏捷开发，但是外部公司因为商务原因还是比较困难，需求不明确，成本合同额难以定下来。

用户故事

用户故事 扑克牌估算法

文章摘要

• 极限编程（extreme），意思就是如果某个实践好，那就将其做到极限。例如，如果集成测试重要，那我们每天都做几次测试和集成（持续集成）
  
• 响应变化高于遵循计划：变化是软件开发过程中的一个常态：客户对业务领域的理解加深会导致变更；商业环境的变化会导致变更；技术的变化也会导致变更；人员的变动也会带来变更。
  
• 软件开发的软、易变、非线性增长复杂度； 制造业的生产过程高度重复，而软件开发中的不确定性，导致了过程重复是有限的。任何两个项目都不完全一样，不可能走过同样的步骤，这个差异是“明确定义的过程”不适用于复杂的项目管理类的重要原因
  
• 需求蔓延（requirement creep)是软件开发中最常见的风险之一；
  
• 如何度量价值不是件容易的事，我们可以从这几方面来考虑：产品的销售额、对品牌及竞争力的影响、通过创新给企业带来的新的机会；
  创新有风险，但也给企业带来新的机会。
  
• 敏捷开发有点类似美国电视剧的制作模式，电视剧是一集一集的拍，一集一集的播；根据观众的反馈进行调整；或者取消拍摄止损。
  
• 信息流失（药方抄3遍毒死人）：5个人参加的电视节目，第一个人做动作给第二个人看，然后第二个人努力将看到的做给第三个人看，直到最后一个人做给观众看。往往最后一个人展示的动作已经和第一个人的原始动作相差很大了。
  
• 不存在完美的产品，从商业角度来说，这其实是一个好事，不完美意味着机会，它能给我们带来商机。
  
• 正确的可执行代码是项目进展状况最准确的度量；
  
• 管理者应该是领导者，为团队定目标期望，而不是天天告诉团队如何做具体工作； 管理者的勇气，是做有远见的智慧型领导者。
  
• 让团队同时做多个项目，不会提升团队效率，这样的安排实际是效率杀手。
  
• 瀑布模式解决进度问题的方法是砍掉任务（通常是测试任务），而敏捷解决进度的方法是减少用户需求特性（低价值的需求）；前者牺牲的是质量，而后者砍掉了价值最低的用户需求；
  
• 一鸟入林，百鸟无声；
  
• 成就感让大家变得更主动；
  
• CCB 变更控制委员会
  PB product backlog 产品需求列表
  BS Business Specification 业务需求书
  FS Functional Specification 功能需求书
  
• 使团队成为真正的一个拳头而不是5个分开的指头。
  
• 出了问题不要责难，而是要鼓励；
  
• 如果发现自己不能解决一个问题，要有勇气不耻下问，寻求帮助。
  
• 从I型人才到T型人才，复合型人才；
  
• 谁报告坏消息，谁就要被处罚，结果是没人愿意报告坏消息了
  
• 看过几期《非常勿扰》，如果男嘉宾是软件工程师，基本的结果都是最后遭遇全部灭灯。（加班太多）
  
• 华为是最有勇气的IT企业，它把变革当作学习的机会、超越竞争对手的机会、发展壮大的机会。
  
• Scrum鼓励的是团队英雄行为，奖金的分发会更大程度上基于团队的表现，如果一个团队有优异的表现，那就请鼓励团队的每一个成员。
  
• 学会从全局看问题，学会平衡短、中、长期利益。
  
• IT的价值观：支持组织的业务目标及客户的期望。
  
• 合理不合法：合理说的是项目组被逼做出必要的裁剪（不一定是合适的），不合法讲的是实际的过程是不符合组织过程要求的。
  
• Donald Reinertsen:每个成功的产品都会有一个简单清晰的价值定位（value proposition)，消费者从众多竞争产品做选择时，往往只会根据三四个因素。
  
• 电梯陈述法：你必须能够用1-2分钟的时间（也就是从进入电梯开始到电梯落地），向一个高层讲清楚你的产品的价值定位。
  产品名称、价值、差异（优势）
  例如：牙医预约系统：为了帮助牙医及其助手能够方便地提前预约病人治疗时间，我们开发出牙医预约系统，它是个能够支持办公室电脑或者通过互联网预约地软件系统，和其他所有系统比，牙医预约系统非常简单易用。
  
• 心平气和对待冲突，不要害怕冲突；坚持原则。
  
• 不要把迭代回顾会议变成一个抱怨会议，如果识别出需要改进的都是团队外的人和事，这样的会议会变成没有价值的会议，很可能是在浪费时间。
  
• 用户故事：作为“角色”，我希望完成“活动”，这样可以获取“业务价值”
  我们需要从正常业务流程及异常处理两个角度挖掘用户故事，避免遗漏。
  
• 架构设计
  架构设计的主要价值在于，它对系统核心基础设施做一序列关键决策：哪里需要泛化？要使用分层模式吗？如果使用，每一层的职责是什么？每一层包含哪些模块以及为什么要创建这些模块？如果在层和组件之间之间划分系统的职责？如何将模块进行大规模部署？信息如何在模块之间以及系统与外围系统之间流转？
  
• 跑马拉松比赛，没有人像跑百米一样地冲刺，否则你一定会倒在中途。让一个团队连续几个月天天加班，也很难开发出高质量地产品。软件开发主要是脑力活动，像我每天集中精力有效工作时间也就6各小时，过了这个界限，脑子就明显钝化了。
  软件开发的节奏意味着阶段、活动的可预测性：固定的迭代周期、固定的回顾会、规定的评审会等，都会帮助团队形成自己的开发节奏。
  
• 成功是团队的成功，任何人不能由于团队的失败而受益。
  
• 收集信息（审查）的目的是为了根据信息完成必要的工作（调整）
  
• 例会的真正结果应该是确定会后要开哪些后续会议；例会上不要做深入的讨论，识别问题但不在例会上解决问题，例会后的会议才是问题解决的时机。
  
• 种子团队
  
• scrum中的共享团队资源
  1、公共模块团队
  2、架构团队
  3、测试团队（测试资源紧张的情况下）
  4、维护团队（缺陷修复、紧急功能实现等）
  
• 统计数据显示37%的软件开发问题和需求有关，其中13%源于无效的用户需求收集，12%源于需求遗漏，12%源于需求变更。需求问题带来的返工可能占整个返工的75%-85%
  
• Ron Radice关于技术评审的书名就叫“高质量低成本”，因为数据显示和测试相比，技术评审是一个高性价比的质量控制活动。
  
• 开发过程中发现的问题不应该算作缺陷，修复这些问题本来就是要做的事情。团队应该重点分析客户所报的缺陷。
  
• 导入敏捷
  
• 很多所谓的评估项目很可能是花瓶项目。
  类似体验，目前不是得到体验报告，关键是要根据这个报告进行调整和治疗；
  许多软件项目都处于2级迷茫，这也是许多软件项目往往需要追加成本的原因。
  
• 没有改进（改动）过的过程，很有可能是没有在项目中真正被使用。
  
• QA票是任务书的补充文档。
  
• 软件开发过程碰到的4级迷茫
  • 0级迷茫：开发过程需要做的一切都很清楚，没有迷茫之处；
    
  • 1级迷茫：很清楚地直到自己有一些不明确之处；
    
  • 2级迷茫：没有意识到自己有不清楚之处；
    
  • 3级迷茫：没有掌握有效的方法以发现自己不清楚之处
    
• 他说自己做得好的一点是讲清楚了许多人觉得理应如此的实践。
  
• 看板的实际意思是信号卡，看板代表其精益生产体系中的信号系统，精益拉动计划系统。
  
• 在维护好客户关系的前提下，客户不付钱的事少做，客户付钱的事情多做； 投资回报的角度来考虑。