软件流程和管理（二）：SDLCs — Agile

流程和管理（二）：SDLCs — Agile"/>

软件流程和管理（二）：SDLCs — Agile

目录

1. 理解Agile

1.1 Agile为什么有吸引力

1.2 什么是Agile

1.3 Agile的起源

1.4 敏捷模型的各个阶段

2. Agile框架

2.1 Manifesto 宣言

2.2 12 Key Principles 十二条宣言

2.3 Kanban 看板

2.4 Scrum

3. 了解Scrum——角色、仪式和工件。

3.1 Scrum的主要特点

3.2 Scrum Framework - Sprints

3.3 Scrum Framework - Framework

3.4 Scrum Roles

3.4.1 Product Owner

3.4.2 Scrum Master

3.4.3 The Scrum Team

3.5 Scrum Ceremonies / Meetings

3.5.1 Sprint Planning

3.5.2 Daily Stand-up

3.5.3 Sprint Reviews - Showcase

3.5.4 Sprint Retrospective

3.6 Scrum Artefacts

3.6.1 Product Backlog

3.6.2 Sprint Backlog / User Story

3.6.3 Burn Down Chart

4. 了解敏捷的优势/劣势

4.1 什么时候使用敏捷模式？

4.2 优势

4.3 缺点

4.4 如何选择Formal或Agile

---

1. 理解Agile

Agile的意思是迅速或多变。“Agile process model”是指一种基于迭代开发的软件开发方法。Agile方法将任务分解成更小的迭代，或部分不直接涉及长期规划。项目的范围和要求在开发过程的开始就已经确定了。关于迭代的数量、持续时间和每个迭代的范围的计划都是事先明确定义的。

在Agile process model中，每个迭代被认为是一个很短的时间“框架”，通常持续1到4周。将整个项目划分为较小的部分，有助于将项目风险降到最低，并减少整个项目的交付时间要求。每个迭代涉及一个团队通过完整的软件开发生命周期工作，包括规划、需求分析、设计、编码和测试，然后向客户展示一个工作产品。

1.1 Agile为什么有吸引力

• 我们处在一个不断变化的全球世界中，变化的速度越来越快
• 客户的需求和要求呈指数级增长——产品必须持续交付
• 技术成本低，易于使用，全球市场的竞争加剧，进入门槛降低
• 人才争夺战已经结束——而我们已经输了！跨职能团队有助于最大限度地减少潜在的损失
• 漫长的开发周期就像漫长的午餐，已经成为过去。
• 质量不再是我们所做的事情（事后检查）——它必须是我们所做的一切的一部分
• 跨职能小组更有趣

1.2 什么是Agile

• 一个基于迭代开发的框架，通过自我组织的跨职能团队之间的合作，需求和解决方案不断发展
• 一个鼓励频繁检查和调整的有纪律的流程
• 一种鼓励团队合作、自我组织和问责制的领导理念
• 一套旨在快速交付高质量软件的工程最佳实践
• 一种使开发与客户需求和公司目标相一致的商业方法

• 在软件开发中，我们考虑的是方法论、活动、互动、结果、工作产品、人工制品和组织工作的过程。

无论使用何种方法论，软件开发的主要任务都是一样的，但是在Agile中，活动的流程、活动的方式以及参与的人员都是极其不同的。

1.3 Agile的起源

• 20世纪90年代在美国大型企业中开始的变革
• 软件工程师对
  • 产品交付前的漫长准备时间感到沮丧
  • 在项目早期做出的决定后来无法改变感到沮丧
• 2000年，17位软件工程师思想领袖首次会面，讨论软件工程和不同方法
• 2001年，在Snowbird ski lodge in Utah举行了著名的会议，他们在那里开会，以改变行业设计、工程和部署软件的方式
• 敏捷宣言将他们聚集在一起

1.4 敏捷模型的各个阶段

Following are the phases in the Agile model are as follows:

1. Requirements gathering
2. Design the requirements
3. Construction/ iteration
4. Testing/ Quality assurance
5. Deployment
6. Feedback

1. Requirements gathering 需求收集

在这个阶段，你必须定义需求。你应该解释商业机会，并计划建立项目所需的时间和精力。根据这些信息，你可以评估技术和经济可行性。

2. Design the requirements 设计需求

当你确定了项目后，与利益相关者一起工作来定义需求。你可以使用用户流图或高级UML图来显示新功能的工作，并显示它将如何应用于你现有的系统。

3. Construction/ iteration 建设/迭代

当团队定义了需求，工作就开始了。设计师和开发人员开始在他们的项目上工作，其目的是部署一个工作产品。该产品将经历各个阶段的改进，因此它包括简单的、最小的功能。

4. Testing/ Quality assurance 测试

在这个阶段，质量保证团队检查产品的性能并寻找错误。

5. Deployment 部署

在这个阶段，团队为用户的工作环境发布产品。

6. Feedback 反馈

发布产品后，最后一步是反馈。在这个阶段，团队会收到关于产品的反馈，并通过反馈进行工作。

2. Agile框架

敏捷框架的主要内容包括：

• Manifesto（宣言）
• 12 Key Principles（12条关键原则）
• Kanban（看板）
• Scrum

2.1 Manifesto 宣言

我们正在探索更好的开发软件的方法，通过这样做，并帮助其他人这样做。通过这项工作，我们得出了以下价值：

1. Individuals and interactions over processes and tools 个人和互动高于流程和工具
2. Working software over comprehensive documentation 可工作软件高于全面的文件
3. Customer collaboration over contract negotiation 客户合作高于合同谈判
4. Responding to change over following a plan 应对变化而不是遵循计划

也就是说，虽然右边的项目有价值，但我们更重视左边的项目。

2.2 12 Key Principles 十二条宣言

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 我们的首要任务是通过早期和持续交付有价值的软件来满足客户。

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 欢迎不断变化的需求，甚至在开发后期。敏捷的流程为客户的竞争优势驾驭变化。

Deliver working software frequently, from a couple of weeks to a couple of months, shorter timeframes is the preference. 经常交付工作软件，从几周到几个月，更短的时间框架是首选。

Business people and developers must work together daily throughout the project. 业务人员和开发人员必须在整个项目中每天一起工作。

Build projects around motivated individuals. Give them the environment and support they need and trust them. 围绕积极的个人建立项目。给他们需要的环境和支持，并信任他们。

The most efficient and effective method of conveying information to and within a development team is face-to-face. 向开发团队传达信息以及在开发团队内部传达信息的最有效方法是面对面的交流。

Working software is the primary measure of progress. 可工作软件是衡量进展的主要标准。

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 敏捷过程促进可持续发展。赞助商、开发者和用户应该能够无限期地保持恒定的速度。

Continuous attention to technical excellence and good design enhances agility. 持续关注技术的卓越性和良好的设计可以增强敏捷性。

Simplicity - the art of maximizing the amount of work not done - is essential. 简化——最大限度地减少未完成的工作的艺术——是至关重要的。

The best architectures, requirements, and designs emerge from self-organising teams. 最好的架构、需求和设计产生于自组织的团队。

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 每隔一段时间，团队就会反思如何变得更有效，然后相应地调整其行为。

2.3 Kanban 看板

Signboard / Billboard 看板/广告牌：

工作项目是可视化的，通常通过看板为参与者提供一个从开始到结束的进度和流程。

可视化的进展为自我组织的团队提供了透明度/责任感，通常被称为SWIMLANE板

2.4 Scrum

Scrum是一种管理项目的敏捷方式

Scrum是一个框架，在这个框架内，人们可以解决复杂的适应性问题，同时富有成效地、创造性地交付尽可能高价值的产品。

简而言之，Scrum要求Scrum Master培养一种环境，在这种环境中：

• 产品负责人将一个复杂问题的工作安排到一个Product Backlog中。
• Scrum团队在一个Sprint期间将选择的工作变成价值增量。
• Scrum团队和其利益相关者检查结果，并为下一个Sprint进行调整。
• 重复进行

3. 了解Scrum——角色、仪式和工件。

• Scrum是一个敏捷的过程，使我们能够专注于在最短的时间内交付最高的商业价值。
• 它使我们能够快速、反复地检查实际工作的软件（每两到四周一次）。
• 企业设定优先级。团队自我组织，以确定交付最高优先级功能的最佳方式。
• 每隔两到四周，你就可以看到真正的可工作的软件，并决定按原样发布或再进行一次冲刺继续增强它。

3.1 Scrum的主要特点

• Self-organising teams 自我组织的团队
• Product progresses in a series of focused sprints 产品在一系列集中的冲刺中进行开发
• Requirements are captured as items in a list of product backlog 需求被捕捉为 product backlog 列表中的项目
• Scrum is one of the agile processes – the one most widely used, discussed and debated Scrum是敏捷流程之一——是使用最广泛、讨论和辩论最多的流程
• Time frame is contained to a manageable size (weeks or months) 时间框架被控制在可管理的范围内（周或月）

3.2 Scrum Framework - Sprints

3.3 Scrum Framework - Framework

The Scrum Team

Scrum的基本单位是一个由人组成的小团队，即Scrum团队。Scrum团队由一名Scrum主管、一名产品负责人和开发人员组成。在Scrum团队中，没有子团队或等级制度。它是一个由专业人员组成的有凝聚力的单位，每次都集中在一个目标上，即产品目标。

The Scrum Events

Scrum中使用规定的事件来创造规律性，并尽量减少对Scrum中未定义的会议的需求。所有的事件都有时间限制。一旦一个Sprint开始，其持续时间是固定的，不能被缩短或延长。其余的事件只要达到目的就可以结束，以确保在这个过程中花费适当的时间，不允许浪费。

Scrum Artifacts

Scrum的Artifacts代表了工作或价值，以提供透明度以及检查和调整的机会。Scrum定义的Artifacts是专门为最大限度地提高关键信息的透明度而设计的，以便每个人对Artifacts有相同的理解。

3.4 Scrum Roles

3.4.1 Product Owner

• Defines the features of the product 确定产品的特点
• Decides on release date and content 决定发布日期和内容
• Is responsible for the Benefits / Profitability of the product (ROI) 负责产品的效益/利润率（ROI）
• Prioritises features according to market value 根据市场价值对功能进行优先排序
• Adjusts features and priority every iteration, as needed 根据需要，在每次迭代中调整功能和优先级
• Accepts or reject work results 接受或拒绝工作成果

3.4.2 Scrum Master

• Represents management to the project 在项目中代表管理层
• Responsible for enacting Scrum values and practices 负责制定Scrum的价值观和实践
• Removes impediments / road blocks 排除障碍/路障
• Ensures that the team is fully functional and productive 确保团队充分运作并富有成效
• Enables close cooperation across all roles 促进所有角色之间的紧密合作
• Shields the team from external interferences 保护团队不受外界干扰
• Is a member & active participant of the Scrum Team 是Scrum团队的成员和积极参与者

3.4.3 The Scrum Team

• Typically 6 - 9 people 通常为6-9人
• Cross-functional 跨职能的：
  • Programmers, testers, user experience designers, business representatives etc. 程序员、测试员、用户体验设计师、业务代表等
• Members should be full-time – some exceptions 成员应该是全职的，但也有例外
• Co-located (physically or virtually) 同地办公（物理或虚拟）

3.5 Scrum Ceremonies / Meetings

3.5.1 Sprint Planning

• Defines how to achieve sprint goal (design) 定义如何实现冲刺目标（设计）
• Create sprint backlog (User Stories) from product backlog 从product backlog中创建sprint backlog（用户故事）
• Estimate sprint backlog in team velocity and Story Points 以团队速度和故事点来估计冲刺积压的内容
• Product Owner priority guides the work 产品负责人优先指导工作
• Release Plan is created 创建发布计划
• High-level design is considered 考虑高层次的设计

会议的前半部分

• 团队确定在这个冲刺阶段可以做什么
• 首先写下Sprint的目标
• 从积压项目中找出能够实现这一目标的项目

会议的后半部分

• 团队找出工作的完成方式
• 在sprint backlog中分解每个（功能）用户故事/大型用户故事，以捕捉所有需要的工作（故事点）。
• 用户故事构成冲刺计划的基础，用于跟踪、成本和管理进度

3.5.2 Daily Stand-up

Parameters 参数

• Daily
• 15-minutes and no more than 30 mins
• Stand-up

不是用来解决问题的/不是一个状态会议

• 所有人都被邀请
• 只有团队成员、ScrumMaster、产品负责人可以澄清用户故事的任何问题

有助于避免其他不必要的会议

提出3个关键问题：

• 我昨天做了什么。
• 我今天要做什么。
• 有什么阻碍我完成工作。

3.5.3 Sprint Reviews - Showcase

• 团队展示其在冲刺期间所完成的工作
• 通常采取新功能或基础架构的演示形式
• 非正式的
• 2小时准备时间规则
• 没有幻灯片
• 整个团队参与
• 邀请所有人

3.5.4 Sprint Retrospective

• 定期检查哪些是有效的，哪些是无效的
• 通常是30分钟
• 每次冲刺后进行
• 整个团队都要参与。
  • ScrumMaster和团队
• 可能是产品负责人、客户和其他人（但一般不是）
• 讨论要做什么。
  • 开始做什么，停止做什么，继续做什么

3.6 Scrum Artefacts

3.6.1 Product Backlog

用户故事

• 用户故事是从系统的终端用户/客户的角度来表达的一个需求。
• 用户故事将重点从写需求转移到谈论需求上。
• 用户故事是对一个功能的简短描述，从客户的角度出发，讲述系统的新功能。它们遵循一个简单的模板：
  • As a < type of user >, I want < some goal > so that < some reason >
• 用户故事是在不同的细节水平上写的。
• 他们可以涵盖大量的功能，如这个来自专业会员网站的例子。
  • As a site visitor, I want to get all information associated with my professional membership, so that I have access to all information centrally.
• 因为这个级别的细节对于一个敏捷团队来说过于庞大，无法在一次迭代中完成，所以有时会在工作前将其拆分为更小的用户故事
•  Feature or epic user story

故事点

• 故事点是一种衡量单位，用于表达对全面实施product backlog项目或任何其他工作所需的总体努力的估计。
• 故事点有助于估计在一个冲刺阶段可以完成多少工作。
• 当用故事点进行估算时，每个项目都会被分配一个值。
• 原始值并不重要，重要的是相对值。
• 一个被分配为2的故事应该是被分配为1的故事的两倍。它也应该是被估计为3的故事点的三分之二。
• 该团队可以不分配1、2和3，而分配100、200和300，或者100万、200万和300万。重要的是比例，而不是实际数字。

• 需求
• 项目中所有期望的工作的清单 
• 理想的表达方式是，每个项目对产品的用户或客户都有价值。
• Product Backlog User Stories 是由Product Owner为一个Sprint选择的 
• 在每个冲刺开始时重新确定优先次序

例子 - 专业机构网站

News Section – Sprint 1

• User Story 1 - As a site visitor, I can read current news on the home page so that I stay current on key professional items 1 Story Points
• User Story 2 - As a site visitor, I can email news items to the editor so that they can be considered for publication 2 Story Points
•  User Story 3 - As a site member, I can subscribe to an RSS feed of news so that I can stay current on the news that is of interest to me 3 Story Points

Courses and Events – Sprint 2

• User Story 4 - As a site visitor, I can see a sorted list by date of all upcoming “Certification Courses” so that I can choose the best course for me 2 Story Points
• User Story 5 - As a site visitor, I can see a list of all upcoming “Other Courses” (noncertification courses) so that I can choose the best course for me 5 Story Points
• User Story 6 - As a site visitor, I can see a list of all upcoming “Social/Networking Events.” so that I can select ones I am able to attend 1 Story Points

To complete this total Product Backlog would take 14 Story Points

3.6.2 Sprint Backlog / User Story

• Scrum团队在Sprint计划期间将用户故事分解为低级别的用户故事。
• 用户故事被用于SME和开发者之间的对话。开发者用任务和工时估计来更新用户故事，"Just-In-Time"。
• 剩余的估计项目每天都会更新
• Sprint Backlog很少被改变。
• 在冲刺阶段的用户故事要么100%完成，要么不完成。

3.6.3 Burn Down Chart

• 燃烧图是一个剩余工作与时间的图形表示。
• 未完成的工作（或积压的用户故事）通常在纵轴上，时间在横轴上。
• 它被用来预测所有的工作将在何时完成。

4. 了解敏捷的优势/劣势

4.1 什么时候使用敏捷模式？

• When frequent changes are required. 当需要频繁改变时。
• When a highly qualified and experienced team is available. 当一个高素质和有经验的团队可用时。
• When a customer is ready to have a meeting with a software team all the time. 当客户准备好一直和软件团队开会的时候。
• When project size is small. 当项目规模较小时。

4.2 优势

• Customer satisfaction by rapid, continuous delivery of usable software 通过快速、持续地交付可用的软件来满足客户需求
• People and interactions are emphasised rather than process and tools 强调人与人之间的互动，而不是强调过程和工具
• Continuous attention to technical excellence, good design and quality 持续关注卓越的技术、良好的设计和质量
• Regular adaptation to changing circumstances 定期调整以适应不断变化的环境
• Frequent Delivery 频繁交货
• Face-to-Face Communication with clients. 与客户面对面的沟通。
• Efficient design and fulfils the business requirement. 高效的设计和满足业务要求。
• Anytime changes are acceptable. 任何时候的改变都是可以接受的。
• It reduces total development time. 它减少了总的开发时间。

4.3 缺点

• Difficult to assess the effort required at the beginning 在开始时很难评估所需的努力
• Can be very demanding (from traditional approaches) on users time 可能对用户的时间要求很高（从传统方法来看）。
• Harder for new starters to integrate into the team 新手较难融入团队
• Agile is a very different approach – It can be intense for the team 敏捷是一种非常不同的方法--它对团队来说可能很紧张
• Requires experienced resources (which are limited in today’s market) 需要有经验的资源（这在今天的市场上是有限的）
• Due to the shortage of formal documents, it creates confusion and crucial decisions taken throughout various phases can be misinterpreted at any time by different team members. 由于缺少正式的文件，它造成了混乱，在各个阶段作出的关键决定可能随时被不同的团队成员误解。
• Due to the lack of proper documentation, once the project completes and the developers allotted to another project, maintenance of the finished project can become a difficulty. 由于缺乏适当的文件，一旦项目完成，开发人员被分配到另一个项目，对已完成项目的维护就会成为一个困难。

4.4 如何选择Formal或Agile

没有一个正确的答案。下面的问题可以帮助我们做出决定。

• 需求的稳定性如何？
• 终端用户是否需要合作？
• 时间线是积极的还是保守的？
• 项目的规模是多少？
• 项目团队在哪里？
• 什么是关键资源？