敏捷管理

增量型生命周期   最小可行产品（MVP）

一个产品四阶段    引入-成长-成熟-衰退

敏捷型生命周期  基于迭代，时间长度相等的时间盒子，交付最重要的功能

                            基于流程，根据功能而不是迭代进度进行开发。定义任务板的工作流，并管理各列进行中的工作   WIP（在制品）

敏捷项目管理

敏捷思维

4大价值观、12大原则、实践  scrum  xp  看板

敏捷宣言   个体以及互动 胜过流程和工具、可用的软件 胜过详尽的文档、客户合作 胜过合同谈判、应对变更 胜过遵循计划

四大价值观 以人为本、以价值为导向、合作共赢、拥抱变化

12大原则  

1、 我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户  //尽早、持续交付  有价值、客户满意

2、 欢迎对需求提出变更，即使在项目开发后期也不例外。敏捷过程要善于需求变更，帮助客户获得竞争优势  //拥抱变化

3、 要经常交付可用的软件，周期从几周到几个月不等，且越短越好  //频繁交付  

Scrum的迭代周期大概为一个月

XP（极限编程）的迭代周期则短至一周

4、 项目实施过程中，业务人员与开发人员必须始终通力合作  //一起工作 理解彼此的想法

5、 要善于激励项目人员，给予他们所需的环境和支持，并相信他们能够完成任务  //提供环境和支持

6、 团队内部和各个团队之间，最有效的沟通方法是面对面的沟通  //面对面沟通  渗透式、高带宽沟通

7、 可工作的软件是衡量进度的首要指标  //衡量指标  价值导向  

8、 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持稳定恒久的进展速度   //可持续步调    不允许过度的压力和过度的疲劳

9、 对技术的精益求精以及对设计的不断完善将提高敏捷型  //技术卓越    重构

10、尽量做到简洁，尽量最大可能减少不必要的工作。这是一门艺术  //简洁

11、最佳的架构、需求和设计出自于自组织团队  //自组织团队

12、团队要定期回顾和反省如何能够做到更有效，并相应地调整团队的行为   //定期反思  Retrodpective Meeting

Scrum

从相关方处获取需求--产品负责人PO—产品待办列表Product Backlog—团队 迭代计划会议—迭代待办事项--（每日站会—迭代评审会议—潜在可发布的产品增量—迭代回顾会议）--敏捷教练Scrum Master –

Srcum框架的33355

三支柱  透明性、检查、适应

三角色  产品负责人PO、敏捷教练、项目团队

三工件  产品待办事项列表、冲刺/迭代待办事项列表、可交付产品增量

五事件

冲刺Sprint、冲刺规划会议、每日站会、迭代评审会议、迭代回顾会议Sprint Retrosperctive

五价值观

承诺、专注、开放、尊重、勇气

 

产品负责人  维护产品待办事项列表，指定软件的交付的内容   可接受或拒绝工作成果

敏捷教练  清除障碍 服务团队

项目团队  人数3-9人  授权，自组织和管理   责任属于整个开发团队

 

三个工件---用户故事

产品待办事项列表 产品待办事项列表是所有工作的有序列表，它以故事形式呈现给团队，价值越大的排在上面

产品负责人在迭代中的会议中与团队合作，为即将进行的迭代准备故事，细化足够的故事

刺探，以了解风险

 

冲刺待办列表 明确具体任务、任务自管理、Spring规划会议产出起始、团队的资产

 

可交付产品增量

冲刺Sprint

冲刺计划会议

每日站会  不超过15分钟、任何人都可以主持站会、完成·、障碍、反模式

迭代评审会议   4小时以内、内容包括：完成、未完成，如何解决，演示，预测，下一步的工作，评审、改变、下个预期产品

迭代回顾会议   检视、Sprint计划会议之前、回顾会议最长不超过2小时、遵守时间盒子的规则

Sprint回顾会议的目的在于：

1、 检视前一个Sprint中关于人、关系、过程和工具的情况如何

2、 找出并加以排序做的好的和潜在需要改进的主要方面；同时制定改进Scrum团队工作方式的计划

敏捷或适应型环境中需要考虑的因素：   整合、范围、进度、成本、质量、资源、沟通、风险、采购、相关方

燃尽图   

燃起图

Sprint计划会  拆分成task   领取task、PO准备待办事项列表、Sprint计划会一般不超过8小时

每日站会   内部沟通交流、成果、障碍

敏捷团队构成   团队规模3-9人、集中办公、100%专职成员，跨职能团队、T型人才、自我组织

成功敏捷团队的角色

跨职能团队成员   各种必要技能、常规节奏、短时间内交付任务

产品负责人  待办事项、排序任务

团队促进者   遵循敏捷流程、引导、指导、消除

成功敏捷团队的角色  

       1、自我组织、自我管理

       2、与仆人式领导一起茁壮成长，领导支持团队的工作方法

       3、频繁创造产品增量，集体对项目工作负责

       4、限制在制品WIP

    5、以各种方式开展合作（如结对、群集、群体开发）

仆人式领导  服务 需要和发展 达到最高绩效   实践并传播

 领导力的特征  自我意识、倾听、服务、促进、引导、帮助、促进他人精力和才智提升

 工作顺序  定义目标  鼓励人员  一个人人都能成功的环境   开展过程

项目整体状态   燃尽图  进展和风险情况  燃起图  显示迭代过程中范围内变化   

               速度   实际完成功能的故事点大小的总和    4-8次迭代

               敏捷挣值只能在迭代中使用   挣值是基于已完成的功能

看板方法原则

       准时制

       看板，为视觉符号或卡

       工作流的状态：要完成的工作、进行中的工作和已完成的工作

提高工作效率和质量：限制在制品WIP

减少浪费：透明使浪费可视化，消除浪费

 

适应回顾

       准备、收集数据、分析原因、采取行动、收尾

准备  常见工具：签到、ESVP

收集数据 常见工具：时间盒子、三五成型、颜色标识、需找优势、满意度直方图

分析原因  常见工具：头脑风暴、名义小组、五问法、鱼骨图

采取行动   常见工具：简单主题、SMART目标

收尾   常见活动：  +/Δ     帮助、阻碍、设想

用户故事  INVEST原则

I 独立的

N 可协商的

V 有价值的

E 可估计的‘

S 短小的

T 可测试的

3C： 卡片、交谈、确认

产品待办事项列表

排序  以价值和风险（Anti-Vaule）排序

属性  DEEP：详略适宜的（Detail Appropriately）,可估计的（Estimable）,涌现式的（Emergent）,排好优先级的（Prioritized）

制定迭代待办事项

敏捷三角形

范围、进度、成本    成本、进度、范围      价值、约束范围、质量

价值目标：提供可交付的产品

质量目标：提供可靠的、适应性强的可交付产品

约束目标：在可接受的约束内，实现价值和质量目标

敏捷三角形-技术实战  持续集成、验收测试驱动开发(ATDD)、刺探（时间盒研究或实验）、在不同层面测试、测试驱动开发（TDD） 行为驱动开发（BDD）:编写自动化测试

Spike(刺探\探针)：架构spike、基于风险spike     //技术尝试。用于通过快速失败来降低风险

 

 

敏捷项目章程    够用就好

敏捷团队章程   团队章程—团队社会契约---团队价值观、工作协议、基本规则、团队规范

增量   是一个Sprint完成的所有产品待办列表项的总和，以及之前所有的Sprint所产生的增量的价值总和。无论产品负责人是否决定发布它，增量必须可用

敏捷计划层次  敏捷计划拥抱变化，而不是阻碍变化；推测意味着确定方向，并期待更多变化

敏捷的层次滚动计划—敏捷相对估值

故事点是故事相对规模的一个数值指标，注意它不是具体的时间值

相对规模估计---宽带德尔菲：花车效应、花环效应、计划扑克、亲和估算：斐波那契序列

适合敏捷合同类型----采购与合同

敏捷适用性过滤器：联系程度、经验、团队、支持、信任、决策、交付、关键性、变更

 

产品愿景盒和电梯测试说明的意义

产品路线图  FAB  F功能 A优势 B好处

故事地图

迭代0-N  0计划迭代，创建安排故事卡片，不交付客户价值   1-n开展迭代工作，具体执行由故事拆分成的各个任务    N强化迭代，不再实现新的需求，所有的功能都要经过完全测试并保证其功能可靠性。不交付客户价值

极限编程(XP)  基于频繁交付周期的软件开发方法，关注团队凝聚力、沟通、代码质量和编程，主要目标在于降低因需求变更而带来的成本

结对编程、持续集成、自动化测试、技术债务、重构

看板  限制在制品WIP   源于精益

精益  消除浪费  按照用户需求拉动   Muda(浪费)、Mura(不均衡)、Muri(超负荷)

制造七浪费：  运输、等待、动作、缺陷、库存、过量生产、过度加工

软件七浪费: 部分完成的工作、多余的流程、多余的特性、任务切换、等待、动作、缺陷

MoSCoW法则 M必须做、M应该做的、C可以做的、Would not不要做的

卡诺KANO分析

精益画布 是呈现在一张纸上的可视化简明商业企划书

MVP最小可行产品，可以为客户提供价值的足够小且足够完整的功能包

MMF最小可售功能，可以为客户提供价值的足够小且足够完整的功能包

 

 

敏捷合同三角形   进度和成本一般固定，范围工作量固定，但是功能可以随着项目的变化而进行等量地调整

 

透明沟通与信息发射源

沟通：敏捷提倡集中办公，面对面沟通，信息发射源，定期邀请相关方评审

相关方：直接与客户对接，减少中间的层层管理级别的；加快组织内部和组织之间的信息分享，敏捷提倡信息高度透明。

信息发射源（看板板、累计流量图、燃尽图） 和每日站会，都有助于与相关方了解项目，共识信息，管理风险等。

迭代规划会议、迭代评审会议、迭代回顾会议，都对项目信息透明，顺利推进项目有帮助

常见的估算用户故事规模的工具是故事点和理想时间。理想时间代表时间量，即不受会议、个人生活、非工作日或其他拖延、障碍和分心的干扰的情况下，相对于待办事项中其他用户故事，单独个人建立，测试和发布用户故事所花的时间

 

用户故事：代表客户需求的具体点，为客户增加价值。一般由三部分组成：作为一个角色、我需要一个功能、以便我能达成目的

用户故事是小而细粒度的，而不是合集，用户故事的合集是产品待办事项列表

 

情商，识别、评估和影响我们自己、其他人和团体的情绪的能力。管理敏捷团队，保持灵活领导力的有效方式就是持续提升我们自身的情商（自我认知、自我控制、社会认知和社会技能）

领导力面对工作，是利用自己的权利和影响使得对方按照你的意思工作，团建是为了建立好的气氛，需要以对方为主。

 

看板实践中的队列补充会议类似于敏捷里的冲刺计划会议，用来计划下阶段的重点工作，包括障碍处理。

 

高绩效团队的两个主要特点，一是工作方式自组织；二是设定挑战目标，以实现绩效为根本目的。

 

信息共享  知识共享：知识共享对于大规模敏捷项目来说是一个重要的机制，知识共享会议需要同目标一样被清晰地定义，团队参与必须监控去确保知识流转按照一个结构化方式进行

 

PO的作用  产品负责人主要负责确定产品的功能和达到要求的标准，维护产品待办事项列表，指定软件的交付的内容，同时有权利接受或拒绝开发团队的工作成果。范围增加，产品负责人应该及时更新产品待办列表并对增加的内容进行评估，对优先级进行排序，以确定下一步行动。

 

 

敏捷强调价值优先，在项目中实实在在地体现价值是让干系人接受敏捷最有效的方式

 

只有产品负责人有权决定项目范围的变更。项目的进度目前已经落后，如果进行范围裁剪则必须要与产品负责人取得联系

 

会议的促进者主要职责是搭建平台，邀请共创，自己如果需要表达观点可以在其他人发言之后补充

迭代次数 = 产品待办事项 / 速度 

 

 

 

任务板   可以看到单个任务的状态，对于特定增量的项目进展预测更有帮助

故事地图  是所有用户故事的罗列和展示

累计流图   可以看到和预测项目的进展，但是看到的是整体的数量

 

渗透式沟通 是指无意识的、非主动的沟通

预期货币价值，是实施定量风险分析的一种工具

净现值分析，对项目进行评估筛选的一种财务分析的一种工具