ACP敏捷9.敏捷应用场景

十大场景概述
●场景一:敏捷价值观和原则(如敏捷理念与传统理念的不同)
●场景二:敏捷优先级技术(如MoSCoW等)
●场景三:敏捷估算技术(如斐波那契数列应用等)
●场景四:敏捷团队沟通(如分布式团队等)
●场景五:敏捷领导力(如仆人式领导等)
●场景六:敏捷度量指标(如速度、时间、WIP等)
●场景七:敏捷计划(如版本计划、迭代计划)
●场景八:敏捷持续改进(如回顾会议)
●场景九:敏捷工程技术(如持续集成、完成定义等)
●场景十:敏捷风险管理(如风险燃尽图)

1. 敏捷应用场景

场景二： 优先级技术

 基于价值的分析致力于了解由客户定义的价值与产品中的不同部分如特性和任务之间的关系是如何的。特性通常以基于价值和风险的优先级得到优先处理。通过风险-价值指标和成本价值指标，使用MoSCoW或Kano方法可执行优先级。

场景三： 敏捷估算

 亲和估算，用于初略估算，相同规模的用户故事放在一起，大致估算。T恤估算是亲和估算的一种典型用法。

:计划扑克是基于宽带德尔菲估算技能、也是以共识为基础的工作量估算技能。有时候也称为敏捷扑克，往往在故事点和开发用户故事中用来估算相对工作量。在计划扑克会议中，每一位成员各持有一副相同价值的计划扑克卡片。

场景四：敏捷团队沟通

 一支高绩效敏捷团队是渗透沟通和面谈式互动的理想组合。对于分布式团队,在没有组合的情况下,一些经验可以提供有效沟通的最佳形式:团队内部网站虚拟团队空间电邮视频会议地理分离，
特别是世界范围的,团队要考虑语言、文化、时区的不同。

场景五 敏捷领导力 

 一名新的敏捷项目领导从支持角度习惯性的参与工作，并使用信息发射源来确保所有行动，消除对团队可见的障碍，敏捷项目领导正在做什么?
A: 采用接受反馈的做法，促进团队改进
B: 实行与敏捷团队合作的仆人式领导风格
C: 建立协作式团队工作文化
D: 遵循参与式决策模型千:

解析：敏捷提倡敏捷管理者要帮助团队排除障碍，构建愿景，保证信息可视化等等。不是命令和控制的方式，而是服务式的方法。

服务式领导力的说法可追根到1970年，罗伯特K格林立夫的一篇文章中， 指出服务式领导是献身于他们的公司和工作，为他们的同事，团队和客户服务的谦逊的管家。在一一个自主管理的团队中，正如格林立夫所说，一名服务式领导理想上是一名促成者， 倾听敏捷团队的需求，清除团队障碍并为提高生产率提供工具和其他支持。

场景六 敏捷度量指标

平均吞吐量：队列长度除以平均前置时间

在敏捷中，速度是用来预测的指标，不是绩效指标或者目标，不存在理想速度、最佳速度、基准速度等等,所以AIC\D的说法是错误的。
 

传统项目做计划，叫plan；敏捷中也做计划，叫planning，强调持续做计划，滚动做计划。

场景七： 敏捷计划

 发布计划，要有发布目标，每个迭代会有大致初始的用户故事，也就是大致确定这个迭代做什么。

在制定迭代计划时候，迭代长度的确定一般考虑三个因素：

1. 团队能力：是不是能在迭代内交付这些用户故事；2. 交付的这些用户故事，是不是经过了测试，形成一个相对完整的，能产生价值的交付单元；3. PO或者业务方有没有可能在一个迭代中对于已经交付的结果去进行验证，给出反馈。根据这些因素来确定迭代长度，一般不超过四周。

 //先考虑是那个层面的计划，敏捷中只考虑2个层面的计划；评审会议看结果，不是看计划。

 在迭代计划中,团队根据三部曲去设计选代待办项:
1.团队分解大的或复杂的用户故事为多元的，小的故事
2.团队把每个用户故事分解为开发任务
3.团队估算理想时间。,

场景八：敏捷持续改进

PDCA反馈循环，一环套一环；迭代是以周为单位的反馈循环。

 敏捷项目管理着重强调“持续完善”。从迭代后客户提供反馈，到迭代后团队保留时间回顾和反思执行情况，持续完善已经进入敏捷方法论中，所以选择B更合适，A/C/D都是敏捷所不提倡的，是一次性行为，不是持续的行为。

 敏捷回顾会议的作用就是收集反馈，持续改进。

 

场景九： 敏捷工程技术

场景9 敏捷工程技术实践， 主要是基于敏捷的XP极限编程实践	----外圈，管理实践-----4 ●Whole Team:完整团队 ●Planning Game:计划游观 ●Small Release: 小版本发布 ●Customer Tests:客户测试 ---中圈--技术+管理实践--5- ●Collective Ownership:共同所有权 ●Coding Standard: 代码规范 ●Sustainable Pace:可持续的节奏 ●Metaphor: 隐喻 ●Continuous Integration:持续集成 ----技术实践--4-- ●Test-Driven Development:测试启动开发 ●Refactoring: 重构 ● Simple Design:简单设计 ●Pair Programming: 结对编程
创建持续集成的服务器 霓虹灯： 红灯 绿灯 黄灯	持续集成就是为了沟通，所以你希望保证每个人都能很方便的看到系统当前的状态以及在系统上所做的改变。其中于沟通的最重要的一个途径是主线构建的状态。如果你使用Cruise,那么有-个网站可以展示给你看是否有个构建正在进行，以及最后一次主线构建的状态。很多团队喜欢将持续显示和构建系统连接起来,从而使它更显而易见。 通常用灯来表示:绿灯表示构建成功，当失败的时候则亮红灯。常见的一个设计是红色和绿色的熔岩灯-不仅仅给出这些构建状态的指示，而且还指示已经处于该种状态多久了。红色熔岩灯上的气泡表明此次构建已经失败很久了。每个团队都可以自己选择构建传感器一当然你的选择也可以是很好玩的 (最近我看到有人在用一只跳舞的兔子)。
统一的业务完成定义

 场景十： 风险管理

 15*0.2=3天 ----暴露出来大的风险

迭代中，敏捷用风险燃尽图来跟进风险，而不是用传统的风险登记册来做，太复杂了，风险燃尽图是一个轻量化的风险跟进方式。 风险燃尽图是用于跟踪项目风险的风险管理技能，敏捷团队和客户/产品负责人识别到风险，并进行跟踪。

 2. 企业敏捷成熟度评估模型

2.1 衡量一个项目是否适合用敏捷的方法来实施。

三个领域；9个 文化Culture 支持Buy- in 信任Trust 决策Decision Making 团队Team 规模Team Size 经验Experience 外部联系Access是否可以及时活动PO或者客户的反馈 项目Project 变更Change 关键性Criticality重要性 交付Delivery	Agile敏捷型(1-4分)； Hybrid混合型(4-8分)；Predictive预测型(8- 10分)； //混合：内部开发用敏捷；整体对外用传统项目管理方式。
文化 支持：buy in	高层发起人是否了解并且支持在项目中使用敏捷的方法进行实施。 //领导是否支持
团队信任度	考虑与团队合作的发起人和业务代表的态度。相关方确信凭借持续支持和双方反馈，团队能够将其匦景和雷求转换为成功产晶或服务? //业务方和客户方是否相信你们团队可以用敏捷方法实施交付
团队决策能力	团队是否可以自主作出有关如何实施工作方面的本地决策? //是否被授权，团队是否有能力做自己内部的决策。 //团队是否能自己做决策。
团队规模	核心团队的规模是多少?使用该量表: 1-9 。 1: 10-20 ■2: 21-30■3; 31-45=4:46-60=5:61-80■6:81-110=7:111-150=8: 151-200=9;201+=10..
经验水平	考虑核心团队角色的经验和技能水平。角色中人员经验水平参差不齐是很正常的，这对顺利开展敏捷项目没有影响:但每个角色中至少应有一名有经验的人员，这会更容易开展工作。
客户/业务联系	团队每天是否能联系到至少一名业务/客户代表以询问问题和获取反馈?
变更可能性	每月需求变更或发现新需求的可能性是多少? 50%以上变化，得1分； 需求变化小于5%，得10分。
产品或服务关键性	要帮助确定其他验证级别和文档严格程度需求。请评估正在构建的产品或服务的关键性。考虑因可能的缺陷导致的损失，确定失败可能的后果。
增量交付Dilevery的可能性	产品或服务是否能够按比例构建和评估?此外，业务或客户代表是否能够及时提供所交付增量方而的反馈?
举例子	适合敏捷开发

  2.2 衡量一个组织敏捷能力的评估

3. 总结