敏捷软件开发基础知识

• 下载 PowerPoint 演示文稿

Content

• 引言
• 什么是敏捷？
• 敏捷的基础
• 什么是敏捷软件开发？
• 通过示例探索敏捷理念
• 敏捷基础
  1. 敏捷宣言（价值观）
  2. 敏捷原则
  3. 敏捷方法论
• 传统的软件开发
• 敏捷与传统软件开发（瀑布模型）的对比
• 敏捷的优势
• 敏捷的劣势
• 敏捷的应用
• 敏捷的障碍
• 关注点
• 参考文献
• 历史

引言

本文旨在解释敏捷的概念、历史、基础和原理。

"一图胜千言"。使用图片并不意味着文章轻松；事实上，我正试图用一种简单的方式教授一个相当复杂的概念。因此，我使用了太多的图片来将理论映射到可以想象或绘制的东西，从而提供更好的理解。

在我工作经验中，我发现很多人对敏捷有误解。他们使用一些敏捷方法论（如 Scrum、RUP），但不知道敏捷本身意味着什么。

因此，我写了这篇文章，以提供对敏捷软件开发的基本理解。它侧重于通用的敏捷理论，因此读者不需要有技术背景。
此外，它可以作为理解敏捷理念的参考。

什么是敏捷？

它是一种理念、文化、思维方式或一套价值观。

敏捷的基础

2001 年，一小群人聚集在一起，讨论他们觉得传统的软件开发项目管理方法经常失败，肯定有更好的方法。他们提出了一个名为敏捷宣言的东西，其中描述了 4 个重要的价值观，我们将在本文后面详细讨论。

什么是敏捷软件开发？

敏捷软件开发是一种不同的管理 IT 开发团队和项目的方式。另外，我们可以说它是传统顺序开发或瀑布模型的替代方案。

通过示例探索敏捷理念

对我来说，将敏捷解释为一个想要减肥并变得敏捷的胖子是很自然的。
这个例子将贯穿他应该关注的价值观、原则，然后是他需要应用的（饮食计划）方法论。


在上图的左侧图片中，我们可以看到一个胖男人（不敏捷），然后他变成了瘦子（敏捷），如右侧图片所示。
让我们采访一下这个人，让他告诉我们他是如何改变自己的。

1. Q1 – 请告诉我们您是如何变得敏捷并减掉多余体重的？
   答案
   我给自己设定了一些价值观，然后体现这些价值观，并通过一系列原则提供更具体的例子。然后，我通过一些饮食计划（方法论）应用了（价值观和原则）。
2. Q2 – 请告诉我们价值观？
   答案
   1. 改变饮食习惯胜过遵循节食计划。
      改变饮食习惯，比如开始烹饪低胆固醇的健康食物，享用黑巧克力、无糖咖啡、新鲜果汁，这比遵循节食计划更重要。
   2. 控制食量胜过吃特定的健康食品。
      一次性戒掉所有不良饮食习惯会很困难。因此，控制食量并逐渐减少食量更为重要。
   3. 做你喜欢的运动胜过遵循特定的健身动作。
      做你喜欢的运动比做一套具体的、以后会让你感到厌烦的动作更重要。
   
   
   “也就是说，尽管右边的项目有价值，但我们更看重左边的项目。”
   
   
3. Q3- 请告诉我们原则？
   答案
   1. 停止计算：计算每一卡路里或克脂肪对长期保持体重没有任何帮助。
   2. 评估你吃的食物：注意你吃的碳水化合物、蛋白质和脂肪的质量。避免精制淀粉、糖和饱和脂肪。
   3. 拥抱多样性：不要只依赖少数几种食物。
   4. 保证充足的睡眠：你的身体每天需要 8 小时睡眠。
   5. 提高自我意识：例如，开始喝绿茶，每周去健身房 3 到 6 天。
4. 请告诉我们您尝试过的饮食计划（方法论）？
   答案
   我尝试过阿特金斯饮食法、穴居人饮食法、血型饮食法和脂肪冲洗饮食法。我发现血型饮食法更适合我。

敏捷基础

敏捷的基础与上述示例非常相似；它有价值观、原则和方法论。

1. 敏捷宣言（价值观）：4 个敏捷价值观是敏捷理念的基石。
2. 敏捷原则：12 个敏捷原则体现了价值观，并在更低的层面上提供了更具体的敏捷含义示例。
3. 敏捷方法论：支持敏捷价值观和原则的方法（Scrum、XP 等）。

1. 敏捷宣言（价值观）

   正如我在本文前面提到的，2001 年2月，17 名软件开发人员在犹他州雪鸟度假村会面，讨论轻量级开发方法。他们发布了《敏捷软件开发宣言》，定义了现在称为敏捷软件开发的方法。宣言的作者成立了一个非营利组织，推广按照宣言原则进行的软件开发。
   
   敏捷宣言全文如下：
   “通过实践和帮助他人实践，我们正在发现更好的软件开发方式。通过这些工作，我们开始重视：”

   1. 个体与互动胜过流程和工具。
   2. 可工作的软件胜过详尽的文档。
   3. 客户协作胜过合同谈判。
   4. 响应变化胜过遵循计划。

    

   
   
   “也就是说，尽管右边的项目有价值，但我们更看重左边的项目。”
   
   

   敏捷宣言（价值观）解释

   • 敏捷价值观（1） 个体与互动胜过流程和工具。

     
     如果流程和工具被视为管理产品开发及相关一切的方式，那么人员和他们工作的方式必须符合流程和工具。僵化的遵守使新想法、新需求和新思维难以适应。然而，敏捷方法更看重人而非流程。这种对个人和团队的强调将焦点放在人以及他们的精力、创新能力和解决问题的能力上。

   • 敏捷价值观（2） 可工作的软件胜过详尽的文档。

     
     文档不产生任何价值。只有软件才产生价值。敏捷宣言要求我们关注结果（可工作的软件），并通过权衡来最小化手段（详尽的文档）。
     这并不意味着你不应该编写文档；而是说你应该编写有价值的文档，同时又不妨碍团队的进展。
     换句话说，在会议中向客户展示文档不如展示可工作的软件更有用、更受欢迎。

   • 敏捷价值观（3） 客户协作胜过合同谈判。

     
     在传统的开发模式中，软件公司和客户需要详细记录他们想要什么以及将要做什么。这为项目失败时分配责任提供了依据。
     与此形成鲜明对比的是，敏捷建议我们应该优先考虑共享协作努力，而不是合同义务。
     如果你经常与客户进行实际协作，你会发现合同不会在每次会议中被拿出来。
     总的来说，我们可以说合同的重要性不如签订它的人。

   • 敏捷价值观（4） 响应变化胜过遵循计划。
     

     许多围绕软件的传统方法论都致力于控制变化。
     敏捷说：“我们不会控制变化。我们应该拥抱它，应该预料到它的发生，并在它发生时找出应对方法。”

     “休姆菲里斯定律”说，客户在看到可工作的软件之前永远不知道自己想要什么。因此，我们必须预料到开发过程中会发生很多变化。
     敏捷方法论基于这样的认识：变化不是值得恐惧或回避的。变化是增加价值的驱动力。所以不要抗拒变化，但要对其保持韧性。

   • 提议的第 5 个 精湛技艺胜过执行。
     
     

     Robert "Uncle Bob" Martin 提议更新敏捷宣言，增加第五个价值观：“精湛技艺胜过执行”。

     我们重视精良制作的软件胜过可工作的软件。软件能够工作非常重要，但更重要的是代码是干净的，易于阅读，因此易于更改。
     

2. 敏捷原则

   敏捷宣言的背后有十二项原则。这些原则体现了价值观，并在更低的层面上提供了更具体的敏捷含义示例。

   1. 我们最优先考虑的是通过早期和持续交付有价值的软件来满足客户。

      

   2. 欢迎变化的需求，即使是在开发后期。敏捷流程利用变化来为客户带来竞争优势。

      

   3. 频繁交付可工作的软件，周期从几周到几个月不等，倾向于较短的周期。

      

   4. 在整个项目期间，业务人员和开发人员必须一同工作。

      

   5. 围绕积极主动的个人建立项目。给他们所需的环境和支持，并信任他们能够完成工作。

      

   6. 向开发团队以及团队内部传递信息最有效的方法是面对面交谈。

      

   7. 可工作的软件是衡量进展的主要标志。

      

   8. 敏捷流程促进可持续发展。赞助商、开发人员和用户应该能够长期保持稳定的步伐。

      

   9. 持续关注技术卓越和良好设计可以增强敏捷性。

      

   10. 简洁——最大化未完成工作量的艺术——至关重要。

       

   11. 最佳的体系结构、需求和设计源于自组织的团队。

       

   12. 团队定期反思如何提高效率，然后相应地调整其行为。

       

3. 敏捷方法论

   敏捷方法论是支持敏捷价值观和原则的方法。
   最受欢迎的敏捷方法论是（XP、Scrum、ASD、Crystal、DSDM 和 FDD），并且已被全球越来越多的组织采用。

   如何选择敏捷方法论

   敏捷不局限于一种特定的方法论。你需要为你的组织决定合适的方法论，因为有些方法论不适合你的文化、你的团队、你的市场或你的工具。如果选择的方法论不起作用，你需要更换另一种。此外，你还可以构建自己的敏捷方法论，并根据敏捷价值观和原则随着时间的推移进行改进。

   
   正如你在上面的信息图中看到的，敏捷伞下有很多方法论。它们之间的主要区别在于需要遵循的规则数量，例如 Scrum（9 条规则）、XP（13 条规则）、Kanban（3 条规则）。
   请注意，遵循的规则越少，适应性越强。

传统的软件开发

传统的软件开发方法，更准确地称为瀑布模型，是一种线性的（顺序的）软件开发方法。

瀑布模型在软件开发中一直很普遍，Dr. Winston W. Royce（1970 年）是早期描述瀑布模型的人之一。

瀑布模型具有明显的吸引力。它提供了一个易于理解的过程，并且似乎遵循逻辑顺序（分析 -> 设计 -> 编码 -> ..等）。此外，它是一个熟悉的过程，因为它类似于我们构建其他事物的方式，例如建筑物和汽车。阶段检查点提供了风险管理的一种形式，因为在未经前一阶段授权的情况下，过程无法进入下一步。

瀑布模型的主要问题是，直到项目结束才能获得任何价值，直到最后才进行测试，并且直到最后一天才征求利益相关者的批准。这种方法风险很高、成本高且效率低下。

敏捷与传统软件开发（瀑布模型）的对比

• 瀑布模型采用顺序设计过程。开发从起点到终点顺序流动，包含几个不同的阶段（分析、设计等）。相比之下，敏捷方法提出了一种增量和迭代的软件设计方法。它基本上是作为对瀑布模型局限性的回应而开发的，设计过程被分解成称为“冲刺”的独立模型。

  

• 在瀑布模型中，客户直到项目结束才能获得任何价值，但在敏捷开发中，客户反馈与开发同时发生。

  

• 在敏捷开发中，开发人员和业务部门之间有更紧密的协作，而这是瀑布模型所缺失的。

  

• 瀑布模型项目的变更成本相对较高。相比之下，在敏捷开发中，需求变更可以在流程的任何阶段纳入——即使在开发后期，成本也会更低。

  

• 瀑布模型项目的交付风险相对较高，因为它直到开发周期接近尾声才会交给客户。相比之下，使用敏捷开发可以持续交付可工作的软件，从而降低交付风险。

  

敏捷的优势

• 客户满意度：通过快速、持续交付有用的软件。
• 极佳的沟通：客户、开发人员和测试人员之间不断互动。
• 上市速度：频繁交付可工作的软件（以周为单位，而非月）。
• 更愉快的体验：业务人员与开发人员之间的日常合作，使敏捷开发团队成为大多数人更愉快的协作场所。
• 提高质量：持续关注技术卓越和良好设计。
• 灵活性：定期适应不断变化的环境。
• 更多透明度和更好的可见性：在整个软件开发过程中，能够了解进展情况。同时，始终保持沟通，让客户了解情况，以便每个人都知道我们在流程中的位置。
• 提高生产力和高客户满意度：我们知道客户在看到之前常常不知道自己想要什么。我们可以更早地向他们展示东西，并与他们沟通和交流。他们可以给我们反馈，告诉我们这是否真的是他们想要的。这有助于提高生产力和更好的质量。
• 降低风险：降低项目失败的风险。

敏捷的缺点

• 需要客户的可用性和合作
• 需要客户有清晰的愿景（如果客户代表不清楚他们想要的最终结果，项目很容易偏离轨道）。
• 只有有经验的程序员才能在开发过程中做出所需的决策。因此，它不适合新手程序员，除非与有经验的资源结合。
• 很难量化交付项目的总工作量和成本。

敏捷的应用

• 有紧迫截止日期的项目
• 高度复杂性的项目
• 高度新颖性的项目（当我们正在做一些新的事情，或者至少对构建它的团队来说是新的事情）
• 需求不明确的项目，可能需要大量更改才能实现。

敏捷的障碍

• 区分“做敏捷”和“是敏捷”
  很多时候，当一个组织尝试做敏捷时。他们会有一个待办事项清单，列出你应该做的事情。所以他们是在“做敏捷”，而不是“是敏捷”。“是敏捷”意味着基于敏捷原则思考。而“做敏捷”意味着遵循一种敏捷方法，如 Scrum、Kanban、Lean 等。
• 人们一起工作
  如何让你的团队成员一起工作。例如，在传统的软件开发过程中，有两个团队（开发人员和测试人员）是分开的，他们不知道如何一起工作。因此，组织将努力教他们如何一起工作，如果他们坐在一起会做什么，以及他们将如何工作。因为敏捷的整个思想是让每个人都一起工作，在软件中构建质量，而不是试图测试、修复、重新测试、修复、重新测试、修复。

关注点

请注意，如果一切正常，请不要转向敏捷。你应该将敏捷作为一种改进的方式，如果你真的觉得你的组织在某些方面未能向市场交付所需的东西，那么你才考虑敏捷。如果你没有这些问题，就不要转向新东西。改变是困难的。（Jeff Payne）

敏捷也许不完美，但它优于其他替代方案

参考文献

• Wikipedia
• 敏捷方法论
• 敏捷联盟
• 敏捷宣言
• 敏捷精华
• 什么是敏捷开发
• 敏捷森林
• AMIS 技术博客
• 敏捷基础：与 Jeff Payne 的访谈

历史

• 2015/12/17 文章已添加。