精益开发实战读书笔记

本人比较懒,对于看书的话,并不是很喜欢。没养成习惯,而且每次看到书,都有厌学的情绪。习惯挂上网看内容,反倒不习惯纸质的东西。本来吧,现在工作其实很少用到敏捷开发的。现在这个项目主管,打算折腾一番,还买了个看板。在别人的推荐下,他去买了这么一本书——《精益开发实战》,豆瓣上也有这本书的信息

Lean from the Trenches

书不厚,两三天可以过目完,既然是过目完的话。那么就可能印象不深了。所以,我就做了一些笔记吧。好记性不如烂笔头。加上自己的话,记性确实比较差。至于有没有用呢?我也不知道,我们项目小组也就打算开始搞,至于最后是形式化掉,还是真的有效的话,还有待商榷。用这边书里面的话来说。敏捷开发其实更加注重的是流程,并不断的去完善整个的流程,没有最完美的。

书内容还是不错的,毕竟是别人对于项目敏捷开发的总结。吸取别人的经验,并学以致用。不过现在还是只能保留这理论阶段,效果的话。还是以后在说吧。今天说的是笔记。

首先是涉及到一些开发的词汇,本人书读的少。

  • 极限编程(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的代码合并到主干上。

上面这些说的是版本控制的事情,我发现我们团队,代码控制,其实挺乱的。这一个,那一个,同一个库,有多个团队进行维护。导致后期部分接口改动了。没整合到一起的时候,可能不同产品没有影响,但是一旦整合,出什么问题,谁也不能保证。

没有完美的解决方案。伟大的流程不是设计出来的,而是逐渐演变出来的,所以重要的不是流程,而是我们用来改进流程的流程。

拥有专职变革推动者:一个来自内部,一个来自外部。这个好像是说定期会议上,要有外人在主持,确实,旁观者清。

如果是大家自己提出来的意见,人们会更容易接受变革(拉人入坑,被上贼船)。这点也确实,如果是你自己提出来的意见,那你应该会自己主动做好。

敏捷宣言:

  • 个体和互动 胜过流程和工具
  • 可以工作的软件 胜过详尽的文档
  • 客户合作 胜过合同谈判
  • 响应变化 胜过遵循计划

十二条原则:

  1. 我们最重要的目标,是通过持续不断地及早交互有价值的软件使客户满意。
  2. 欣然面对需求变化,即使在开发后期也一样。为了客户的竞争又是,要通过敏捷过程掌控变化。
  3. 经常地交互可工作的软件,比如相隔几星期或一两个月就交付,倾向于采取较短的周期。
  4. 业务人员和开发人员必须相互合作,项目中的每一天都不例外。
  5. 激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。
  6. 不论团队内外,传递信息效果最好、效率也最高的方式是面对面的交谈。
  7. 可工作的软件是进度的首要度量标准。
  8. 敏捷过程倡导可持续开发。负责人,开发人员和用户要能够共同维持其步调稳定延续。
  9. 坚持不懈地追求技术卓越和良好的设计,敏捷能力由此增强。
  10. 以简洁为本,他是极力减少不必要工作量的艺术。
  11. 最好的架构、需求和设计出自由组织团队
  12. 团队定期地反思如何提高成效,并依次调整自身的举止表现。

精益原则:

  • 全局优化
  • 消灭浪费
  • 品质优先
  • 不断学习
  • 尽快交付
  • 人人参与
  • 不断提高

scrum核心概念:

  • 按优先顺序排列的残破需求清单
  • 跨职能团队:将产品所有人员划分为多个小规模、跨职能、自组织的开发团队。
  • sprint
  • 持续调整版本发布计划
  • 持续调整流程

XP:

  • 持续集成:拥有一个随着团队的开发可自动编译、集成并测试代码的系统。这样就能尽早为开发团队提供有关产品质量方面的反馈。
  • 结对编程:在一台工作站上进行结对编程,从而是学习效果最大化、设计质量最大化、缺陷最小化。
  • 测试驱动开发:采用测试代码驱动系统的设计。编写自动化测试脚本,然后编写刚刚足够的代码以使其通过测试,然后从根本上重构代码,提高其可读性,移除重复代码。清理并重复该过程。
  • 集体代码所有权:允许(实际上是鼓励)开发团队的任何人编辑代码库的任何部分。这样可营造出团队所有权的意识,确保整个系统的设计都一致、易于理解。
  • 增量式设计改进:从最简单的设计开始,然后运用重构等技术持续不断地改进设计,而不是从一开始就做好完整的设计。

看板规则:

  • 可视化工作流
  • 限定在制品
  • 衡量并管理周期时间

哪些测试应当先予以自动化:

  • 风险高但手动测试容易的测试,或者风险低但手动测试难度大的测试
  • 易于手动测试且易于自动化的测试,或者手动测试难度大且自动化难度也大的测试
  • 风险高且难以自动化测试,或者风险低且易于自动化的测试。

说起这个测试,我倒是觉得有时候开发的时候,测试还是很重要的,尤其是我们团队这边,测试人员有时候就是纯手动进行,对于脚本等一些功能的编写能力其实很差。虽然普通用户大部分不会使用脚本的方式来使用产品。但是自动化确实是一个很严重的问题。有些自动化测试,却是由研发来编写的。这样我觉得就不好了,一是增加了研发的负担,二是研发有时候会被自己套住,不能够更加客观的去测试。

 

开发团队讨厌手中的工作被打断,这样就打断了流程,摧毁了士气。

降低团队人员流动率。

团队间要相互信任。

上面3条,团队确实要降低流动率,我们这边有个团队因为某种的原因,流动率非常大,我刚到公司的时候,整个团队基本上就只剩下一个开发人员,还有头头了。这样可持续性太差了。不利于团队的发展。团队间的信任,如果你们连信任都没有,那么谈什么合作都是浮云了。

 

因果图陷阱,解决办法:

  • 移除多余的图框,也就是无价值的图框
  • 专注于深度优先,而非广度优先。别把所有的问题都写下来,而是写最重要的,并不断向下挖掘
  • 接受不完美,永远不可能完美
  • 问题涉及过广,尝试限定明确的问题
  • 划分因果图为若干部分

建立因果图原因:

  • 建立共识
  • 发现问题对业务的影响
  • 找到根本原因
  • 消除恶性循环

不能太依赖因果图,而在于解决问题方法本身:提问角度,由此展开的讨论以及调查发现。

 

好了,上面这些就是关于这本书的笔记了,比较乱,有些内容都是书里面摘抄的。没看过英文原版。发这篇文章的话,仅作记录。

转载请注明: 转载自elkPi.com

本文链接地址: 精益开发实战读书笔记

发表评论

电子邮件地址不会被公开。 必填项已用*标注