敏捷项目管理基础笔记分享

1.敏捷项目管理基础

1.1 项目管理和迭代开发方式项目的定义：一系列活动，有一个明确的目标或目的，并且必须在特定的时间和预算内依据规范完成

项目管理：运用技能，方法与工具，为满足或超越项目有关各方对项目的要求与期望，所开展的各种计划，组织，领导控制等方面的活动。

项目的三角：

• 范围：要求做什么，也规定了不能做什么
• 时间：必须完成的时间框架或最后期限
• 成本：可用于项目的费用

• 质量：
  • 产品的质量：项目的可交付成果的质量
  • 过程的质量：项目管理过程本身的质量

项目管理的目的：在有限的资源投入条件下，在要求的时间内完成既定的项目目标。

迭代开发模式

迭代式开发也被称作迭代增量式开发或迭代进化式开发，是一种与传统的瀑布式开发相反的软件开发过程，它弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率。

在迭代式开发方法中，整个开发工作被组织为一系列的短小的、固定长度的小项目，被称为一系列的迭代。

每次迭代都包括了定义、需求分析、设计、实现与测试。采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成 系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求，并开始新一轮的迭代。

1.2 Scrum方法——3 3 3 5

Scrum是一种敏捷项目管理框架，用于开发和维护复杂产品，是一个增量的、迭代的开发过程。以下是其详细介绍：

历史起源

Scrum的原始含义是指英式橄榄球次要犯规时在犯规地点对阵争球。1986年，竹内弘高和野中郁次郎在《New New Product Development Game》文章首次提到将Scrum应用于产品开发。1993年，Jeff Sutherland首次将Scrum用于软件开发。1995年，Jeff Sutherland和Ken Schwaber规范化了Scrum框架，并在OOPSLA 95上公开发布。2001年，敏捷宣言及原则发布、敏捷联盟成立，Scrum是其中一种敏捷方法。

角色

• 产品负责人（Product Owner）：负责将Scrum团队的工作所产生的产品价值最大化，对Product Backlog进行有效管理，包括开发并明确地沟通Product Goal，创建并清晰地沟通Product Backlog条目，对Product Backlog条目进行排序，确保Product Backlog是透明的、可见的和可理解的。
• Scrum Master：负责按照Scrum指南的游戏规则来建立Scrum，通过帮助Scrum团队和组织内的每个人理解Scrum理论和实践来做到这一点，对Scrum团队的效能负责，通过让Scrum团队在Scrum框架内改进其实践来提升效能。
• 开发团队（Developers）：由测试人员、设计人员、UX专家、运营工程师和开发人员组成，团队成员拥有不同的技能组合，并相互交叉培训，负责协同工作以确保成功完成Sprint，倡导可持续发展实践，自我组织并以明确的态度对待他们的项目，推动规划和评估他们在每个Sprint中可以完成的工作量。

工件

• 产品待办事项列表（Product Backlog）：是一份涌现的和有序的清单，列出了改进产品所需的内容，是Scrum团队所承担工作的唯一来源，能够被Scrum团队在一个Sprint中完成的Product Backlog条目被认为准备就绪，在Sprint Planning事件中可供选择。
• Sprint待办事项列表（Sprint Backlog）：由Sprint Goal、为Sprint选择的Product Backlog条目以及交付Increment的可执行计划组成，是Developers为其制定的计划，是一个高度可视且实时的工作画面，随着学到更多，Sprint Backlog在整个Sprint期间会进行更新。
• 产品增量（Increment）：是迈向Product Goal的一块坚实垫脚石，每个Increment都是之前所有的Increment累加起来的，并经过彻底地验证，以确保整合在一起的所有Increment都能工作，为了提供价值，Increment必须是可用的。

事件

• Sprint：是Scrum的核心，是固定时长的事件，为期一个月或更短，前一个Sprint结束后，下一个新的Sprint紧接着立即开始，实现Product Goal所需的所有工作，包括Sprint Planning、Daily Scrum、Sprint Review和Sprint Retrospective，都发生在Sprint内。
• Sprint Planning：通过安排在Sprint中要做的工作来启动Sprint，最终的计划是由整个Scrum团队协作创建的，处理为什么这次Sprint有价值、这次Sprint能完成什么、如何完成所选的工作等话题。
• Daily Scrum：目的是检视达成Sprint Goal的进展，并根据需要调整适应Sprint Backlog，以调整即将进行的计划工作，是一个属于Scrum团队的Developers的15分钟的事件，在Sprint的每个工作日都在同一时间同一地点举行。
• Sprint Review：在Sprint结束时，团队聚在一起开一个非正式的会议，回顾已经完成的工作，并向利益相关者展示，产品负责人也可能基于当前的Sprint将Product Backlog返工。
• Sprint Retrospective：团队聚在一起记录和讨论在Sprint过程中什么可行，什么不可行，产生的想法用于改进未来的Sprint。

价值观

• 承诺：愿意对目标做出承诺。
• 专注：把心思和能力都用到承诺的工作上去。
• 开放：将项目中的一切开放给每个人看。
• 尊重：每个人都有其独特的背景和经验，要相互尊重。
• 勇气：有勇气做出承诺，履行承诺，接受别人的尊重。

优势

• 及时响应变化：通过持续沟通和反馈得出客户需求，其高适应性的特点，可以在短时间内实现产品迭代，更好地响应客户需求，适应市场变化。
• 提高项目进展透明度：简化工作流程，在每次Scrum框架模式的会议上，项目经理可以提前知晓项目可能存在的问题或风险，提前做好风控准备，并且团队成员之间可以彼此了解大家的工作情况以及遇到的问题。
• 增加团队协作：成员之间可以及时了解每次迭代规划上的内容，彼此间互相合作，并及时改善协作间出现的问题，增加团队协作性。
• 降低风险、节省成本：在Scrum框架模式的每一次会议下，产品经理、Scrum团队、利益方保持沟通，可以尽早发现问题所在并及时作出调整，从而帮助降低开支并提高产品交付质量，快速应对市场。

1.3 KANBAN方法

看板：一种可视化流程管理系统

三个原则：可视化，限制在制品，管理流动

五个核心实践：

• 可视化工作流（价值流）：工作流程，由各种工作项构成
• 限制在制品数量：工作项在本状态数量的上限，取决与整体团队的能力
• 度量与管理流动：让价值流动起来，方法：累计流量图
• 协同改进：整个团队一起合作
• 显示化流程规则：不同状态转换的规则

Scrum方法还是KANBAN方法都是为了顺畅，高质量地交付有用的价值

1.4 风险管理 风险管理规划是指决定如何处理并进行项目的风险管理活动

四个阶段:

1.风险识别

2.风险分析

3.风险应对计划

4.风险监控和控制

2. 需求管理与版本规划

2.1需求收集与分析：

需求的定义: IEEE软件工程标准词汇表(97年)中定义需求为:

➢用户解决问题或达到目标所需的条件或权能(Capability).

➢系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。

➢一种反映上面(1)或(2)所描述的条件或权能的文档说明。

软件需求包括以下几个层次:

➢业务需求

➢用户需求

➢功能需求

➢非功能需求、软件需求规格说明等

2.2需求管理流程： 需求收集–>需求分析–>需求分解与澄清–>需求优先级与排期

2.2.1需求收集：

• 原始需求–>用户需求

• 需求获取的方法： 文档与数据，访谈，调查问卷，原型，需求讨论会，竞品分析

2.2.2需求分析：

• 用户需求–>产品需求

• 针对待开发软件提供完整，清晰，具体的要求，确定软件必须实现哪些任务

• 工具：影响地图：why who how what

2.2.3基于用户故事的拆分与澄清：

需求层级：

• Epic Story史诗故事：产品的主干任务，非常大

• Feature特性：描述了产品的具有一个完整的功能，特性也比较大，持续数周，横跨几个迭代

• 用户故事：特性一般可以拆分为多个用户故事，每个用户故事都对用户有价值。但是单个用户故事却可能不能被正常使用或者是整个功能的细分场景

• 三要素：角色，活动，价值

• 角色：谁使用这个功能

• 活动：需要完成什么样的功能

• 商业价值：能带来什么样的价值

• 格式：AS a，I want ，so that | 作为一个<角色>，我想要<活动>，以便于<商业价值>

3C原则：

• 卡片（Card）:用户故事写在小的记事卡片上

• 交谈（Conversation）：用户故事背后的细节来源于和客户或者产品负责人的交流沟通

• 确认（Confirmation）：验收测试确认用户故事被正确完成