敏捷开发初识

朴灿烈づ我的快乐病毒、 2022-05-23 07:08 193阅读 0赞

###  ###

软件市场发展越来越迅速和成熟，传统瀑布式开发模式存在一定的限制，敏捷从而有了更广阔的的平台与机遇。Scrum作为在敏捷中使用最常用的一种方案，受到众多的关注。

### **定义：** ###

**敏捷开发（Agile Development）不是指某一种具体的方法论、过程或框架，而是一组价值观和原则。**

![70][]

### 理解： ###

*  首先，敏捷并不是一门具体的技术，而是一种理念或者说是一种思想。它可以指导我们更加高效的开发。
 *  其次，敏捷开发都具有以下共同的特征：

1.    迭代式开发

2.    增量交付

3.    开发团队和用户反馈推动产品开发

4.    持续集成

5.    开发团队自我管理

*  最后，相比于“传统”的瀑布开发模式，敏捷开发是一种“现代”的开发模式。

### 具体方式： ###

上面说了敏捷是一种指导思想或开发方式，但是它没有明确告诉我们到底采用什么样的流程进行开发，而具体的开发方式有哪些呢？

Scrum，[极限编程（XP）][XP]，[精益软件开发（Lean Software Development）][Lean Software Development]，动态系统开发方法（DSDM），特征驱动开发（Feature Driver Development），水晶开发（Crystal Clear）等等。

除了Scrum和XP，对于上面的其他开发方式，我也只是简单了解，大家可以多查查相关的资料。

我们可以简单的对比一下Scrum和XP：   
1. 在开发的过程中，你可以采用Scrum方式也可以采用XP方式；   
2. Scrum和XP的区别是，Scrum偏重于过程，XP则偏重于实践，但是实际中，两者是结合一起应用的。

### 敏捷宣言： ###

我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作，我们形成了如下价值观：

**个体与交互 重于 过程和工具**

**可用的软件 重于 完备的文档**

**客户协作 重于 合同谈判**

**响应变化 重于 遵循计划**

在每对比对中，后者并非全无价值，但我们更看重前者

### 敏捷开发的12准则： ###

在敏捷开发中，我们遵循以下准则：

1.    我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。

2.    欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。

3.    要不断交付可用的软件，周期从几周到几个月不等，且越短越好

4.    项目过程中，业务人员与开发人员必须在一起工作。

5.    要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。

6.    无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。

7.    可用的软件是衡量进度的主要指标。

8.    敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。

9.    对技术的精益求精以及对设计的不断完善将提升敏捷性。

10.   要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。

11.   最佳的架构、需求和设计出自于自组织的团队。

12.   团队要定期反省如何能够做到更有效，并相应地调整团队的行为。

### 什么是Scrum？ ###

Scrum 是一个用于开发和维持复杂产品的框架 ，是一个增量的、迭代的开发过程，通常用于敏捷软件开发。。原词来自于橄榄球中“带球过人”。在橄榄球比赛的每次冲刺前，都将有一个计划安排的过程，但冲刺开始后则由队员在原计划的基础上随机应发。

![70 1][]

### 评价： ###

很多觉得Scrum并没什么实质性作用，原因有这么几点：

1.    对于没有接触过Scrum的程序员来说，很难做到敏捷。

2.    用户故事的划分以及产品列表挑选最高优先级有点困难

3.    开发的过程中，团队中所有程序能够一直保持积极主动性很难把握

4.    Scrum对于自组织的团队要求很高

5.    对于在实施Scrum的过程中，对于把握全局的master以及产品负责人的要求更高。

6.    能否在实施的过程中及时发现问题，及时解决问题

不可忽视Scrum作用：

1.    Scrum团队总是先开发对客户具有较高价值的需求。

2.    更好的管理软件开发项目，它同样可以用于管理运行软件维护团队，或者作为计划管理，或者作为计划管理方法。

3.    提高团队的开发效率，降低项目的开发周期，最大限度的发挥团队的作用，更好的满足用户的需求。

优缺点：

Scrum的优点就是敏捷的优点，很注重实效，能更好的应对变化。

缺点是，他过于强调了人的自我管理。 有的观点认为，Scrum适用于一帮资深程序员组成的团队，每个人都是牛人，每个人都有激情干活，这样才work。在国内大家缺乏能动性，没什么激情，很不适合Scrum。

还有一个问题，就是很容易不停的因为目标变化而重新设计，最终导致不能交付。

Scrum并不能保证项目成功，它只是给你更多的反馈，更多的可控性，让你更灵活的应对变化。在实际项目中我们应该对Scrum进行可适应性调整。

下面是《启示录》的作者Marty Cagan对敏捷开发的态度：P156,159

![70 2][]![70 3][]

### **Scrum的详解【3355】** ###

**3角色**

Product Owner：决定每个冲刺的任务，决定选择做什么和为什么做这些。

Scrum Master：Scrum团队教练和带头人，扫除实施障碍。

Team：是任务执行团队，可以是研发团队，也可以是跨职能团队，能够切实提供一个可用产品的团队。

**3工件**

Product Backlog：产品待办事项集合，我理解也是 用户故事，相当于当前版本所要做的所有需求。

Sprint Backlog：迭代功能开发列表，理解为一个冲刺目标阶段内的需求列表。例举如，当前版本总共要完成40需求，是我们的Product Backlog；我们把当前版本拆分4个冲刺阶段，即是4个Sprint。第一个Sprint需要完成10个需求，则这10个需求为当前Sprint的Sprint Backlog。

Burndown chart：燃尽图，确定需求实现阶段后，随时间往后推进，时间剩余消耗，同时任务列表也随工作的推进而消耗。即是，迭代显示剩余工作时间和任务的完成情况。

**5价值观**

Focus 专注：将故事拆解为冲刺阶段，目标细化，同时也是集中绝对的团队能力，解决既定目标，体现当前的专注，也排除其他插入时间的消耗。

Courage 勇气：在整个敏捷过程中，需要效率的提升，同时，面临的技术、环境、团队等一系列的问题并不会变少，就需要有勇气，有决断的阔步向前，用最优势的精力、资源解决当前最迫切的问题。

Openness 公开：团队内信息的完全公开，让问题无所隐藏，同时也让优秀和战绩能够很好地展示及引导，公开，从而大家平等，从而大家尊重。

Respect 尊重：在敏捷过程中，因为公开我们搭建了尊重的基础；同时因为效率的要求和冲刺任务的明确性，我们做自己最擅长的事情，从而让整体效率最大化。尊重他人，信任他人。

Commitment 承诺：构筑团队内部共同解决问题，最高效率突击任务环境，是因为我们信守承诺，敢于给出承诺；同时，也因为我们为别人为团队的承诺，我们必须是最好的处理我们的任务，对于我们承担的责任敢于承诺，也直面承诺的责任。

**5工作**

sprint planningmeeting：冲刺前计划会议，决定并生成sprint Backlog。---类似需求评审

sprint：冲刺，由冲刺会议决定了我们的目标，从而确定了冲刺的阶段，人员及任务安排。---类似于计划

daily standupdomeeting：每日站会，主要用于跟进进度，确定当前任务的情形，同时沟通是否有异常情况。要将异常在开始阶段进行良好控制。

sprint review：冲刺回顾。一个冲刺完成，对冲刺进行回顾，整理有益处，执行良好的部分；规划检查不好的地方，可以做的更好的方面。优化中不断前行。

retrospectivemeeting：回顾会议。完成当前版本，需要对整体进行回顾，对经历经验进行整理归档，形成有效的成长型文档，便于团队更好的成长。

### **Scrum过程** ###

在我看来Scrum是一种轻量级的软件过程，它是一个项目管理框架。它是由一套关于项目的开发流程，开发维护人员沟通方法，各种最佳实践组成的。 一个完整的Scrum流程包括很多个Sprint（就是迭代），每个sprint在2到4周不等。

在项目开始时，将所有需要完成的工作列在一个Product Backlog中。

每次Sprint时：

1.        召开Sprint计划会议，在会议上产品负责人（Product owner）为Product Backlog中各项功能需求确定优先级。

2.        随后，开发团队“认领任务”，并把这些任务从Product Backlog中挪到Sprint Backlog中去。

3.        每天举行站立会议，参加人员Team Leader和Scrum团队，时间尽量短，15分钟即可。每个人回答3个问题：

a)        你已经做了什么？

b)        你即将做什么？

c)        你遇到了什么困难？

会议完后，相关人员可讨论遇到的问题。

4.        一个Sprint结束之后召开Sprint评审会议。会议主要展示本次迭代完成的原型，主要参与者包括所有对该产品感兴趣的人，可以是产品负责人，开发团队，客户等等，时间控制在两小时以内。

5.        召开Sprint回顾会议。会议由产品负责人、团队开发人员和Team Leader参加，总结本次迭代哪些做得好，哪些做得不好，团队在下一次sprint中要如何改进。

### **[Scrum详解见下一篇文章][Scrum]** ###

[70]: /images/20220523/0682f44da69f4b81926f6bb5791ea1b2.png
[XP]: http://baike.baidu.com/link?url=za2IFNeSuXjSk7pPJD2NO8Ef5iCmzlGLKv8IlddpQ6SlA5RE6MnFXU8EPLsh5yfBXf1VN_QVrCTwWPj5l1dTZ_
[Lean Software Development]: http://baike.baidu.com/link?url=a1dsOFhBEcxiLJNFihKD-GYiCiWqMubMaF_XyDMaCb7DKEwifGDgiQab-YUIEp7yimZmCQ-LrDEG3qGRZyQLaK
[70 1]: /images/20220523/adc9bc5ba00b4e91885336e6dbb0cef3.png
[70 2]: https://img-blog.csdn.net/20180604164003883?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2libGFkZQ==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70
[70 3]: /images/20220523/24678fb8d7894917a7780c9362e5fb67.png
[Scrum]: https://blog.csdn.net/iblade/article/details/80569794