敏捷项目管理学习
目录：
7、敏捷项目管理方法：XP、ASD、FDD、TDD、Crystal、DSDM、AUP
10、Product Backlog和Sprint Backlog
14、Scrum主管的主要工作、与产品负责人工作的区别、两个角色是否可以由一人承担
22、传统项目管理的五大过程组和十大知识领域（5个 + 10个）
备注：本文将以一个项目实例——PlantSCM（Plant Supply Chain Management，工厂供应链管理系统），作为本文中部分示例图的来源。该项目需求简介如下图1所示：
1、敏捷工作实践的过程（5个）
- 定义产品愿景和产品路线图
- 计划发布与冲刺
- 细化需求和估算
- 创建用户故事
- 创建Product Backlog
- 发布计划
- 冲刺：冲刺计划会议、创建Sprint Backlog、 燃尽初始图、冲刺计划
- 全天的工作
- 计划每天的工作，活动：每日例会
- 跟踪每天的进展，工具：燃尽图，任务板
- 开发并测试每天的工作
- PO和开发团队的活动：细化、开发、验证
- 开发活动：完成标准、结对编程、持续集成、测试驱动开发
- 验证活动：自动化测试、同行评审、PO评审
- Scrum Master的活动：识别障碍、解决问题
- PO和开发团队的活动：细化、开发、验证
- 结束一天的工作，更新、调整Sprint Backlog、燃尽图、任务板等
- 展示工作和集成反馈：冲刺评审会议、冲刺回顾会议
- 冲刺评审会议：展示工作 + 收集反馈
- 冲刺回顾会议：评审冲刺 + 改进流程
- 为发布做准备
- 发布迭代：准备部署产品
- 内部准备：组织为产品发布做好准备
- 外部准备：市场为产品发布做好准备
2、敏捷宣言（4个）
- 如图2所示，主要包括：
- 个体和交互胜过过程和工具
- 可用软件胜过完备文档
- 客户协作胜过合同谈判
- 响应变化胜过遵循计划
3、敏捷开发原则（12个）
- 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意
- 即使到了开发的后期，也欢迎改变需求
- 经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好
- 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作
- 项目由有激情的、值得信任的个体合作完成
- 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈
- 工作的软件是首要的进度度量标准
- 敏捷过程提倡平稳的开发节奏；发起人、开发者和用户应该能够保持一个长期的、恒定的开发速度
- 不断地关注优秀的技术和好的设计可以增强敏捷能力
- 简单化是根本（不做过度设计和预测）
- 最好的构架、需求和设计是来源于自组织的团队
- 每隔一定时间，团队会在如何才能更有效地工作方面进行反思，并对自己的行为进行相应调整
4、敏捷开发核心思想
- 以人为本，适应变化
5、Scrum敏捷开发框架
- 优先开发高优先级需求，在每个迭代结束后，都会开发完成可交付的产品
- Scurm过程（如图3所示，重复以下过程，直至项目完成）：
- 产品负责人根据价值和工作量，确定需求优先级，并创建Product Backlog
- 创建Sprint Backlog
- 团队每日例会
- 迭代结束，产生潜在可交付的产品增量
- 冲刺评审会议和冲刺回顾会议
6、敏捷的角色、工件、仪式
- 敏捷角色（Scrum Roles）：
- Scrum主管（Scrum Master）
- 产品负责人（Product Owner）
- 开发团队（Scrum Team）
- 干系人（Stakeholder）
- 敏捷导师（Agile Mentor）
- 敏捷工件（Scrum Artifacts）：
- 产品待办列表（Product Backlog）
- 冲刺待办列表（Sprint Backlog）
- 产品增量（Product Increment）
- 燃尽图（Burndown Chart）
- 敏捷仪式（Scrum Ceremonies）：
- 冲刺计划会议（Sprint Planning Session）
- 每日例会（Daily Scrum）
- 冲刺评审会议（Sprint Reviews）
- 冲刺回顾会议（Sprint Retrospectives）
7、敏捷项目管理方法：XP、ASD、FDD、TDD、Crystal、DSDM、AUP
- XP：eXtreme Programming的缩写，极限编程开发方法
- 轻量级，适用于需求快速变动场景，要求客户与开发人员最好以side-by-side方式工作
- 目标：降低因需求变更而带来的成本
- 特征：
- 增量和反复式的改进和改进
- 结对编程
- 测试驱动开发
- 简单设计
- 反馈
- 隐喻来组织系统
- 可持续的速度
- 四大价值观：
- 沟通
- 简单
- 反馈
- 勇气
- ASD：Adaptive Software Development的缩写，自适应软件开发方法
- 强调开发方法的适应性，从更高的组织和管理层次阐述开发方法为什么要具备适应性
- 目标：更具迭代性和更短间隔
- 特征：
- 专注于最终用户
- 准时交付
- 鼓励开发团队和客户之间提高透明度
- FDD：Feature Driven Development的缩写，特征驱动开发方法
- 特征驱动，模型驱动，适用于需求经常变更、中小型软件开发项目的开发模式，强调简化、实用；
- 目标：快速迭代
- 特征：
- 开发全局模型（Develop an Overall Model）
- 建立特征列表（Build Feature List）
- 依据特征规划（Plan By Feature）
- 依据特征设计（Design By Feature）
- 依据特征构建（Build By Feature）
- TDD：Test Driven Development的缩写，测试驱动开发方法，如图4所示
- 测试作为编程中心，要求在编写代码前，首先编写单元测试用例，测试用例确定需要编写的功能代码，编写的功能代码要通过用例，并不断重构优化
- 目标：测试工作保证代码质量，帮助客户和开发团队去除模棱两可的需求
- 特征：
- 测试自动化运行
- 保证代码整洁可用，保证代码重构质量
- 及时重构，小步前进
- 提高代码可测试性
- Crystal：水晶族方法
- 灵活、执行不严格、全透明的工作方式，是个族系列，对不同类型的项目可以采用不同的实践方法
- 特征（七大体系特征）：
- 经常交付
- 反思改进
- 渗透式交流
- 个人安全
- 焦点
- 与专家用户建立方便的联系
- 配有自动测试、配置管理和经常集成功能的技术环境
- DSDM：Dynamical System Development Methodology的缩写，动态系统开发方法，如图5所示
- 倡导以业务为核心，适用于系统升级的二次开发，是一种控制框架，重点在于快速交付并补充如何应用这些控制的指导原则，已成为应用最为广泛地快速应用开发方法
- 目标：解决复杂项目管理流程
- 特征：
- 开发时间固定，功能划定和资源配置配合实际开发效果进行规划
- 重在利用原型设计
- AUP：Agile Unified Process的缩写，敏捷统一过程
- 轻量级RUP，可包容许多不同类型的过程
- 目的：快速构造可执行软件
- 特征：
- 全局串行
- 局部迭代
8、产品愿景声明和产品路线图
- 产品愿景声明（Product Vision Statement）：样例如图6所示
- 定义：确定组织未来或长远位置，以客户为导向，满足利益相关者的需求；确定产品目标和需求，与业务战略的关系是否一致
- 创建步骤：
- 设定产品目标
- 创建愿景声明的草案
- 与项目干系人共同确认愿景草案，并修改
- 确定愿景草案，描述项目开发原因和预期目标
- 产品路线图（Product Road Map）：样例如图7所示
- 定义：产品需求的综合提示图，是产品需求的概览，也是组织开发过程的工具
- 创建步骤：
- 分解产品需求
- 整理产品特性
- 估算产品特性：对需求价值和工作量打分，确定核心需求
- 计算相对优先级并排序
- 决定产品特性的时间框架：按照优先级排序，确定产品迭代时间增量，创建产品路线图
9、用户故事
- 定义：一种对某个产品需求的简单描述
- 用户故事卡片：
- 标题【名称】
- 作为【用户】或【角色】
- 我希望【行动】
- 以便【获得益处】
- 创建步骤：
- 识别项目干系人：专家、管理者、普通用户、技术用户等
- 识别客户：即使用该产品的人（角色），细分客户类型和特点
- 制作用户画像：描述识别的用户特点，样例如图8所示
- 创建用户故事： 样例如图9所示
- 确定产品需求
- 和干系人协作完成产品需求描述
- 编写用户故事卡片
- 优先级确定规则：
- 优先级 = 价值 / 工作量
- 价值打分：客户、PO、其他相关干系人
- 工作量打分：开发团队
- 风险越高，经济价值越高的功能，优先级越高
- 优先级 = 价值 / 工作量
10、Product Backlog和Sprint Backlog
- Product Backlog：确定了用户故事优先级的用户故事列表，样例如图10所示
- 如下图所示，表头主要包括：
- 用户故事编号、用户故事
- 优先级（其等于价值 / 工作量）、价值、人天评估（工作量）、实际人天
- 产品特性
- 预期结果
- 对应TAPD任务链接
- 状态
- 用户角色
- 填写日期、计划开始时间、计划完成时间、实际开始时间、实际结束时间
- 如下图所示，表头主要包括：
- Sprint Backlog：冲刺阶段的重要文档，用于描述任务、时间计划和进度，样例如图11所示
- 如下图所示，表头主要包括：
- 编号、用户故事、故事点、故事点预计
- 任务
- 负责人
- 工作量估算
- 具体每日时间结点及完成情况（绿色：表示计划完成并实际完成；红色表示计划完成但出现延期；蓝色：表示额外完成）
- 如下图所示，表头主要包括：
11、冲刺主要工作、敏捷角色及分工
- 主要工作：冲刺计划会议、创建Sprint Backlog、燃尽初始图、 冲刺计划
- 敏捷角色及分工：
- 开发团队：
- 完成可交付的产品
- 产品负责人：
- 审核产品待办列表和冲刺计划
- 解决开发中的技术问题
- 验证每天的测试结果
- 监督指导持续集成的工作
- Scrum主管：
- 每日站会
- 解决遇到的非技术困难，保护开发团队不受外部干扰
- 保持与干系人的良好沟通，建立好的人际关系
- 开发团队：
12、不同折线的燃尽图所说明的问题（6个）
- 如图12所示，主要包括符合预期、较复杂、较简单、假象、无参与、快速失败等六种。其中图12中蓝色折线为计划燃尽线，绿色折线为实际燃尽线（剩余时数）；图13为样例燃尽图
- 符合预期：开发过程中有细节需补充，但总体可控，属于正常
- 较复杂：开始无进展，开发团队根据情况，可移除一些用户故事
- 较简单：进展顺利，后期进度提前，可增加一些用户故事
- 假象：可能为了考核等原因，不是真正的进度情况，要了解开发团队原因，消除假象
- 无参与：可能没有更新自己的工作进度，也可能是PO增加了一些已完成的任务
- 快速失败：可能没有使用燃尽图，或发现项目没进展，快速停止，解决问题
13、冲刺评审会议与冲刺回顾会议
- 冲刺评审会议：
- 目标：
- 由产品负责人向用户代表和干系人展示用户故事、演示可交付的功能
- 记录和收集反馈意见，将新的用户故事放到产品Backlog，已有用户故事的修改放到冲刺Backlog
- 作用：
- 演示可交付的功能，用以确认项目进度，具有真实性
- 尽早获得用户反馈，产品更贴合用户需求
- 需要的准备工作：
- 邀请参加的人员
- 确定会议时间、地点
- 资料准备
- 日程确定、产品演示及讨论
- 会议的进程控制，讨论中的时间控制
- 会议纪要、总结与反馈
- 目标：
- 冲刺回顾会议：
- 目标：
- 开发团队、产品负责人、Scrum主管一起回顾本次冲刺
- 回顾开发平台、测试工具、管理平台等的选择和使用情况，敏捷过程中沟通、敏捷实践是否合理等
- 作用：
- 分享好的经验和发现改进点
- 需要准备的工作：
- 确定会议时间地点
- 回顾内容：工具、结对、分工、问题解决等做成道具
- 确定开会方式：讨论式、头脑风暴、引领式等
- 会议纪要、总结与反馈
- 目标：
14、Scrum主管的主要工作、与产品负责人工作的区别、两个角色是否可以由一人承担
- Scrum主管的主要工作：
- 服务于产品负责人：
- 确保Scrum团队中的每个人都尽可能理解目标、范围和产品域
- 找到高效管理产品待办列表的技巧
- 理解在经验主义的环境中的产品规划
- 确保产品负责人懂得如何来安排产品待办列表使其达到最大价值化
- 理解并实践敏捷性
- 当被请求或需要时，引导Scrum事件
- 服务于开发团队：
- 作为教练在自组织和跨职能方面给予开发团队以指导
- 帮助开发团队创造高价值的产品
- 移除开发团队工作进展中的障碍
- 当被请求或需要时，引导Scrum事件
- 在Scrum还未完全采纳和理解的组织环境中，作为教练指导开发团队
- 服务于组织：
- 带领并作为教练指导组织采纳Scrum
- 在组织范围内规划Scrum的实施
- 帮助员工和干系人理解并实施Scrum和经验导向的产品开发
- 引发能够提升Scrum团队生产率的改变
- 与其他Scrum Master一起工作，增强组织中Scrum应用的有效性
- 二者区别：
- Scrum主管：主要确保团队是富有成效的，促进日常需求和迭代推进，促进外部干系人和Scrum团队的密切联系，对功能很熟悉，同时还具备扫除障碍，防范干扰的能力
- 产品负责人：负责项目业务价值，提供项目战略和方向，决定做什么工作以及按照什么顺序完成，然后将其记录到Product Backlog中
- 两个角色不应该由一人承担。因为产品负责人主要负责与客户互动，创建客户案例，组织积压的产品并确定优先级，以及其他面向客户/用户的问题。而Scrum Master主要处理流程，监督会议，消除障碍并监视项目的整体运行状况，并根据需要进行调整。因此，二者术业有专攻，不应该由一人承担
- 服务于产品负责人：
16、敏捷工程实践（4个）
- 结对编程：两位程序员在一台电脑前工作，一位负责编程，另一位实时检查每一行敲入的代码
- 作用：
- 促进代码设计质量
- 提升团队能力和知识传播
- 研究表明结对生产率比两个单人总和低15%，但缺陷数少15%，考虑修改缺陷工作量和时间都比初始编程大几倍，所以结对编程总体效率更高
- 作用：
- 持续集成（CI）：
- 提供产品质量的快速反馈，保证随时拥有可工作软件
- 修复失败的构建是团队最高优先级的任务
- 测试驱动开发（TDD）：见本博客中第七部分【敏捷项目管理方法】中描述
- 重构：改善既有代码设计
17、组织中实施敏捷管理的步骤（8个）
- 制定实施策略
- 构建意识，培养热情
- 实施团队转型
- 确定实验的项目
- 确定成功的标准：时间、成本、质量、风险、变更、交付的成果
- 培训计划与实施
- 总结与改进
- 推广
18、冲刺结束，发布产品的准备工作（3个）
-
发布迭代：准备部署产品
-
帮助客户正确使用发布的产品
-
团队做好运营和维护准备
-
创建用户在线帮助文档
-
进行性能测试、压力测试、安全测试
-
如果系统升级重构，检查与旧系统的集成测试
-
准备产品部署工作
-
经营许可和法律审查
-
内部产品发布审批报告准备
-
-
内部准备：组织为产品发布做好准备
-
公司个组织部门要为产品发布做好准备
-
PO和Scrum Master要准备一个发布迭代待办列表
-
识别和确定完成发布活动的干系人
-
市场部门：与新产品发布相关的市场活动
-
销售部门：向哪些客户推销产品、推销策略等
-
生产部门：如何部署或打包产品
-
技术部门：如何收集客户反馈，如何响应客户意见
-
运营部门：帮助运行产品，解决运行中出现的问题
-
法务部门：产品许可，法律依规，版权纠纷，产权归属
-
-
准备评审会的PPT，解释产品的背景、目标、价值，确保干系人充分理解产品和产品客户
-
PO负责迭代发布任务的汇报，市场部门或运营部门主持评审会
-
-
外部准备：市场为产品发布做好准备
-
确定产品推广、品牌营销的时机
-
运营和市场把客户反馈转化为产品推广的依据
-
准备产品推广文案、新闻发布会、产品包装等营销物料
-
支持渠道要畅通
-
19、敏捷项目管理的关键测量指标（10个）
- 冲刺目标成功率
- 缺陷数量
- 项目总工期
- 产品上市时间
- 项目总成本
- 投资回报率
- ROI预算中的新请求（新的产品特性可能转化成更高的产品收入）
- 资金调配：将项目预算从一个项目移到另外一个项目的操作过程
- 满意度调查
- 团队成员流动率
20、Scrum团队的核心价值观（5个）
- 承诺(Commitment)：团队要对目标做出承诺，并对结果负责
- 专注(Focus)：团队的每一个成员专注在项目上，排除一切干扰
- 开放(Openness)：团队成员要相互信任，保持并鼓励每一个成员采用开放的态度
- 尊重(Respect)：建立相互尊重的工作氛围，积极和快乐的人会对他人友善
- 勇气(Courage)：有勇气做出承诺并坚持这些承诺，有勇气保持专注并向干扰者说“不”，有勇气保持开放并愿意改进，有勇气尊重并包容不同意见
21、敏捷管理的优势（10个）
- 更好的产品质量
- 更高的客户满意度
- 更高的团队士气
- 增强合作和责任感
- 可定制的团队结构（允许团队成员按自己特定的工作风格和个性组建团队，根据成员特定的技能进行分工）
- 更多的测量标准（燃尽图，故事点、速率、ROI投资回报率、时间表和预算）
- 提高绩效可视性（看板、站会、冲刺评估）
- 项目更易监控（有多个环节可以控制和调整）
- 提高项目可预测性
- 降低风险
22、传统项目管理的五大过程组和十大知识领域（5个 + 10个）
- 五大过程组：
- 启动
- 规划
- 执行
- 监控
- 收尾
- 十大知识领域：
- 项目整合管理
- 项目范围管理
- 项目时间管理
- 项目成本管理
- 项目质量管理
- 项目人力资源管理
- 项目沟通管理
- 项目风险管理
- 项目采购管理
- 项目干系人管理
23、项目的属性
- 生成唯一的产品、服务或结果
- 暂时性
- 通过逐步完善的方法开发
- 需要资源来完成，资源通常来自不同的领域
- 需要有一个主要的客户或项目赞助商
- 涉及到不确定性
24、干系人中，客户与用户的区别
- 二者出发点不同。客户是产品的购买者，用户是产品的使用者。客户是对产品或服务达成买卖关系的实体，用户是使用产品或服务，与产品或服务产生直接交互的实体
- 二者关注点不同。客户关注价格和效果，用户关注简单性、实用性和提升效率
25、适用于敏捷项目管理的项目类型
- 适用类型：
- 需要进行快速迭代、输出交付的产品
- 产品复杂，不断有新需求加入
- 需求方想尽早看到结果，并给予反馈
- 需要在开发过程中与客户紧密协作，对于客户需求变更给予快速响应
- 实例：
- 实例一：公司内部定制化工具类核心产品。因为该类产品的开发主要是为了公司内部服务的，比如公司内部自主研发的算法能力平台、数据采集统一平台、数据统一流程管理平台等等。首先，这些平台都是需要不断的贴合企业内部交付中心团队不断提出的需求的，因此在整个开发过程中，会有新需求加入。其次，这些工具平台能力越快迭代出发布版本越好，因为可以提高交付团队研发效率，避免重复造车轮。因此该类型项目适用于敏捷项目管理
- 实例二：与其他竞司的竞品形成的高竞争新型产品。该类产品需要快速迭代出版本，迅速抢占市场。再根据用户反馈，不断的迭代优化产品。因此该类型项目适用于敏捷项目管理
26、其他
（1）Sprint评审：让利益相关者审阅团队所建设的成果，并为后续计划提供信息
（2）Sprint推荐的最长周期是：30天
（3）如果Sprint长30天，Sprint评审会议最多为：4小时
（4）何时更新发布燃尽图：每个Sprint后
（5）良好团队的特征：自组织的
（6）如果敏捷项目运行后出现新需求，应该是：评估重要性，如果对业务来说足够重要，则包括在项目中，取代较不重要的需求
（7）“拉动”一词是指下工序带动上工序
（8）“拉动”系统的核心是：准时化
（9）内部项目的管理方式：管理是共同承担责任，计划由所有成员和资深项目管理人员共同制定，从而不需要强制就可以共同遵从
（10）外部项目的管理方式：管理是正式的、结构化的，要求周期性进行，并且由一个独立机构进行技术审核
（11）敏捷项目中推荐的设计方法：前面有足够的设计
（12）敏捷开发是一种：以人为核心、迭代、循序渐进的开发方法
（13）看板的三大作用：a）传递生产信息；b）识别浪费；c）控制生产系统动态地自我完善
（14）实行“看板方式”的基础是：流水线生产
（15）所有的敏捷开发方法的共同点：迭代开发和增量交付
（16）精益管理的核心是：消除一切浪费
（17）自动化测试所占比例应该：大于60%
（18）敏捷宣言背后的原则对于架构的处理是如何建议的：架构会浮现出来
（19）使用Scrum时，负责在范围和进度之间作出权衡决策的是：产品负责人
（20）Scrum的框架核心：Scrum的所有实践都是围绕一个迭代、增量的过程框架展开
（21）Scrum框架下，对软件的交付负责的是：开发团队
（22）Scrum的三大支柱：透明性、检验、适应
（23）冲刺：面向团队；迭代：面向产品；一次冲刺可有N次迭代
参考文献
[1]陈泽琳: AgilePM2020-课件1, 华南理工大学软件学院，2020.10;
[2]陈泽琳: AgilePM2020-课件2, 华南理工大学软件学院，2020.10;
[3]陈泽琳: AgilePM2020-课件3, 华南理工大学软件学院，2020.10;
[4]陈泽琳: AgilePM2020-课件4, 华南理工大学软件学院，2020.10;
[5]陈泽琳: AgilePM2020-课件5, 华南理工大学软件学院，2020.10;
[6]陈泽琳: 作业1, 华南理工大学软件学院，2020.10.23;
[7]陈泽琳: 作业2, 华南理工大学软件学院，2020.11.13;
[8]陈泽琳: 作业3, 华南理工大学软件学院，2020.12.18;
[9]陈泽琳: 作业4, 华南理工大学软件学院，2020.12.24;
[10]Project Management Institute： 项目管理知识体系指南（PMBOK指南第六版），[M]北京：电子工业出版社，2018.05;
扫一扫
930
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
