本人比较懒，对于看书的话，并不是很喜欢。没养成习惯，而且每次看到书，都有厌学的情绪。习惯挂上网看内容，反倒不习惯纸质的东西。本来吧，现在工作其实很少用到敏捷开发的。现在这个项目主管，打算折腾一番，还买了个看板。在别人的推荐下，他去买了这么一本书——《精益开发实战》，豆瓣上也有这本书的信息。
书不厚，两三天可以过目完，既然是过目完的话。那么就可能印象不深了。所以，我就做了一些笔记吧。好记性不如烂笔头。加上自己的话，记性确实比较差。至于有没有用呢？我也不知道，我们项目小组也就打算开始搞，至于最后是形式化掉，还是真的有效的话，还有待商榷。用这边书里面的话来说。敏捷开发其实更加注重的是流程，并不断的去完善整个的流程，没有最完美的。
书内容还是不错的，毕竟是别人对于项目敏捷开发的总结。吸取别人的经验，并学以致用。不过现在还是只能保留这理论阶段，效果的话。还是以后在说吧。今天说的是笔记。
首先是涉及到一些开发的词汇，本人书读的少。
- 极限编程（XP）：是一种软件工程方法学，是敏捷软件开发中最富有成效的几种方法学之一。
- Scrum：是一种迭代式增量软件开发过程。
- 瀑布式开发流程：软件开发被分为需求分析，设计，实现，测试 (确认)， 集成，和维护这样的步骤依序进行。这个应该就是我们现在最常用的软件开发流程了。
- 利特尔法则：是一个有关提前期与在制品关系的简单数学公式，排队理论（Theory of Queues）中：在一个稳定的系统中，长时间观察到的平均顾客数量L，等于，长时间观察到的有效到达速率λ与平均每个顾客在系统中花费的时间之乘积，即L = λW.
- 约束法则（TOC）：在制造业经营生产活动中定义和消除制约因素的一些规范化方法，以支持连续改进。
接下来的话，则是一些散碎的笔记，比较乱。
提高1.0之后版本的发布频率，优点如下：发布频率高，则补丁小一些，每个版本的问题和风险也就相应降低了许多。看到这里的时候，想起国内外很多软件都有非常高的发布频率。比如CM的ROM，小米的ROM，确实能快速的解决一些出现的BUG之类的。
创意→功能→下十个功能→开发→系统测试→用户验收测试→上线，这个好像是作者关于看板的一些流程。忘记了，书不在我这边。
节奏（cadence）：固定周期反复发生的事情，构成项目的节律或心跳。比如：周期性回顾，周期性规划，周期性演示及系统测试，周期性版本发布。这个我觉得不错，有时候做事，就是要有节奏，节奏上来了，你想停也停不下来了。
多个团队的时候，需要有一个整体的看板，关联所有的子团队，已让所有的成员对于项目整体有一定的认知。这个是说他们团队越来越大，看板也越来越多，这时候就需要一个整体的看板，来让所有的子团队对看板有个整体的认知。
总体目标及里程碑：需要基于经验数据来大概定下次版本发布时间。并评估实现级别等的一些操作。
内部改进：升级数据库/清理无用代码/重构糟糕设计/对原有功能实现测试自动化，注重代码质量等。看到这里，我自己有些许的惭愧，有时候自己写的狗屎代码，又不想重构，重构有时候，就是体力活。哎。。。水准还有待提高。
BUG：定期系统测试，可以部分系统测试，不必等到整个系统完成。以较少BUG修复的时间。尽可能实现测试自动化。立马修复BUG，不提交BUG系统，当面沟通提高效率。预防BUG重现。BUG优先级，限定BUG数量。
持续改进流程：激励人们对流程做出革命性改进的思维就是敏捷和精益的基础。团队回顾，频繁检入代码，改变立会方式，更新代码编写规范。
流程改进讨论会：
- 做好准备
- 收集数据
- 产生见解
- 做出决策
- 结束会议
犹豫不决之时，选择最简单的方案。
努力完成一件事，而不是努力开始做另一件事！
专注开发的功能影响因素：
- 商业价值
- 知识
- 资源利用
- 依赖关系
- 可测试性
主干无垃圾，主干始终稳定至关重要。也就是意味着，可以进行系统测试。
每个团队有自己的分支。虽然宽松，但是代码必须编译，所有单元测试都必须通过。但功能不一定非要完成或测过。
团队完成一个功能后，需要做下列的行动：
- 检出主干代码并与团队分支合并
- 最后一次检查代码，确保团队分支代码已经稳定（可供系统测试）
- 将团队分支合并到主干
在测试发现BUG，并修复的话，则需要及时将fix的代码合并到主干上。
上面这些说的是版本控制的事情，我发现我们团队，代码控制，其实挺乱的。这一个，那一个，同一个库，有多个团队进行维护。导致后期部分接口改动了。没整合到一起的时候，可能不同产品没有影响，但是一旦整合，出什么问题，谁也不能保证。
没有完美的解决方案。伟大的流程不是设计出来的，而是逐渐演变出来的，所以重要的不是流程，而是我们用来改进流程的流程。
拥有专职变革推动者：一个来自内部，一个来自外部。这个好像是说定期会议上，要有外人在主持，确实，旁观者清。
如果是大家自己提出来的意见，人们会更容易接受变革（拉人入坑，被上贼船）。这点也确实，如果是你自己提出来的意见，那你应该会自己主动做好。
敏捷宣言：
- 个体和互动 胜过流程和工具
- 可以工作的软件 胜过详尽的文档
- 客户合作 胜过合同谈判
- 响应变化 胜过遵循计划
十二条原则：
- 我们最重要的目标，是通过持续不断地及早交互有价值的软件使客户满意。
- 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争又是，要通过敏捷过程掌控变化。
- 经常地交互可工作的软件，比如相隔几星期或一两个月就交付，倾向于采取较短的周期。
- 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
- 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
- 不论团队内外，传递信息效果最好、效率也最高的方式是面对面的交谈。
- 可工作的软件是进度的首要度量标准。
- 敏捷过程倡导可持续开发。负责人，开发人员和用户要能够共同维持其步调稳定延续。
- 坚持不懈地追求技术卓越和良好的设计，敏捷能力由此增强。
- 以简洁为本，他是极力减少不必要工作量的艺术。
- 最好的架构、需求和设计出自由组织团队
- 团队定期地反思如何提高成效，并依次调整自身的举止表现。
精益原则：
- 全局优化
- 消灭浪费
- 品质优先
- 不断学习
- 尽快交付
- 人人参与
- 不断提高
scrum核心概念：
- 按优先顺序排列的残破需求清单
- 跨职能团队：将产品所有人员划分为多个小规模、跨职能、自组织的开发团队。
- sprint
- 持续调整版本发布计划
- 持续调整流程
XP：
- 持续集成：拥有一个随着团队的开发可自动编译、集成并测试代码的系统。这样就能尽早为开发团队提供有关产品质量方面的反馈。
- 结对编程：在一台工作站上进行结对编程，从而是学习效果最大化、设计质量最大化、缺陷最小化。
- 测试驱动开发：采用测试代码驱动系统的设计。编写自动化测试脚本，然后编写刚刚足够的代码以使其通过测试，然后从根本上重构代码，提高其可读性，移除重复代码。清理并重复该过程。
- 集体代码所有权：允许（实际上是鼓励）开发团队的任何人编辑代码库的任何部分。这样可营造出团队所有权的意识，确保整个系统的设计都一致、易于理解。
- 增量式设计改进：从最简单的设计开始，然后运用重构等技术持续不断地改进设计，而不是从一开始就做好完整的设计。
看板规则：
- 可视化工作流
- 限定在制品
- 衡量并管理周期时间
哪些测试应当先予以自动化：
- 风险高但手动测试容易的测试，或者风险低但手动测试难度大的测试
- 易于手动测试且易于自动化的测试，或者手动测试难度大且自动化难度也大的测试
- 风险高且难以自动化测试，或者风险低且易于自动化的测试。
说起这个测试，我倒是觉得有时候开发的时候，测试还是很重要的，尤其是我们团队这边，测试人员有时候就是纯手动进行，对于脚本等一些功能的编写能力其实很差。虽然普通用户大部分不会使用脚本的方式来使用产品。但是自动化确实是一个很严重的问题。有些自动化测试，却是由研发来编写的。这样我觉得就不好了，一是增加了研发的负担，二是研发有时候会被自己套住，不能够更加客观的去测试。
开发团队讨厌手中的工作被打断，这样就打断了流程，摧毁了士气。
降低团队人员流动率。
团队间要相互信任。
上面3条，团队确实要降低流动率，我们这边有个团队因为某种的原因，流动率非常大，我刚到公司的时候，整个团队基本上就只剩下一个开发人员，还有头头了。这样可持续性太差了。不利于团队的发展。团队间的信任，如果你们连信任都没有，那么谈什么合作都是浮云了。
因果图陷阱，解决办法：
- 移除多余的图框，也就是无价值的图框
- 专注于深度优先，而非广度优先。别把所有的问题都写下来，而是写最重要的，并不断向下挖掘
- 接受不完美，永远不可能完美
- 问题涉及过广，尝试限定明确的问题
- 划分因果图为若干部分
建立因果图原因：
- 建立共识
- 发现问题对业务的影响
- 找到根本原因
- 消除恶性循环
不能太依赖因果图，而在于解决问题方法本身：提问角度，由此展开的讨论以及调查发现。
好了，上面这些就是关于这本书的笔记了，比较乱，有些内容都是书里面摘抄的。没看过英文原版。发这篇文章的话，仅作记录。
转载请注明： 转载自elkPi.com
本文链接地址: 精益开发实战读书笔记
