《Scrum开发流程最佳实践》由会员分享，可在线阅读，更多相关《Scrum开发流程最佳实践（7页珍藏版）》请在金锄头文库上搜索。
1、1. 角色分工、职责与义务本流程内按不同的职责将人员划分为四个角色：PO(Product Owner), PD(Product Designer)和开发人员和架构组(Architect)o1.1. PO 的职责与义务1) PO 的职责为收集提出的需求并对其进行分析，输出产品为可以直接应用于产品设计与 开发的需求文档。2) 需求文档是产品设计与开发过程中针对产品功能的唯一参考文档。3) 需求文档应当包含产品设计和开发中需要使用到的全部功能性信息，包括且不限于主要 功能模块划分、详细用例描述、系统输入与输出数据的定义等等。4) 需求文档必须为针对客户需求进行分析总结的结果，其中对功能的描述应具有通
2、用性， 而不应仅针对用户提出某些特定场景。5) 需求文档中所有的内容都应是确定的和无疑义的，应保证任何人通过阅读需求文档所得 出的理解是基本一致的。6) 任何在系统使用过程中可以录入的数据都不是需求的一部分。7) 对需求文档进行的任何修改都应留有历史记录，记录中应包含新增或修改的章节、修改 的内容、进行修改的时间和修改人的姓名。8) PO对需求文档中的内容拥有最终解释权。9) PO 需要提供的文档如下：必须提供的文档：需求文档非必须的文档：辅助其他人员理解需求的参考资料(比如行业规范，网站上的介绍，宣 传资料，自己做的图表等等)1.2. PD 的职责与义务1) PD 的职责为按照需求文档进行界
3、面和用户体验设计，输出产品为界面设计及相关说明 文档。2) 界面设计中应当完整体现需求文档中描述的全部功能。3) 界面设计不但应包含正常流程的界面和用户体验设计，也应当覆盖异常流程。4) 在不同页面中相同类型的元素(如：按钮、表格等)，其样式应保持一致。5) 界面设计应直接体现最终产品的静态显示效果。6) 界面设计如以原型或屏幕截图的方式提供，那么其中应提供一份对基本的使用流程及一 些功能上的重难点进行描述的说明文档。7) PD 对界面设计中用户体验及显示样式部分拥有最终解释权。8) PD 需要提供的文档如下：必须提供的文档：UI设计(静态图片或者Prototype再加上必要的文字说明) 非必
4、须的文档：暂无1.3. 开发人员的职责与义务1) 开发人员的职责为按照需求文档和界面设计文档进行产品框架和模块的设计与开发，输 出产品为可使用的软件产品。2) 最终的软件产品中应该完整包含需求文档中描述的全部功能。3) 最终的软件产品的界面样式应与界面设计基本一致，在界面排列及元素间间隔上允许有 一定的差异，但不应影响界面整体的美观。4) 开发人员需要提供的文档如下： 必须提供的文档：软件的开发设计文档(包括内部模块划分，接口设计，数据库设计等 等)，开发计划(可按迭代补全)非必须的文档：软件的部署(使用)说明，开发环境部署说明，测试数据等1.4. 架构组的职责与义务1) 管理非功能性需求。大
5、多数非功能性需求都是技术层面的，且对软件架构有很大影响的。 架构组要对系统的重用、扩展、安全、性能、伸缩性、简洁等做系统级的把握。2) 定义系统架构。理解系统业务需求和非功能性需求，在兼顾需求和限制的前提下，定义 软件架构，分解模块、层和组件，进行职责划分，确定最终系统使用特定技术部署到特 定的环境以后的样子等。3) 技术评估和选型。做出技术决策，确保团队朝着正确的方向前进。4) 评价和确认系统架构的实现。5) 全程参与。与开发团队及其它相关人紧密协作，参与所有与项目有关的会议：设计、开 发、评审、需求规划等，来保证架构和所在环境的无缝的集成。6) 指导团队架构和设计。架构组应做出具体的设计决
6、定，软件开发人员按照决定构建系统。 开发人员可能不接受架构组选择的设计模式，开发人员可以改进它，但还是最可能的按 照架构组的描述实现。7) 保证质量。保证质量是架构组的职责中很大的一部分。保证质量可以通过代码标准、设 计原则、持续集成、自动化单元测试和代码覆盖分析等实现。8) 编写代码和测试。架构组需要知道代码的质量如何，以便更好的理解架构设计对实现上 的影响。9) 参与改进Story、增加约束、完善描述和验收标准。在Scrum迭代开始前预先设计软件 架构，以便把设计涉及的Story “串接”起来。10) 架构组需要提供的文档如下： 必须提供的文档：架构设计文档(包括模块划分，接口设计，使用的
7、技术，部署方式等 等) 非必须的文档：其他辅助理解架构设计的图表，以及相关的学习资料2. 角色内协作行为规范2.1. PO 部分1) 需求文档的内容应该为整个 PO 团队的共同讨论和分析的结果，不应为某一人的产品。 要保证每个需求都是PO组达成的统一结果。2.2. PD 部分暂无2.3. 架构组和开发人员部分1) 在产品开发中应用的技术应该以稳定为主。任何对技术的选择应该并仅需获得架构师和 主要开发人员的一致意见，并且一个技术一经选定并应用到实际开发过程中，无正当合 理理由，不可更换。注 1 ：正当合理理由包括且不限于原技术功能不完整、有重大安全漏洞且通过对其维护 者的了解无法及时修复、严重的
8、性能问题等等。注 2：非正当合理理由包括且不限于原技术在不影响功能的前提下对系统的扩展性造成 负面影响、追求新技术但新技术与原技术为针对相似问题或领域的不同解决方案而非前 者是后者的升级版本。2) 产品的架构、数据库及主要功能模块的设计及相关的变动只有在获得架构师及全体开发 人员的一致同意后才可付诸实施。3) 任何开发人员在向代码库提交代码前必须对自己的改动进行编译和测试，以保证提交后 代码库中的代码可以通过编译并正常运行。4) 每一次提交应该包含开发人员本地的全部改动，而不可改动多处但只提交一处。5) 在提交重要的实现或改动前，开发人员应邀请至少一位其他的开发人员进行审核，以保 证提交代码的
9、质量。6) 开发人员进行生产活动的周期称为迭代，在其中需要完成指定的任务并输出一定的产品 一个迭代一般为两周。7) 在迭代的最后一天，全部开发人员应举行总结会，对整个迭代的开发过程、遇到的问题、 输出的产品进行评估和总结，以便改善后续的开发过程。8) 在总结会举行之前，该迭代的输出产品应该构建完毕并交付PO和测试人员。9) 计划会和总结会其他人员也可参加。2.4. 架构组部分1) 框架设计文档应该为整个架构组的共同讨论的结果。3. 跨角色协作行为规范3.1. 概述1) 各角色之间的协调、讨论和审阅应只针对对应角色的输出产品和相关的时间节点，不应 针对其生产对应产品的过程与方法。2) 一个角色的
10、下游角色是指在工作中需要使用本角色输出产品的角色，即 PO 的下游角色 为PD和开发，PD的下游角色为架构师/组和开发人员，架构师/组的下游角色为开发人 员，开发人员的下游角色为PO (注：因为开发的成果应由PO和PD进行确认)。3.2. 时间节点部分1) 项目管理中的时间节点包括交付需求文档、界面设计、软件产品的时间和交付内容，其 中按需要可以分别划分为阶段性的时间节点和最终的时间节点。2) 时间节点的设定应该充分考虑相关人员的技术能力和正常范围内的工作时间，并应留有 余地。3) 任何针对时间节点及对应节点输出产品内容的设定和变更应获得对应角色及其全部下 游角色负责人员的同意，未经同意的相关
11、变更无效。4) 任何由于上游角色延迟交付或部分交付产品而对下游角色的生产计划的影响，下游角色 的生产计划应顺延。3.3. 需求文档及产品设计部分1) 需求文档和产品设计在交付前应当得到相关下游角色负责人员的确认，经过确认的文档 或设计可以交付。2) 如果讨论双方对文档或设计中的内容无法达成一致，那么应参考第一章中对最终解释权 的描述进行解决。3) 任何通过口头、邮件、会议、Sametime等讨论方式得出的结论只在被添加至文档或设 计内并得到全部参与原讨论人员的确认后生效，而相关的确认必须使用邮件方式进行。 如某一角色中有多名人员参与了会议且其中包含对应角色的负责人员，可由角色的负责 人员进行统
12、一确认。未经文档化和最终确认的任何改动无效。4) 在计划会确定的一个迭代中的任务不得更改，如要更改，需要重开计划会议征得所有开 发人员和PD的同意。3.4. 软件产品部分1)软件产品的交付应该由PO和QA两个方面共同进行确认，在功能、界面、缺陷数等各 方面满足指定的要求。4. AiO-Scrum 实施规范4.1 几个必须的会议1） Release MeetingProduct owner负责发起Release planning会议，需要参加的是Architect,开发，PD,测 试的代表；PM可选参加（邀请人员要到位）。该会议的目标是指定一个产品开发周期 由几个release组成，每个rele
13、ase都要指定交付日程表。该会议结束时，应该有一个类 似下表一样的发布计划：ReleaseSprintSloriesGoals1. Relea&s #12. RPl豁滿 #21. Sprint #1 (Book)2. Sprint 桎(Fairon)Zory 叭3. Story #3d Story1Figure 7-9Tracing sprint goals* back to release goals （horizontai dicing）.2）Sprint PlanningProduct Owner负责发起Sprint planning会议，需要参加的是Architect、开发、PD和测
14、试的代表； PM 可选参加（邀请人员要到位）。这个会议该会议分为两阶段，第一阶段， 确定需求是什么，Product owner主导向整个team介绍这个sprint要实现的feature,根 据team的反馈来取舍，调整这些feature. Product owner对backlog的优先级进行排序， 然后挑选出合适的feature，发布到Redmine上；第二阶段，决定怎么实现需求， Development team 主导这个会议，从第一阶段的 feature 中，分解 task. 共同评估每个 task，比如task的完成的定义，涉及的技术细节，交付的结果，需要的工作小时。然后 再决定谁来
15、take这个task，谁是reviewer。这两个会议可以分开由各自主导方发起，但 是必须邀请上述各方（无论是required还是optional），在sprint之内如果需要取消该会 议，主导方必须经过参与方的同意。3）Daily ScrumDevelopment team 举行站立式的每日会议，开发和测试必须参加， PO 和 PD 可选，目 标是简短有效的交流。每天查看burn up或者burn down图来检查项目的整体进展。实 践中我们也可以交流遇到的技术难点和意料之外的情况。这是对Sprint planning会议结 果执行的每日考评。严格来说，不能修改/增加/减少已经定下的feature和task。如果 要修改，必须要product owner和team 一致同意，但是要非常慎重。这个由开发team 自由决定。4) Sprint Review由development team发起，而PO、PD必须参与的会议，PM可选参加。会议流程如下：a) 先讨论那些feature和task已经完成，侧重于feature层面b) 向product owner演示已经完成的featurec) product owner 可以介绍产品需求和市场是否有变化，从而为下阶段的 sprint 做好 准备下面的观点可作为实践的参考：a) 每个sprint review都是
