敏捷研发及质量保障

1、敏捷模式的核心在于人-所以人的主观能动性和专业能力相当重要。如果按企业CMM模型来看，个人觉得至少会满足CMM-4的团队采用敏捷比较顺利。
2、从当前团队成熟度和默切情况，以及当前阶段的任务要求出发，对我司开展敏捷进行一次梳理，以加速产品孵化过程。

1、通信领域需求相对比较大，包括RFC需求、解决方案级需求、产测需求、设计需求等，具体细分到story后仍然相对较大，此时建议以具体研发活动作为驱动动力，研发活动包括后续提到的设计、编码、测试、文案，大的模块或组件的活动还可以再一步进行阶段划分，通常以周作为活动节点或阶段节点，跨迭代的特性开发走专有特性开发，迭代发布流程。
2、CI作为敏捷的重要手段之一，而白盒测试则是CI的关键手段。建议CI在动态测试上采用黑盒进行基础功能覆盖+白盒异常分支覆盖相结合的方式。所以前期的敏捷开展也是开发和测试配对方式进行，互补互助的方式实现高效。
3、敏捷各项活动未进行显示节点划分，没有明显的边界。仅要求各项活动做到做好，由参与团队对整体活动进度和质量负责，而不是个人。同时各项活动项目不做计分考核，由PM及团队评价结果。

1、按上述思路，整体敏捷活动重心分为三个阶段：准备阶段、研发阶段、发布阶段。计划阶段和发布阶段的思路偏重于IPD方式，这一块对项目管理团队和技术专家团队的要求较高；而研发阶段主体仍然为迭代原型，中间加入了少量的关键质量活动，使研发同事轻装上阵，驾轻就熟。
2、准备阶段：进入迭代前的阶段，优先输出解决方案、需求分解、规格定义、总体方案及CBB需要（Product Manager&架构组），紧接着由PM组建研发团队（包括SE、PG、TT），提交项目计划（资源计划、质量计划、版本计划）。
3、研发阶段：迭代主体阶段，PM按计划带队管理，SE全程参与（系统/子系统级技术决策、问题攻关），PG\TT高效配对实施。主体阶段活动集中在进度和风险管控（PM/SE/TSE）、编码及评审（SE/PG)、用例及BUG（PG/TT)、特性交互评估（PM/SE/TSE/PG/TT)。多个迭代中间具备迭代回顾活动，一方面进行团队体整，另一方面进行下一个迭代的计划，重点是需求的更新。
4、发布阶段：产品使用阶段，严格来说分为发布前和发布后。发布前进行发布评审（包括市场、运维、服务、研发等代表），确定产品达到商用水平，确定产品已满足各方需求，会签发布产品；发布后按 “既定” 策略对产品进行生命周期管理。

1、需求来源于用户需求、解决方案需求、设计需求、产测需求、运维需求以及友商信息。所有需求必须统一进行跟踪（跟踪信息包括提出方、优先级、提出时间、期望提供时间、落地计划、是否完成、责任主体等）。
2、Product Manager根据各种需求优先级、结合市场紧急度和研发成本采纳需求，对需求进行落地实施。由SE为主体对将需求进行内部分解，根据实际情况输出解决方案、用户Story、内部特性、功能性能指标（规格）。
3、外部需求转化为内部需求之后，SE可进行总体方案设计，定义系统架构以及系统约束（规范类），输出模块/组件/特性分解及依赖关系。总体方案是各项活动中需要评审的内容，由架构组及SE&TSE团队负责。关键特性设计方案也可以在此阶段同步输出。
4、上述活动之后，产品需求以具备可实施的前提能力，由PMO指定Project Manager和SE启动项目，输出具体项目计划（成本计划-人力、设备；研发计划-特性、版本、迭代；质量计划-研发活动【设计、编码、测试、评审及衡量指标），组建研发团队，同步串讲转化后的需求，重要的需求进行反串讲。

1、特性设计：关键重要特性需要首先进行特性设计，特别是组件耦合度分析及交互接口、特性时序分析、DFX设计。测试相关组件不要求进行文档输出，但需要在特性设计中体现。超过2周的特性设计建议以带外开发带内迭代交互的方式进行，或者在迭代回顾阶段投入。
2、用例设计：与特性设计同步进行，但需要关注特性设计中关于DFX和组件耦合情况。用例测试可按测试思路分为基本功能、性能压力、DFX、故障注入等。（用例设计尽量细分，为自动化奠基，同时作为TDD参考）
3、编码&Review：编码活动包括结对编程、TDD、代码Review，结合实际情况来看，代码Review是现阶段最有效的方式之一，其次是TDD。敏捷代码Review重逻辑，轻规范，重点关注需求完成度、边界问题、时序问题，内存和CPU资源，通过代码Review工具实现边检边改。（版本加固迭代时，可组织代码找虫比赛来加固代码以及积累经验）
4、组件测试：开发自测活动（包括调试），可抽取部分基础测试用例进行特性覆盖，异常或边界分支可采用函数测试（打桩测试）-并纳入CI。
5、特性测试：TT介入阶段（代码上库测试），此时SE、TSE同步进行实时评估。特性测试期间建议TSE、SE同步输出测试周报，PM关注；SE组织关键问题攻关；PG配合测试分析问题、解决问题。
6、持续集成：持续集成覆盖静态检查和动态检查，静态检查包括代码逻辑分析和规范，动态检查以白盒测试和自动化测试为主，在此基础上发布初样稳定版本。CI几乎贯穿整个迭代周期，SE和PG需要关注CI红线问题，并推动CI问题收敛。
7、方案测试：整机测试和方案级测试，包括特性组合测试（组网）、三方接入测试、解决方案测试等。阶段上可分为室测和场测，场测需要开启灰度场区测试（实验局）。

1、C级用户应用敏捷开发通常能有效控制在3~6周，而B级平台应用往往很难达到，即使小步快跑的方式也需要6周。故而某些特性耗时并不取决于其功能大小，而是其复杂程度，诸如加密算法、架构调整，无参照新功能。
2、带外特性开发不局限于大特性开发，某些小特性开发也适用或CBB并入。
3、带外特性开发不意味着缺少管理，由SE指定特性开发负责人，同时具备PG和TT配对进行，并同时在迭代周期内关注带外特性进展和风险情况，归入迭代周期时需要进行评估决策。

1、产品文案：所有产品附件需要同步发布，包括技术白皮书、解决方案、命令手册、配置手册、故障排查手册、三方接入指导手册等。此活动在编码活动完成后即可进行（实际情况一般在特性测试完成之后）。
2、项目总结：此活动比较重要，可积累技术经验或总结可改进点，优化项目管理和技术实施方法。研发更多的需要对技术进行沉淀和总结。
3、技术支撑计划：包括两个方面，技术支撑团队的筹建以及产品培圳（SE，面向运维和营销体系的培圳）。
4、发布评审：再次对产品需求满足度和充分性进行考量，要示各领域代理出席评估。
5、灰度发布：正式发布前的实施局部分（如果条允许），产品小批量上线进行市场初检。
6、版本维护：版本生命周期管理，主要是市场问题（包括新增需求）处理。

1、需求澄清：贯穿整个敏捷开发过程，分解需求（准备阶段）->开发规格（迭代阶段）->验证规格（迭代阶段）->修正规格（迭代阶段）->更新规格（回顾阶段）->发布规格（发布阶段）。PM关注整个开发活动中，需求遗漏&变更清况，以对项目计划进行调整。
2、代码审查：包括代码变更评估和特性代码合入评估，前者现阶段由CI和测试配对保证，后者由开发团队主导对核心关键模块进行Review，工具支撑组提供快捷在线的代码审查工具。同时，代码审查同步分析代码量、审查DI、时间消费后得出审查结论，以作为风险指标之一；
3、每日站会：以特性研发小组作为立会单元，贯穿整个业务线，做到上下层情报同步，开发测试高度配合。可指定特性负责人组织并汇报特性进展情况，关注各成员遇到的问题并反馈给PM、SE。
4、测试评估：TSE以周报的形式（测试密积期一周可进行2次）同步分析BUG情况（特对是高危BUG和低级BUG）给出测试建议，同时关注下BUG解决率，并根据风险情况对测试方案进行调整。
5、交互准入：带外特性进行专项准入评估，带内特性由于实时跟进，不需要专项评估（使用过程评估），但需要有代码的准入计划，避免无序代码合入到开发主干。
6、版本管理：版本管理包括代码分支管理（if exsists），包括版本支持的功能，新增的特性，发布时间，遗留BUG、对应代码分支等。

需求收集：覆盖解决方案级需求、用户应用需求、RFC需求、设计需求（含CBB）、测试需求、文案需求、竞品需求。需求收集是整个业务周期的自循环活动，不依赖于产品实施。
需求分解：需求分解为规格，分为功能规格和性能规格，并落实到相应特性/组件开发活动中。
需求串讲：用户核心需求进行串讲和反串讲，由SE主导实施，进一步理解用户需求，避免偏差。
验证需求：以测试用例设计和驱动作为需求验证的关键手段，大多测试需求可来源于此活动。
回顾&发布需求： 重点在需求调整，包括对内迭代需求调整、更新，对外的需求再确认（需求提出方）。

1、代码审查以SE和PG为主，由代码审计工具支撑One by One的问题发现和解决，高效推动代码审计过程。在举办代码审计比赛时，可将相对比较公共的特性作为审查对象，对全员进行开放，一方面加强了特性代码质量，另一方面对团队技术提升比较明显，离不开工具的高效性和可视性。
2、需要注意的是整个审查过程与开发自测重叠，理论上对开发进程没有影响，瓶颈点审查人（SE）的工作安排上。

1、站会邀请特性开发活动中涉及到的所有开发、测试及SE参加。
2、站会做到相关各组件情况的可视化，同时开发测试紧密配合。
3、站会以沟通活动进度和风险为主，但不进行讨论，汇报专项问题或风险由SE/PM处理。
4、站会规则：时间控制15分钟，全员就位，按顺汇报，风险反馈。

1、TSE：关注测试面BUG情况，如BUG走势是否符合预期、组件BUG分布是否正常、BUG解决情况，梳理阻塞性BUG、高风险组件并针对性进行测试方案调整。
2、SE：关注开发面BUG情况，如BUG引入情况、低级BUG的共性问题触发开发环节的活动改进；高级BUG的跟踪以及攻关处理；关注TSE梳理的阻塞性BUG和高风险组件。
3、PM：跟进测试周报，针对非可容性风险适当调整项目计划（人力、成本、时间）。

1、交互准入侧重于带外特性开发，需要同时关注准出和准入条件；带内特性至少需要关注准入条件。交互准入以简单的checkList方式进行，两者都由开发自检，但带外需要SE复检并评估。
2、测试活动已完成的交互准入，需要TSE同时进行评估。

1、带外特性：在合适节点打出开发分支进行专项特性开发，完成后经交互准入合入迭代主干。
2、测试发布：同时发送固件及代码（以TAG形式发布），以及功能清单、BUG解决清单。
3、受限发布：（灰度发布）开辟实验局或试用网点时发布相对正式的固件版本，需要打出开发分支以解决可能的紧急问题，并在下一个迭代时归入&终结到迭代主干。
4、正式发布：经灰度发布后并经过一定的版本加固，产品满足一定的商业需求进行正式销售，此时所有文案具备，并且代码以分支形式发布，发布分支可能会经过若干迭代周期后，由于不满足客户需求而终结，满足客户新需求的产品再次在后续迭代主干发布。正式发布版本在生命周期内，需要解决影响客户使用的紧急问题，并将这些问题合入到迭代主干；同时，如果在迭代主干上发现发布的正式分支存在的严重缺陷，仍然需要触发发布分支的同步解决，解决的方式以最小代价为前提。