Scrum开发流程最佳实践

1.角色分工、职责与义务

本流程内按不同的职责将人员划分为四个角色：PO（Product Owner），PD（Product Designer）和开发人员和架构组（Architect）。

1.1.PO的职责与义务

1)PO的职责为收集提出的需求并对其进行分析，输出产品为可以直接应用于产品设计与

开发的需求文档。

2)需求文档是产品设计与开发过程中针对产品功能的唯一参考文档。

3)需求文档应当包含产品设计和开发中需要使用到的全部功能性信息，包括且不限于主要

功能模块划分、详细用例描述、系统输入与输出数据的定义等等。

4)需求文档必须为针对客户需求进行分析总结的结果，其中对功能的描述应具有通用性，

而不应仅针对用户提出某些特定场景。

5)需求文档中所有的内容都应是确定的和无疑义的，应保证任何人通过阅读需求文档所得

出的理解是基本一致的。

6)任何在系统使用过程中可以录入的数据都不是需求的一部分。

7)对需求文档进行的任何修改都应留有历史记录，记录中应包含新增或修改的章节、修改

的内容、进行修改的时间和修改人的姓名。

8)PO对需求文档中的内容拥有最终解释权。

9)PO需要提供的文档如下：

必须提供的文档：需求文档

非必须的文档：辅助其他人员理解需求的参考资料（比如行业规范，网站上的介绍，宣传资料，自己做的图表等等）

1.2.PD的职责与义务

1)PD的职责为按照需求文档进行界面和用户体验设计，输出产品为界面设计及相关说明

文档。

2)界面设计中应当完整体现需求文档中描述的全部功能。

3)界面设计不但应包含正常流程的界面和用户体验设计，也应当覆盖异常流程。

4)在不同页面中相同类型的元素（如：按钮、表格等），其样式应保持一致。

5)界面设计应直接体现最终产品的静态显示效果。

6)界面设计如以原型或屏幕截图的方式提供，那么其中应提供一份对基本的使用流程及一

些功能上的重难点进行描述的说明文档。

7)PD对界面设计中用户体验及显示样式部分拥有最终解释权。

8)PD需要提供的文档如下：

必须提供的文档：UI设计（静态图片或者Prototype再加上必要的文字说明）

非必须的文档：暂无

1.3.开发人员的职责与义务

1)开发人员的职责为按照需求文档和界面设计文档进行产品框架和模块的设计与开发，输

出产品为可使用的软件产品。

2)最终的软件产品中应该完整包含需求文档中描述的全部功能。

3)最终的软件产品的界面样式应与界面设计基本一致，在界面排列及元素间间隔上允许有

一定的差异，但不应影响界面整体的美观。

4)开发人员需要提供的文档如下：

必须提供的文档：软件的开发设计文档（包括内部模块划分，接口设计，数据库设计等等），开发计划（可按迭代补全）

非必须的文档：软件的部署（使用）说明，开发环境部署说明，测试数据等

1.4.架构组的职责与义务

1)管理非功能性需求。大多数非功能性需求都是技术层面的，且对软件架构有很大影响的。

架构组要对系统的重用、扩展、安全、性能、伸缩性、简洁等做系统级的把握。

2)定义系统架构。理解系统业务需求和非功能性需求，在兼顾需求和限制的前提下，定义

软件架构，分解模块、层和组件，进行职责划分，确定最终系统使用特定技术部署到特定的环境以后的样子等。

3)技术评估和选型。做出技术决策，确保团队朝着正确的方向前进。

4)评价和确认系统架构的实现。

5)全程参与。与开发团队及其它相关人紧密协作，参与所有与项目有关的会议：设计、开

发、评审、需求规划等，来保证架构和所在环境的无缝的集成。

6)指导团队架构和设计。架构组应做出具体的设计决定，软件开发人员按照决定构建系统。

开发人员可能不接受架构组选择的设计模式，开发人员可以改进它，但还是最可能的按照架构组的描述实现。

7)保证质量。保证质量是架构组的职责中很大的一部分。保证质量可以通过代码标准、设

计原则、持续集成、自动化单元测试和代码覆盖分析等实现。

8)编写代码和测试。架构组需要知道代码的质量如何，以便更好的理解架构设计对实现上

的影响。

9)参与改进Story、增加约束、完善描述和验收标准。在Scrum 迭代开始前预先设计软件

架构，以便把设计涉及的Story“串接”起来。

10)架构组需要提供的文档如下：

必须提供的文档：架构设计文档（包括模块划分，接口设计，使用的技术，部署方式等

等）

非必须的文档：其他辅助理解架构设计的图表，以及相关的学习资料

2.角色内协作行为规范

2.1.PO部分

1)需求文档的内容应该为整个PO团队的共同讨论和分析的结果，不应为某一人的产品。

要保证每个需求都是PO组达成的统一结果。

2.2.PD部分

暂无

2.3.架构组和开发人员部分

1)在产品开发中应用的技术应该以稳定为主。任何对技术的选择应该并仅需获得架构师和

主要开发人员的一致意见，并且一个技术一经选定并应用到实际开发过程中，无正当合理理由，不可更换。

注1：正当合理理由包括且不限于原技术功能不完整、有重大安全漏洞且通过对其维护者的了解无法及时修复、严重的性能问题等等。

注2：非正当合理理由包括且不限于原技术在不影响功能的前提下对系统的扩展性造成负面影响、追求新技术但新技术与原技术为针对相似问题或领域的不同解决方案而非前者是后者的升级版本。

2)产品的架构、数据库及主要功能模块的设计及相关的变动只有在获得架构师及全体开发

人员的一致同意后才可付诸实施。

3)任何开发人员在向代码库提交代码前必须对自己的改动进行编译和测试，以保证提交后

代码库中的代码可以通过编译并正常运行。

4)每一次提交应该包含开发人员本地的全部改动，而不可改动多处但只提交一处。

5)在提交重要的实现或改动前，开发人员应邀请至少一位其他的开发人员进行审核，以保

证提交代码的质量。

6)开发人员进行生产活动的周期称为迭代，在其中需要完成指定的任务并输出一定的产品，

一个迭代一般为两周。

7)在迭代的最后一天，全部开发人员应举行总结会，对整个迭代的开发过程、遇到的问题、

输出的产品进行评估和总结，以便改善后续的开发过程。

8)在总结会举行之前，该迭代的输出产品应该构建完毕并交付PO和测试人员。

9)计划会和总结会其他人员也可参加。

2.4.架构组部分