《深入核心的敏捷开发》读书笔记（1）

 

 

敏捷开发的理念：

为了便于外界的理解，ThoughtWorks商定了一个经典答案“60%Scrum+40%XP”。

1.什么是Scrum？

首先，它是一套敏捷开发流程；是为了兼顾产品经理和程序员的保证项目正常交付的方法。

角色：

1）Project Owner：即产品经理，迫于领导的压力，喜欢往团队中不断增加任务或修改需求。

2）Scrum Master：类似于项目负责人，他需要做的是保护团队，兼顾产品经理的需求，确保项目的按时交付。

3）Team：开发测试设计人员，Scrum Master本身可能也是开发人员。

流程图：

 

其中还包括迭代回忆，每日站会，内部演示（review meeting）等形式。

2.什么是XP？

XP（eXtreme Programming）极限编程：在更短的周期内，更早地提供具体、持续的反馈信息。

在迭代的进行计划编制，首先在最开始迅速生成一个总体计划，然后在整个项目开发过程中不断的发展它。

依赖于自动测试程序来监控开发进度，并及早地捕获缺陷。

依赖于口头交流、测试和源程序进行沟通。

倡导持续的演化式设计。

依赖于开发团队内部的紧密协作。

尽可能达到程序员短期利益和项目长期利益的平衡。

 

其中包含一些方法：结对编程（pair），持续集成等。

我自己在ZTE实习的过程中也体会到了部分的持续集成带来的优点，基本每一周到两周的版本迭代，每日的Daily CI都是提升效率的好方法。

 

敏捷开发的经济价值：

1.产品投入市场速度加快

2.缩短新客户导流的周期

3.减少维护遗留系统成本

4.减少新开发系统的成本

其实也就是通过提高效率降低成本来提高收入。

敏捷开发的核心原则：

价值驱动+技术卓越（这个我目前没有入职还没有体会到hhh）

 

敏捷开发的核心实践原则：

1. 统一迭代节奏：

一个团队是全功能的，其中包含开发，测试，业务需求分析师，UX等角色。大家统一的进行迭代，并且跨职能协作，也就是你的角色不是固定的，所以对学习能力和开发能力要求都十分的高。

2. 基于Story的需求和范围的实时管理：

要求全角色都能够理解并且认可一个Story-----这样做能够体现价值驱动原则。

其中不对Story进行更技术的Task拆分，这样做也是为了让大家更多的关注在该故事的业务价值上。也就是所谓的“全栈文化支持”

3. 持续集成+测试驱动开发：

持续集成的两个核心：1）必须每次提交出发构建2）每次提交必须基于上一次的成功构建

测试前置（TDD）：先写单元测试是基本素养，对较为复杂的story做提前验收，早沟通早发现问题。

4. 效能和周期时间的持续改进：

实质问题围绕在Velocity和Cycle time上，每个团队都需要做的持续改进。

5. 基于客户深度参与的统一团队：

客户参与迭代内站会，展示会和回顾会。

 

迭代看板，通过以Story为核心，承载业务价值，实质上是吧质量管理融入了技术工程体系内，都是以团队为概念。

 

 

 

以上就是该书第一部分所讲内容，这一部分对敏捷开发做了一个基本的介绍，通过对团队中的布局，团队每天需要做的事，来详细的讲述了ThoughtWorks在开发过程中的整体流程，通过举例详细表明了开发过程中的角色，敏捷开发中的实践原则。