Scrum团队经历和经验分享，首先感谢scrum的技术指导立青对于整个执行的实际应用，以下内容也是根据参与项目情况后的体会和总结学习的分享。

主要内容划分：

整体流程的选择

各个分支流程的工作内容选择，和如何进行风险的预估和快速进度的管理

PD期望的质量保障的效果和结果

测试如何进行PD期望和有效的测试保证

其他优秀总结分享可供参考的内容

首先scrum的整体流程和过程体系：不多赘述，直接看图，大理论不谈

每个阶段如何进行项目管理和规范选择以及风险防范和预估，所有事务都是前期投入越充分后期就越顺畅

1) PB阶段：描述功能的写法选择，需求写法的确定。确定，用户权限要实现的内容，拆粒度的深度

确定迭代的时间进度：2周一个迭代

版本编写：迭代的计划规划

通过对于PD的PRD编写工作的内容：PRD的写法分析见下简图

本迭代选择的方式为用户场景涵盖型，选择原因：技术交叉性不大，主要在于实现用户场景和提高用户体验的功能改善和改进的项目。为了减少和项目成员过多的时间沟通。

产生的效果：需求沟通完全可控，在后期开发过程中的需求沟通和内容确认的时间不超过1个小时。

针对不同的项目的目的和要实现的内容，可以根据不同的优点选择需求的编写方式和撰写风格。

粒度的深度方式选择：期望看到的情况 ，User story的形式，然后到task。拆分结果期望是独立的可测试的

1. User Story要由需求提交者来编写，团队中的任何人都可以是需求提交者、当然产品经理一定是主体；
2. 永远不要在User Story中使用And和Or，因为这些分支词就表示分支任务，把它们拆成两个Story；
3. 再大的Story也不要大于1个sprint、否则说明没有尽力或没有能力去分解功能，而不是不能分解；
4. User Story要有优先级和预计完成时间，以便团队根据其优先级和工作量来制定Sprint Backlog；

其目的是为了完成原始需求和实现需求的区分。

2) 计划会议1： 初步的SB（团队工作量，US优先级和工作量，优先级，需要指定PM，整个大团队，组织者和ScrumMaster的指定）

3) 计划会议2： 任务分解；工作量和任务分工；排期；PM自己开项目计划会议（SM）；

项目分开的选择PM主导；3种

A标准（WBS,估时排期---会中全体）好处a.民主，科学可能产生不好的点：效率低，统一

B个人主导(会前：WBS,估时/个人会中：个人讲，集体review)|排期，会中全体(好处：半民主)

C由PM主导（会前：WBS估时PM 会中：PM讲，大家review） 不好的地方，不科学，不民主，对其他考虑不够专业例如前端等。好处：效率高

优先考虑B，风险性和效率综合考虑，在团队成熟了可以考虑使用A

根据资源和工作量 分析出团队瓶颈 来相互资源平衡，全功能团队。目的是实现团队风险的预防和提前应对

任务条的设计 任务都是连续的 第一天一部分时间紧接着第二天剩余的时间，按照优先级进行完成，目的是未完成的后期其他成员的时间影响就能清晰可见 例如TC 配合关系的影响和 团队的时间风险的影响，出现问题就需要调整计划。另外如果资源分得太散了风险太大，需要投入在主要的，不要过分集中或者过分分散 例如过分分散 20号发布 大家全部分散在各个单一的任务资源 如果出现任何一个问题 则会影响全部的发布，所以要进行拆分资源的投入来减少风险

这样做的目的不是为了评价团队成员的工作任务量，强度和问题量而是为了识别风险

另外一个优点是计划时间评估的准确度能力的提升会随着迭代团队的相互成熟，不断精准化

需求 计划 实际时间

4) 实际和期望产生的结果方式：任务按照优先级划分进行排列

任务时间和划分做个最简单的风险识别的例子：为何采用如此分配和团队目标呈现

图1：

图2：

上面两个图属于2个极端的来反应说明问题点，再取中间是可采取的有效的方式。

图1的问题在于区块化分工开发过于明细，如果任何一个开发在完成任务中出现问题，则即使其他任务都正常，那么整个项目组也会直接全部受到影响，全部无法正常上线

图2则是任务过于单一，人员集中，会存在技术实现人员的沟通和相互影响的风险过大串线的任务未实现资源最大化的应用。团队配合不合理，下游团队的闲置，测试被压缩。对不同技术和人员层次未规划

实际采用方法就是取2个极端进行中和，根据优先级和任务的难以程度和耗时情况，进行主力和协助资源的穿插分配达到有主导有协助，提高下游提前进行部分简易任务的进行，整体资源应用前移。

目的是通过团队的时间表也能清晰反映，主要工作困难和耗时点，假如，开发资源充足，测试资源紧张，完全可以全民皆兵，开发资源紧张，测试资源富裕可协助单元测试等，人员角色实现交叉，来实现共同目标的顺利达成。

5) daily meeting：一个项目；晨会；PD参加-目的识别问题（PM-开发进度和人员情况的掌控 QA：项目风险识别，质量保证情况）

6) 评审会议：功能（PM）---对功能实现进行评审，以及技术团队的技术评审等

7) 回顾会议：（SM组织），全员参加。迭代的回顾。目标完成情况

8) 经费：制定团队规则和惩罚以及活动规则，周期完成或者回顾会议进行团建

PD期望的质量保障的效果和结果

以上前期选用的方法都是为了保证项目的质量和时间成本质量，以及资源的分配。

测试如何进行PD期望的有效测试保证

那么PD期望看到的测试需要完成哪些内容

a) 对于需求评审阶段的需求测试内容

i. 对于需求的内容的目的性能达成共识，测试提前化，了解项目要完成和后期期望达到的目标是什么，针对目标进行需求测试分析。

ii. 对于PRD和PB会议以及计划会议中，能够对功能内容或者需求能够进行场景拆分，最期望看到的就是业务场景的遗漏，异常甚至是场景交互的问题提交，所谓的需求测试的亮点所在和PD最期望看到的内容就在于测试在需求阶段对于场景的分析；是否有更为方便缩短流程的场景订正。以及良好的产品方向或者行业方向的建议

b) 计划会议2阶段，以及技术团队的技术评审会议，测试人员能够协助开发在场景压力，技术实现以及如何设计测试方法进行快速测试，缩短周期上进行控制。由于良好的风险意识能对团队整体的资源，时间和技术上提供风险识别和问题分析。

c) 开发和实现阶段，以及测试阶段：此时的主要期望在于发现功能交互问题，以及可用性的提升

d) 回顾阶段：nice to have能进行问题分析和残留问题的总结看法和处理计划。