打造高效的前后端分离项目团队
《打造高效的前后端分离项目团队》目标：制定及实现统一的标准化高效前后端分离项目实施流程培养建立公司内部的阶梯性前端人才资源
二、项目需求把控三、技术方案制定四、高效协同化实施五、自测与发布准备一、开发流程优化与角色划分
开发流程优化与角色划分敏捷赋予了我们什么？仅仅依靠敏捷就够了吗？Scrum！敏捷开发迭代需求敏捷一直被追宠，她让我们比10年前的确有所进步；但在问题最多的具体实施层面，敏捷能做的实在有限，甚至不足！如何让每个人力资源高效协同实施、发挥最大潜能，最终形成制度规范，才是我们最为重要的改进方向；-敏捷并未“死”去，前提是我们必须加以补救!...协同实施+精细化模块迭代测试迭代实施角色化制度工具宏观制度流程具体实施方法
开发流程优化与角色划分为什么要角色划分？要接受资源能力不平衡的事实，让每个开发人员做最擅长的事才能高效，切勿拔苗助长；不是每个人都对需求能领悟透彻，也不需要每个人都能理解；关键在架构师层面我们能把控和梳理整个需求，而后由架构师统一设计和下发组件(卡片)任务块TASK；每个实施小组划分三种角色-架构师、工程师、测试人员；三者大致按2:5:1的比例配合前端架构师前端工程师后端工程师测试人员后端架构师1:21:3251架构师-工程师-测试人员三者至多协同人数比大约为2:5:1，适合以两周一迭代规模项目团队；如工程师人数增加，则架构师及测试人员亦需等比增加并加以分组需求分析/把控技术方案交互协同图模块分工组件UI数据渲染组件事件触发接口实现数据源配置测试用例测试实施服务协议
需求评审开发流程优化与角色划分-主线流程单个迭代实施主线流程需求评定(15%)架构师工程师测试人员概要设计(35%)开发实施/联调(65%)测试/部署(40%)与BA进行需求PK；把控、梳理及输出最终需求；参与需求会议，并与架构师一并进行需求评定；参与需求会议，掌握最终业务需求单个迭代周期最终需求文档协议文档交互协同图技术方案(可选)组件(卡片)/页面测试用例数据源配置输出内容测试报告/问题清单模型配置UAT环境部署以组件(卡片)为单位陆续输出“交互协同图”并分派[前端]根据交互协同图陆续输出协议文档(数据源配置)[后端]根据陆续输出的“交互协同图”，实现组件(卡片)内部渲染及事件触发[前端]修复BUG核心模块实施编写测试用例测试并输出测试报告及问题清单根据陆续输出的协议文档实现服务接口[后端]基于US功能联调根据陆续输出的“交互协同图”，实现组件(卡片)事件交互及模型映射[前端]建表/后端基础实施[后端]UAT部署核心模块联调修复核心模块BUG技术方案方案评审
二、项目需求把控三、技术方案制定四、高效协同化实施五、自测与发布准备一、开发流程优化与角色划分1）需求至简，敢于说“No!”2）剖析业务真实用意及痛点3）建立需求回述及评审机制
需求至简，敢于说“No!”在满足业务需求基础上，尽可能的简化需求复杂度；将复杂逻辑拆解至可独立处理逻辑单元；切勿追求及接受“大而全”，“简而精”才是合理的开发逻辑；面对复杂度过高或不合理需求均可说“No!”提出异议，并给出其他方案定位；只要是为了更好的实施，对复杂核心需求的质疑无论对客户还是合作方均能得到益处；很多项目往往是前期需求未把控到位，导致实施中途方案变更，直接影响项目进展；有效把控需求极其重要1个失控需求引发的问题需求开发代价过高-直接导致PO层面遭受损失，同时破坏客户关系稳定；需求技术层面存在瓶颈-导致项目实施延期，甚至返工；需求逻辑错误-导致项目实施困难，影响到其他关联模块，并可能导致一并返工；需求复杂度过高，无拆分-导致项目实施困难，出错率激增，问题迟迟难以解决，项目延期严重；需求把控不到位，将导致许多项目问题，可直接影响整个项目的成败；应当将此类风险扼杀在需求评定阶段；提前说“No!”
剖析业务真实用意及痛点不是所有BA都能掌握业务真实需求，不是所有BA都能百分百传达业务真实需求至实施团队；很多关键需求需要实施层面进行反馈及发出质疑，以此避免后期实施变更；当需求较为复杂（很多情况是以往设计不合理导致）或逻辑混乱，客户又难以被PK而妥协该方案；此时应该将BA或客户引入提炼该需求背后的真实业务需求；高度复杂或逻辑混乱的需求背后必定可拆分出业务的真实需求；需求A1需求A2需求A3需求B1(复杂度高)需求A5需求B2(逻辑混乱)业务人员实施团队BA了解和掌握业务的真实需求和痛点BA直接将由真实业务需求导致的复杂需求灌输给实施团队，真实数据反被忽视需求A4真实需求衍生出其他复杂需求
建立需求回述及评审机制对于核心需求点，需要在需求会议阶段，进行评审及回述；1、使开发团队对需求有较深掌握，将风险扼杀在需求阶