下载信息  [文件大小：0.00 bytes 下载次数： 次]

点击下载文件:undefined

看关键词汇，比如：快速变化、迭代、冲刺sprint、用户故事、用户画像、史诗、最小化可行产品MVP、燃尽图、燃起图、看板、增量交付、持续发布、迭代规划会、每日站会、迭代评审会、回顾会、lDoD（Defineof Done）等。

二.  如何区分对待敏捷和预测？

预测是大规划、大执行、大交付；

敏捷是小步快跑-迭代+增量，不断交付l预测是严格控制变更；

注意：敏捷不是随便乱改，也必须要经过评估，只是团队+客户，讨论达成共识，就改了。没有冗长的流程和审批过程，以及各类繁复的文件。

个体和互动  高于  流程和工具

工作的软件  高于  详尽的文档

客户合作  高于  合同谈判

响应变化  高于  遵循计划

• ProductOwner：作为客户代表，定义所有产品功能，决定产品发布的内容及日期，对产品的投入产出负责，根据市场变化对需要开发的功能排列优先顺序，合理的调整产品功能和迭代顺序，认同或者拒绝迭代的交付。

• ScrumMaster：起到教练的职责，领导团队完成Scrum的实践以及体现其价值，排除团队遇到的困难，确保团队的胜任其工作，并保持高效的生产率，使得团队紧密合作，使得团队个人具有多方面职能的工作能力，保护团队不受到外来无端影响。

• Dev Team：经典团队拥有5-9人，团队成员都是多面手（程序员，测试员，用户经验设计，等等），团队成员都全职工作（特殊职能可以例外（数据库管理员）），团队自我组织和管理，团队关系在一个迭代中应该是固定的，个人的职能可以在新迭代开始时发生调整。

2. 三种工件(Artifaccts)：

• ProductBacklog：产品需求的列表，包含业务需求、技术需求、NFR等，理想情况下，每一个待完成的工作都将对客户产生价值，PO对该列表进行优先级排序，每个迭代开始前，优先级排序还需再度修正，待办事项列表中的条目以用户故事的形式呈现，ProductBacklog遵循DEEP模型（Detailed适当的详细程度、Estimated被估算的、Emergent涌现的、Prioritized排了优先级的）

• SprintBacklog：ProductBacklog 的子集，只记录当前迭代的工作，将用户故事拆分成任务，团队成员主动领取任务，团队成员有共同的迭代目标，为交付可工作的成果而努力，团队成员可以添加、删除或者更改迭代中的任务，迭代列表中的任务进行了估算，剩余工作量的估计每天需要更新。

• Product Increment：团队在迭代内完成交付成果，集成到以往的迭代成果中，形成增量式的交付（发布和交付解耦），每次交付的用户故事必须符合验收条件，每次交付的增量成果必须处于可用状态，而不管PO是否决定发布这个用户故事。

3. 5种会议

• 产品梳理会P.B Refinement：拆分Epic\Feature、分析Userstory、重新估计并重排优先级。

• P 迭代计划会Sprint Planning Meeting：第一阶段：选取用户故事，确定迭代目标（PO与团队一起从P.B中选择待完成的用户故事）；第二阶段：拆分任务，创建S.B（团队拆分和确认任务给出工作量估算）S.B是团队协作的结果 不是只有SM和PO来决定的。

• D 每日站会Daily Scrum：属性：每天都开，15分钟结束，站着开会；所有相关的人被邀请，只有Scrum Master、Product Owner、Dev Team能够在会上发言，避免无关的讨论。

• C 迭代评审会Review：团队需要演示所完成的迭代工作，典型的做法是使用演示形式展示新功能或者底层架构的实现，非正式的，2小时的提前准备，不需要正式演示文，整个团队都需要参加，邀请所有关注产品的人参加。

• A 迭代回顾会Retrospective：周期性的回顾，总结工作中的经验和教训，15-30分钟，在每个迭代结束时进行，整个团队都需要参加，可能还包括客户，迭代回顾内容：哪些工作良好（应该继续保持）？哪些做的不好（应该停止）？哪些可以改进（就被按优先排序的改进的行动达成共识？）。

勇气Courage，开放Open，专注Focus，承诺Commitment，尊重 Respect。