ACP知识串联

史泰西复杂性矩阵模型

每日站会问题：为什么团队不愿意配合敏捷转型？

1. 思维没有发生改变，只是增加了管理团队成员的步骤；
2. 计划是项目经理做的，和团队成员没有关系；
3. 每天站在一起汇报工作，面临的是项目经理的责问；
4. 有问题项目经理也不懂，要解决的还是自己；
5. 脱离不了管理者与被管理者之间的关系；
6. 一切流于直面，书上的跟实践的不一样。

Be Agile not Do Agile

敏捷注重的是思维模式，而不仅仅是实践方法，如果思路没有变，那么做的都是假敏捷。

三大制约因素在敏捷中的差别

三大制约因素差别

三大制约	Waterfall（瀑布型）	Agile（敏捷型）
范围	明确的范围 努力为达成确定的范围而努力	不确定的范围 项目实施过程中范围可随时修正
时间	提前设定完工时间 实际完工时间依范围的达成而决定	提前设定Sprint（冲刺）以及Release（版本发布）时间 时间到达必须交付
成本	提前设定完工预算 实际完工成本依范围的达成而决定	提前设定完工预算 预算到达必须交付

 其他属性的对比

	Waterfall——计划管控	Agile——经验开发
面对变更	抗拒变更-设定严谨的流程	拥抱变更-定期修正
最终产品	事前可预知	随着过程逐步修正完整
需求收集	事先详尽收集需求	根据定期反馈来探索需求
规划方式	事先详尽而完整的规划	过程中逐步细化
管理心态	详尽规划严谨控制	不断检查确认、学习与调整

敏捷金三角

1. 虽然在项目初期有对应的产品的愿景，但是充满知识性的项目完全无法预测项目到底要花多少钱及多少时间
2. 敏捷的作法是依客户的价值需求，定期的把客户能认知的最高价值成果交付到客户手中
3. 随着项目的执行，逐步修正方向
4. 让客户参与项目的进行，决定项目的终点

Scrum方法

PO-Product Owner 和客户有关联（甲方/自己领导）客户代表。负责把功能列表Product Backlog（产品待办事项列表）按照优先级的高低进行排序。并开一个会议叫Sprint Planning Meetings（冲刺规划会议）把功能拆分成各种各样的工作列出来，这个列表叫Sprint Backlog（冲刺待办事项列表）。然后进行开发工作，这个开发工作又称为一次Sprint Execution （冲刺执行），一般冲刺时间是2-4周的时间。想了解工作进度情况可以通过Daily Stand-up Meeting（每日站会） 来了解当前工作情况，站会内容3件事情。然后得到增量产品，这个产品是和之前集成过的增量产品。开发完成之后，进行检查有一个Sprint Review Meeting（冲刺审查会），后期在开一个Sprint Retrospective Meeting（回顾会议）。从开始到结束属于一个循环，一个冲刺。

Scrum团队三大角色和职责

由PO、SM和DT组成且缺一不可，团队数量一般7±2（5-9人）包括PO和SM。

1. PO即Product Owner 字面意思是产品或业务负责人，负责产品待办事项列表的制定。并且要检查增量产品是否符合要求。职责负责将产品的的价值最大化，负有产品的成败之责，主要工作是建构、说明、管理产品待办列表及针对团队的提问给予回馈。管理产品待办列表包含：排序优先级、确保正确性、与团队分享所理解的用户故事、创造价值及要求透明度。
2. Development Team字面意思是开发团队，角色可以互相支援。要求团队成员必须是通才，自我组织，自我指挥。主要是执行项目工作，产出迭代的增量成品。
3. SM即Scrum Master，字面意思是敏捷教练、敏捷专家或者敏捷大师。服务型领导，负责解决团队后顾之忧，解决遇到困难和问题；协助PO进行指导；还需要和客户、公司高层合作。职责提供团队所需要资源及环境、提供团队所需要敏捷训练，使团队能专注开发项目。协助PO与团队沟通产品愿景、目标及待办清单。

冲刺规划会议：30天sprint时间盒是8小时，2周sprint时间盒是4小时。

会议分成两部分，每个部分的时间盒各为整个会议的一半：

1. 前半部分：（做什么）

• 定义sprint目标；
• 团队一起从PB选择待办项创建SB。

1. 后半部分：（如何做）

• 将功能特性分解为任务，创建sprint计划。

每日站会一个时间盒为15分钟的会议。

所有的工作都有计划，但不是所有的工作都要在规划会议上分解。团队只注重前几天工作的分解，其他工作可以在每日站会上提出。

冲刺评审会议

Scrum团队与PO邀请的重要用户和相关方会面，团队会演示sprint增量成果，并得到反馈。还会讨论PB，让每个人都知道在下个一个sprint的SB会包括什么。对于30天的sprint，会议时间盒为4小时。

冲刺回顾会议

团队利用sprint回顾会议做经验教训总结，包括好的和不好的。整个Scrun团队都要参加，并在会后记录改进。30天的sprint，会议时间盒为3小时，回顾会议时间盒到期，这个sprint就结束。

客户价值优先级排序方法

1. 莫斯科（MoSCoW）

• Must have：必要的，无此功能系统将无法运作
• Should have：应该有的，让系统运作得顺畅
• Could have：可以有的，增加系统附加价值
• Won‘ have：额外的期望，但不在此次范围之内

      2. 帕累托分析（Pareto Analysis）

• 用于判断待办清单中Userstories 的价值优先级。需要方法可以取得帕累托的统计，如：问卷、访谈、专家判断、不记名投票……；
• 利用80/20法则，协助干系人界定关键功能与重要性

     3. 计点投票（Dot Voting）

• 是通过多数人投票技术，以决定优先级。操作步骤如下：

        一、假如有40个方案可以选择，每人分到8点，每个方案不限定给1点，若投票者觉得此方案                 很重要可以将8点全部投在同一个方案上。所有的点数都要使用完。每人8点是由40*20%                 得到的。（80/20法则）

        二、待全部人完成投票后，在依据总和点数排出优先级。

• 投点数可以是公开或者不记名的，以防止由某人影响最终方案或给予记名投票者签在的压力

 一共20个方案，每人4点。同上

    4. 狩野分析（Kano Analysis）

将客户的满意度分为4类

1.Delighter（感到兴奋）：上方的上湾曲线，指额外的功能没有做不会做抱怨，但是若有做到则客户感到兴奋及雀跃，如：无人驾驶、自动停车的功能。

2.Satisfier（感到满意）：中间斜线，指功能增加，客户满意度也跟随着增加，如：车子的内装

3Dissatisfier（感到不满意）：下方的下弯曲线，指必要的功能，没做好会引发客户抱怨，做很好客户也不会赞美，如：踩刹车功能，车子需停止

4.Indifferent（不显著）：正中间的正方形，指客户没有明确功能，有没有做都没有关系。

    5. 大富翁（Monopoly Money）

 指大富翁钞票，是用来排序需求特性的有效方法，操作步骤如下：

1. 给干系人一叠大富翁游戏钞票，钞票金额等同于项目预算总额
2. 使用这些游戏钞票，来针对用户故事需求进行预算分配，以了解相关干系人对需求特性优先级的想法。

   6. 需求优先级模式（Requirements Prioritization Model）

• 是利用严谨的算术方式，用以衡量需求的优先级
• 透过这个模式，每一个被提出的用户故事的Benefit（利益）、Penalty（损失）、Cost（成本）、及Risk（风险）4个特性会按照1~9不同层级的定义，数字越小则相对衡量指标越低
• 由客户定义利益及损失
• 由项目团队定义成本及风险
• 再计算出每一个用户故事的相对优先级

完成的定义（Definition of Done）

1. 当一个PBI或者增量产品被形容为（完成）时，每人必须理解这个（完成）的意思
2. 成员必须对于工作的允收要求有共同的理解，以确保透明度，这就是开发团队对（完成）的定义，并且可用以评估产品增量是否完成。
3. 同样的定义引导团队在Sprint规划会议，知道可选择多少PBI
4. 每个Sprint目的是交付符合（完成）定义且具潜力可发布的增量成品
5. 团队在每个Sprint交付产品功能的增量产品必须是可用的，所以PO可以选择马上进行发布
6. 如果一个系统或产品版本有好几个团队一起工作，则所有团队必须共同定义（完成）
7. 每一个Increment是添加到所有之前的增量成品之上，并且彻底地被测试过，以确保所有的增量成品可整合运作。
8. 随着开发团队越来越成熟，他们对（完成）的定义会扩大到包含更多严谨的标准，以达到更高质量