- 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
- 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
角色分工、职责与义务
本流程内按不同的职责将人员划分为四个角色:PO(Product Owner),PD(Product Designer)和开发人员和架构组(Architect)。
PO的职责与义务
PO的职责为收集提出的需求并对其进行分析,输出产品为可以直接应用于产品设计与开发的需求文档。
需求文档是产品设计与开发过程中针对产品功能的唯一参考文档。
需求文档应当包含产品设计和开发中需要使用到的全部功能性信息,包括且不限于主要功能模块划分、详细用例描述、系统输入与输出数据的定义等等。
需求文档必须为针对客户需求进行分析总结的结果,其中对功能的描述应具有通用性,而不应仅针对用户提出某些特定场景。
需求文档中所有的内容都应是确定的和无疑义的,应保证任何人通过阅读需求文档所得出的理解是基本一致的。
任何在系统使用过程中可以录入的数据都不是需求的一部分。
对需求文档进行的任何修改都应留有历史记录,记录中应包含新增或修改的章节、修改的内容、进行修改的时间和修改人的姓名。
PO对需求文档中的内容拥有最终解释权。
PO需要提供的文档如下:必须提供的文档:需求文档非必须的文档:辅助其他人员理解需求的参考资料(比如行业规范,网站上的介绍,宣传资料,自己做的图表等等)
PD的职责与义务
PD的职责为按照需求文档进行界面和用户体验设计,输出产品为界面设计及相关说明文档。
界面设计中应当完整体现需求文档中描述的全部功能。
界面设计不但应包含正常流程的界面和用户体验设计,也应当覆盖异常流程。
在不同页面中相同类型的元素(如:按钮、表格等),其样式应保持一致。
界面设计应直接体现最终产品的静态显示效果。
界面设计如以原型或屏幕截图的方式提供,那么其中应提供一份对基本的使用流程及一些功能上的重难点进行描述的说明文档。
PD对界面设计中用户体验及显示样式部分拥有最终解释权。
PD 需要提供的文档如下:必须提供的文档:UI设计(静态图片或者Prototype再加上必要的文字说明)非必须的文档:暂无
开发人员的职责与义务
开发人员的职责为按照需求文档和界面设计文档进行产品框架和模块的设计与开发,输出产品为可使用的软件产品。
最终的软件产品中应该完整包含需求文档中描述的全部功能。
最终的软件产品的界面样式应与界面设计基本一致,在界面排列及元素间间隔上允许有一定的差异,但不应影响界面整体的美观。
开发人员需要提供的文档如下:必须提供的文档:软件的开发设计文档(包括内部模块划分,接口设计,数据库设计等等),开发计划(可按迭代补全)非必须的文档:软件的部署(使用)说明,开发环境部署说明,测试数据等
架构组的职责与义务
管理非功能性需求。大多数非功能性需求都是技术层面的,且对软件架构有很大影响的。架构组要对系统的重用、扩展、安全、性能、伸缩性、简洁等做系统级的把握。
定义系统架构。理解系统业务需求和非功能性需求,在兼顾需求和限制的前提下,定义软件架构,分解模块、层和组件,进行职责划分,确定最终系统使用特定技术部署到特定的环境以后的样子等。
技术评估和选型。做出技术决策,确保团队朝着正确的方向前进。
评价和确认系统架构的实现。
全程参与。与开发团队及其它相关人紧密协作,参与所有与项目有关的会议:设计、开发、评审、需求规划等,来保证架构和所在环境的无缝的集成。
指导团队架构和设计。架构组应做出具体的设计决定,软件开发人员按照决定构建系统。开发人员可能不接受架构组选择的设计模式,开发人员可以改进它,但还是最可能的按照架构组的描述实现。
保证质量。保证质量是架构组的职责中很大的一部分。保证质量可以通过代码标准、设计原则、持续集成、自动化单元测试和代码覆盖分析等实现。
编写代码和测试。架构组需要知道代码的质量如何,以便更好的理解架构设计对实现上的影响。
参与改进Story、增加约束、完善描述和验收标准。在Scrum 迭代开始前预先设计软件架构,以便把设计涉及的Story“串接”起来。
架构组需要提供的文档如下:必须提供的文档:架构设计文档(包括模块划分,接口设计,使用的技术,部署方式等等)非必须的文档:其他辅助理解架构设计的图表,以及相关的学习资料
角色内协作行为规范
PO部分
需求文档的内容应该为整个PO团队的共同讨论和分析的结果,不应为某一人的产品。要保证每个需求都是PO组达成的统一结果。
PD部分
暂无
架构组和开发人员部分
在产品开发中应用的技术应该以稳定为主。任何对技术的选择应该并仅需获得架构师和主要开发人员的一致意见,并且一个技术一经选定并应用到实际开发过程中,无正当合理理由,不可更换。注1:正当合理理由包括且不限于原技术功能不完整、有重大安全漏洞且通过对其维护者的了解无法及时修复、严重的性能问题等等。注2:非正当合理理由包括且不限于原技术在不影
原创力文档


文档评论(0)