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. 架构组部分1) 框架设计文档应该为整个架构组的共同讨论的结果。3. 跨角色协作行为规范3.1. 概述1) 各角色之间的协调、讨论和审阅应只针对对应角色的输出产品和相关的时间节点，不应针对其生产对应产品的过程与方法。2) 一个角色的下游角色是指在工作中需要使用本角色输出产品的角色，即PO的下游角色为PD和开发，PD的下游角色为架构师/组和开发人员，架构师/组的下游角色为开发人员，开发人员的下游角色为PO（注：因为开发的成果应由PO和PD进行确认）。3.2. 时间节点部分1) 项目管理中的时间节点包括交付需求文档、界面设计、软件产品的时间和交付内容，其中按需要可以分别划分为阶段性的时间节点和最终的时间节点。 2) 时间节点的设定应该充分考虑相关人员的技术能力和正常范围内的工作时间，并应留有余地。3) 任何针对时间节点及对应节点输出产品内容的设定和变更应获得对应角色及其全部下游角色负责人员的同意，未经同意的相关变更无效。4) 任何由于上游角色延迟交付或部分交付产品而对下游角色的生产计划的影响，下游角色的生产计划应顺延。3.3. 需求文档及产品设计部分1) 需求文档和产品设计在交付前应当得到相关下游角色负责人员的确认，经过确认的文档或设计可以交付。2) 如果讨论双方对文档或设计中的内容无法达成一致，那么应参考第一章中对最终解释权的描述进行解决。3) 任何通过口头、邮件、会议、Sametime等讨论方式得出的结论只在被添加至文档或设计内并得到全部参与原讨论人员的确认后生效，而相关的确认必须使用邮件方式进行。如某一角色中有多名人员参与了会议且其中包含对应角色的负责人员，可由角色的负责人员进行统一确认。未经文档化和最终确认的任何改动无效。4) 在计划会确定的一个迭代中的任务不得更改，如要更改，需要重开计划会议征得所有开发人员和PD的同意。3.4. 软件产品部分1) 软件产品的交付应该由PO和QA两个方面共同进行确认，在功能、界面、缺陷数等各方面满足指定的要求。4. AiO-Scrum实施规范4.1 几个必须的会议1) Release MeetingProduct owner负责发起Release planning会议，需要参加的是Architect， 开发，PD，测试的代表；PM可选参加（邀请人员要到位）。该会议的目标是指定一个产品开发周期由几个release组成，每个release都要指定交付日程表。该会议结束时，应该有一个类似下表一样的发布计划：2) Sprint PlanningProduct Owner负责发起Sprint planning会议，需要参加的是Architect、 开发、PD和测试的代表；PM可选参加（邀请人员要到位）。这个会议该会议分为两阶段，第一阶段，确定需求是什么，Product owner主导向整个team介绍这个sprint要实现的feature, 根据team的反馈来取舍，调整这些feature. Product owner对backlog的优先级进行排序，然后挑选出合适的feature，发布到Redmine上；第二阶段，决定怎么实现需求，Development team主导这个会议，从第一阶段的feature中，分解task. 共同评估每个task，比如task的完成的定义，涉及的技术细节，交付的结果，需要的工作小时。然后再决定谁来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都是一次内部的产品发布，因此介绍和演示团队在产品上取得的进展是主要内容，而不要变成具体每个task的讨论。更不需要每个developer来轮流演示自己的task.b) 没有完成的feature和task需要仔细讨论原因，寻找经验和教训。是否因为目标定的太多没有给团队留下余量，通常我们都会对目标工作量打8折作为实际工作量，是否高估或者低估了技术问题。比如一个没有想到的用户体验问题引入了一连串的技术解决方案。5) Sprint Retrospective Development team在Sprint review会议之后和下一个sprint planning会议之前，developers和PD，PO代表是required参加，其他PM等可选参加。召开这个会议的目的是，总结经验教训，提出在后面的sprint 需要改进的地方。这个阶段每个developer可以轮流阐述自己的观点，遵照下面的流程：a) What have you done in the last sprint?这部分内容可以简单快速，因为实践中每个task都会被review后才视为结束。b) What unsolved problems have you found?这部分有效的内容将加入到backlog中。c) Share your suggestions about process, technique.这部分有效的内容也将加入到backlog中。d) Adjust focus factor在会议中，需要针对现有团队的Sprint实施情况，决定下一个Spirit的Focus Factor。4.2 其他实践1) 单元测试a) 只为公有接口编写单元测试b) 包含边界情况c) 提交代码之前，执行单元测试，不提交没通过单元测试的代码d) 维护测试代码2) 代码reviewa) 每次提交有人review，记录review人员的信息在commit message中。不提交没有经过review的代码。b) 在特殊情况下，酌情选择多人review。例如临发布，重要更改，疑难bug的修复等。5. 代码管理和发布规范除了日常管理，强调我们容易出错的流程1) 对每个项目架设专门的编译测试服务器。服务器的功能至少包括，周期性（比如说一小时）更新最新的代码，编译整个工程，如果编译不通过自动发邮件提示所有开发者注意。服务器的功能最好包括，对编译出来的结果作最基本的自动测试，比如说尝试运行系统看是否成功，导入数据库脚本看是否出错。如果有