敏捷开发、PMP、ACP基础知识
什么叫敏捷
敏捷是许多⽅法的⼀个总称，敏捷是⼀种思想,⼀种态度,
倡导简单设计，快速交付，价值导向，响应变化。
⼀、敏捷的由来
2001 年，17位软件开发领域的领军⼈物在Utah的Snowbird会⾯，分享他们的想法，这些软件业思想领袖共同发表《敏捷宣⾔》，正式宣告敏捷开发运动 的 开始。汽车音响系统
⼆、敏捷宣⾔
六级准考证打印官网入口个体和交互胜过流程和⼯具
重视个体及团队的⼒量
坚持以⼈为本，倡导共同参与
流程和⼯具的局限性，不能适应所有团队
可⼯作的软件胜过详尽的⽂档
⽂档够⽤就好（并⾮否定⽂档的作⽤，强调过犹不及）
避免镀⾦
客户合作胜过合同谈判
客户不是敌⼈，我们的价值是为客户创造价值，营造合作双赢的局⾯
响应变化胜过遵循计划
优先实现价值⼤的需求
重视客户的实际利益
三、敏捷⼗⼆项原则
1）我们最重要的⽬标，是通过持续不断地及早交付有价值的软件使客户满意。
2）欣然⾯对需求变化，即使在开发后期也⼀样。为了客户的竞争优势，敏捷过程掌控变化。
3）经常地交付可⼯作的软件，相隔⼏星期或⼀两个⽉，倾向于采取较短的周期。
4）业务⼈员和开发⼈员必须相互合作，项⽬中的每⼀天都不例外。
5）激发个体的⽃志，以他们为核⼼搭建项⽬。提供所需的环境和⽀援，辅以信任，从⽽达成⽬标
6）不论团队内外，传递信息效果最好效率也最⾼的⽅式是⾯对⾯的交谈。
7)可⼯作的软件是进度的⾸要度量标准。
8)敏捷过程倡导可持续开发。责任⼈、开发⼈员和⽤户要能够共同维持其步调稳定延续。
9)坚持不懈地追求技术卓越和良好设计，敏捷能⼒由此增强。
10)以简洁为本，它是极⼒减少不必要⼯作量的艺术。
11)最好的架构、需求和设计出⾃⾃组织团队。
12)团队定期地反思如何能提⾼成效，并依此调整⾃⾝的举⽌表现。
1.png
an
是衍⽣⾃丰⽥⽣产管理⽅式
基于以下其七种原则的敏捷⽅法论，消除浪费、强化学习、尽可能晚决策、尽可能快交付、授权团队、构建完整性和全盘检视
看板分为物理看板和在线看板。看板的初始⽬的在于可视化⼯作，让每个⼈看到所有⼯作项的进展和相应的优先级，进⼀步提⾼⼯作透明度，并且在⾯临新⼯作时帮助排定优先级。
6.4 D SD M
动态系统开发⽅法
6.5 A T D D
验收测试驱动开发
6.6 T D D te s t- d r iv e n-d e v e lop m e nt 测试驱动开发
七、敏捷团队组成（Scrum）
常规意义下敏捷只存在以下三种⾓⾊。
7.1 PO Pr od uct Owne r
确定产品的功能
决定发布⽇期和内容
为产品的ROI负责投资回报率
排定功能优先级
接收或者拒绝开发成果
维护PBI
听取各⽅的信息和建议
从⽤户的⾓度及公司业务的⾓度思考问题
担任⾓⾊：业务⽅代表/客户、产品经理、市场⼈员、项⽬经理7.2 SM Scr um Mas te r
组织推进Scrum活动
指导团队成员
和PO梳理PBI
清扫障碍
7.3 ST Scr um T e am
设计⼈员
开发⼈员
测试⼈员
其他
⼋、⽤户故事 Ur Story
8.1 故事三要素：
⾓⾊ 活动 价值
模板：
英⽂：As a , I want to , so that
中⽂：作为⼀个 <⾓⾊>, 我想要 <；活动>, 以便于 <；价值>
大连外语培训⽤户故事不能够使⽤技术语⾔来描述，要使⽤⽤户可以理解的业务语⾔来描述
8.2 3C原则
卡⽚(Card): ⽤户故事⼀般写在⼩的记事卡⽚上。卡⽚上可能会写上故事的简短描述，⼯作量估算等。
交谈(Conversation): ⽤户故事背后的细节来源于和客户或者产品负责⼈的交流沟通。
确认(Confirmation): 通过验收测试确认⽤户故事被正确完成。
8.3 ⽤户故事的六个特性
简称INVEST原则：独⽴性(Independent) 、可协商性(Negotiable)、有价值(Valuable)、可估算性(Estimable) 、短⼩(Small)、可测试性(Testable)
独⽴性(Independent) 要尽可能的让⼀个⽤⼾故事独⽴于其他的 ⽤⼾故事。⽤⼾故事之间的依赖使得制定计划，确定优先级，⼯ 作量估算都变得很困难。通常我们可以通过组合⽤⼾故事和分解 ⽤⼾故事来减少依赖性。
可协商性(Negotiable) ⼀个⽤⼾故事的内容要是可以协商的，⽤ ⼾故事不是合同。⼀个⽤⼾故事卡⽚上只是对⽤⼾故事的⼀个简 短的描述，不包括太多的细节。具体的细节在沟通阶段产出。⼀ 个⽤⼾故事卡带有了太多的细节，实际上限制了和⽤⼾的沟通。
有价值(Valuable) 每个故事必须对客⼾具有价值(⽆论是⽤⼾还 是购买⽅)。⼀个让⽤⼾故事有价值的好⽅法是让客⼾来写下它 们。⼀旦⼀个客⼾意识到这是⼀个⽤⼾故事并不是⼀个契约⽽且 可以进⾏协商的时候，他们将⾮常乐意写下故事。
可估算性(Estimable) 开发团队需要去估计⼀个⽤⼾故事以便确 定优先级，⼯作量，安排计划。但是让开发者难以估计故事的问 题来⾃：对于领域知识的缺乏(这种情况下需要更多的沟通)， 或者故事太⼤了(这时需要把故事切分成⼩些的)。
短⼩(Small) ⼀个好的故事在⼯作量上要尽量短⼩，最好不要超 过10个理想⼈/天的⼯作量,⾄少要确保的是在⼀个迭代或Sprint 中能够完成。
⽤⼾故事越⼤，在安排计划，⼯作量估算等⽅⾯的 ⻛险就会越⼤。
可测试性(Testable) ⼀个⽤⼾故事要是可以测试的，以便于确认 它是可以完成的。如果⼀个⽤⼾故事不能够测试，那么你就⽆法 知道它什么时候可以完成。⼀个不可测试的⽤⼾故事例⼦：软件 应该是易于使⽤的。
九、敏捷的会议
原则⼀ 所有会议都要准时开始、准时结束 。
原则⼀ 展开讨论时会议的推进⼈必须在场，他不能参与到具体讨论中， 但是他需要-注意讨论进程，如果讨论参与者失去重点，他还要将讨论带回正轨。
原则三 敏捷不提倡加班。
9.1 迭代计划会 Sp r int Planning Me tting
参与⼈：整个团队
时长：迭代周期（每周两⼩时）如⼀个迭代为两周：会议为4⼩时
输⼊：PB（产品代办列表）
第⼀部分：PO讲解排好优先级的需求
第⼆部分：团队规划迭代选取内容
输出：SB(迭代代办列表)、各个故事的验收测试⽤例
具体流程：
1. PO依次展⽰PB中的故事，选择最⼩的故事作为计量单位：1个故事点
2. 每展⽰⼀个团队就对该故事进⾏估算(⽤计划扑克或猜拳游戏等 ⽅式)并记录平均故事点数
3. 如果其中两个⼈的估算点数超过两倍则分别说明原因，然后重新 估算
4. 如果某个故事过⼤应将其划分为较⼩的故事然后进⾏估算
讨论过程中应该包含以下内容中文翻译成法语
1）团队依次讨论PB中的故事2） 找出验收条件 3） 找出⾮功能性需求(性能、安全......) 4） 确定每个故事的验收测试⽤例 5） 确定每个故事完成的定义
5. SM向团队正式提问“是否能在本Sprint周期内完成该故 事”，如果是则放⼊本次 SB 中
discussions6. 根据团队能⼒，选取故事放⼊SB
jiugan
7. 确定本次Sprint要达成的⽬标
注意事项：
△ 只有团队能估算 PB 中的故事，PO 不参与估算
△ 上⼀个 Sprint 遗留下来的故事需要重新估算
△ 不要讨论技术细节
letterboxing
9.2 站⽴会 D aily Scr um Me e ting
每⽇站⽴会
参与⼈：SM及团队（其他⼈员可参与，但不能讲话）
芬兰语字母时长：15分钟
输⼊：昨天做了什么？今天计划做什么？我遇到了什么困难？
输出：看板
注意事项：
△ SM 站在圈外，不要提问题、移动任务卡或更新燃尽图，团队不是向 SM 汇报
hearfrom△ 不要讨论技术细节问题，可以会后单独讨论
△ 不要在没有准备的情况下参会
△ 进⾏中的任务不要过多
9.3 评审会 Sp r int Re v ie w Me e ting
评审会
参与⼈：所有利益相关⽅
时长：迭代周期（每周⼀⼩时）如⼀个迭代为两周：会议为2⼩时
输⼊：待评审功能
输出：评审结果，⽤户代表及各⽅的反馈
注意事项：
只演⽰完成了的功能
9.4 回顾会 Sp r int Re tr os p e ctiv e Me e ting
回顾会
参与⼈：SM及团队
时长：迭代周期（每周⼀⼩时）如⼀个迭代为两周：会议为2⼩时
输⼊：过程数据累积
输出：改进待办事项列表
注意事项：
建议每次迭代改进排列优先级，且⼀个迭代中不宜改进项过多
会议开场需要营造开放的环境，让⼤家放下包袱，⼤胆说话。
>the boys 英文歌词
