打造工业级 App 开发流程 (JIRA+CI/CD)
本文不光是方法论，更有工作中的最佳实践，以此来解决和回答以下问题。
如何实现从想法到产品的快速落地
如何保证在团队高速发展时，开发效率依旧高效
如何保证快速迭代时，依旧高质量的交付
如何保证执行层面的公开透明
如何体现团队或个人价值
如何将产出量化
为了回答上述问题，我们需要先熟悉以下概念和工具
开发流程
虽然接下来要讨论的是移动端的实践，但实际上针对其它场景，流程极其相似。主要包括：
需求定义，评审，功能拆分，方案设计，开发，代码审核，CI/CD, 黑/白盒测试，上线发布这一套标准的工作流。
如果针对更大的需求/项目，还需要引入项目评审，优先级评审，跨部门合作评审 (依赖梳理), L1 (估难易度), L2 (细化的成本估计) ，RoadMap 制定，Milestone 设定，集成测试，灰度验收等等。
如何根据不同的阶段，制定合理的开发流程，和高效的资源利用?
我们知道，在软件开发中最重要的资源是人，其次是沉淀的技术。这些资源需要根据产品所处的不同阶段，进行不同的分配策略，再配合不同的流程，来保证产品的快速交付。
通常情况下，我们将产品分三个阶段: 产品原型期（初期），发展期（中期），成熟期（后期）。下面分别介绍一下。
产品原型期，也就是从 0 到 1 的阶段
在这个阶段，团队规模越小越好，人员越精干越好，开发可以身兼测试。
技术栈选型不用太受限，也不用过于追求极致性能和体验，即使大量三方库的使用也是允许的。但有一点要注意，需要管理好它们，能封装的就封装一层，以便将来替换。同时，切记不要盲目引入，尽量采用主流的开源框架。
针对核心功能点，保证其有完整的开发流程覆盖，其它非核心需求不用重流程。什么是核心功能？需要根据不同的产品来定义。例如电商类产品中，账号体系，商品成列，交易属于核心，尽量走完整 Scrum 流程。其它非核心功能，比如样式，设置，启动画面，频道，可以放在一个大的 Task 或 Story 统一管理即可。
一句话总结就是，小而精，轻而快。
在产品发展期，也就是从 1 到 10 阶段。
团队的规模依然需要保持精干，以资深为主，需要配合专业的测试人员。
技术选型需要配合产品的需求，有清晰的方向。对三方库的使用、二方库的开发需要有针对性。比如对于电商类产品 ，不要花太大力气在动画和交互上，而针对核心交易流程，商品展示，需要有可沉淀下来的模块。在这个阶段中，核心功能技术方案需要团队自主完成，足够掌握，有充分的灵活性便于将来扩展，不要追求流行的框架。如果技术沉淀不够，可以继续使用三方库，但一定要花大力气逐步替换。
回到开发流程，到这个阶段人员已有一定的增长，可以尝试从业务或技术方向进行模块化划分，如果是5人以下的团队就不用切了。如果超过此规模，可以从业务角度或技术角度进行切分，Scrum 模式依旧可以继续使用。产品需求和技术需求流程基本类似，只是在技术需求上，产品经理就是开发，对开发人员有一定的文档写作能力要求，这也是为将来做更大规模的重构和架构设计奠定基础。当拆出来的团队有两个以上时，团队之间的依赖尽量在其中一个团队中独立完成，换句话说，这个人或团队需要有端到端的设计和交付能力，尽量避免出现一个功能卡在另一个团队中。这也是为了让大部分人都能端到端完成开发，而不是只做自己的一亩三分地。所以这个时候 Scrum 团队里的一些成员，有可能是在某个 Sprint 中是临时存在的，当相关任务结束后，成员自然回到各自的团队中。
一句话总结就是，确定技术方向，沉淀核心技术，建立跨团队的开发模式。
产品成熟期，也就是从 10 到 100+ 阶段。
基本上产品已成型，也获得了市场认可。团队的规模可以根据对未来市场的增长规模，产品的规划，逐步增加人员，这个时候人员的增加是梯队式的，有资深，中级，初级，还有架构师，Release 工程师，配管等等，根据需要设定岗位和人员。
这个时候的技术选型关注点更多是在体验和系统扩展能力上，及开发效率上。模块化也好，性能优化也好，体验升级也好要做的事情很多，但核心还是一点，根据产品的核心卖点，重点投入人力，千万不要面面俱到。比如在还没有基础库时，就开始花大力气研究模块化，要搞模块化，先要搞清楚如何切，模块与模块间的信息如何交互，协议如何制定，如何自测集成之后再来想这些事。你可以看到其中一些事情，在基础打好后，做起来就会很自然，千万不要本末倒置。如果你的产品是展示型的，建议花力气在信息的动态化，个性化上，无论是推荐算法还是自动化配管，总之能提升核心产品体验和用户粘性上的事更为合适。
另外，在开发效率上，我通常的做法是定期讨论，目前开发过程中的 Top 3 瓶颈，然后评估开发成本，制定优先级，列为技术债。和产品沟通后，依次排期解决，让团队看到短期和长期的目标与方向。
在这个阶段的开发流程，会稍复杂一些，但还是会遵循 Scrum 模式，只是会更加规范化，并引入上面所列到的项目评审，部门和团队间的评审，从Idea -> initiative -> L1 -> L2 -> Epic -> Story -> Task 等一系列不同阶段下，讨论出相应 scope 的定义与计划。而且会以月为单位，并在当月讨论评估下个月的需求，或下下个月的需求。这其中还会有需求锁定期，可变更期等等规则，目的是为了使将下来的开发紧紧有条。在这个阶段，需要产品，开发，PM 都有统一的意识。如果大家按同样的节奏，多大的需求都会运转的紧紧有条，心中有数。另外在执行过程中，可以利用一些工具，比如 JIRA 。它还会自动产出各种报告，满足不同人员想看到的各种数据，让执行过程完全透明。后面会有例子展出。
一句话总结就是，开发模式先行，稳而不乱，培养合作意识。
实践
上面谈到是很多理论知识，下面我们来看看如何基于敏捷流程和 JIRA 工具，进行需求分析，跟踪，任务拆解，执行情况跟踪，上线计划，报告产出等的工作流。
首先对于敏捷团队，有哪些会议是必要的?
我们以 Sprint 为单位，通常两周为一个 Sprint，围绕每个 Sprint 会有几个必要的会议需要团队成员参加。
Sprint Planning Meeting (1小时)
Sprint Refinement Meeting (2小时)
Sprint Review Meeting (半小时)
而之后，每个 Sprint 的第一天，会以 Sprint Planning Meeting 开始，所有的开发，产品会在这个会议上，根据上个月 Refinement Meeting 得出的 Story 或 Task 的 Point (复杂度)加上 team 的平均速度（velocity）进行评估，决定在这个 Sprint 中目标是什么，哪些要做，哪些不做，他们的优先级是什么等等，让每个人都知道要做什么，不做什么，目标是什么。
Sprint 开始后，通常在第二周的第一天，通常这个时候紧张的工作告一段落，我们可以利用这个时候去理解下个 Sprint 我们要做的内容，评估每个 Story/Task 的点数。这个会议中同样也需要产品和开发都参与其中，如果有任何不清楚，或需要进一步评估的，都可在下个 Sprint Planning Meeting 开始前进行修正。
在 Sprint 最后一天，通常是在第二周最后一个工作日，我们的 Sprint 里的任务都完成了，现在可以叫上产品和所有相关人员，一起回顾我们所做的内容，通常由这里的最高的管理者，决定是否可最终发布。同时也让所有人了解到将要上线的新特性和成果。注意，这里只是通盘回顾，让大家看看是否完成 Sprint 初所设定的目标。实际上每个任务之前都已走完所有的流程，包括测试，验收等。
每个会议上讨论的内容和模式其实也是有讲究的，为了保证高效，信息传达准确，所有人理解都一样，通常有几点需要注意。
首先在 Sprint 会议前，意味着大的 Epic 甚至 initiative，每个人都已经听过，或多少了解了，这样保证大家知道我们的大方向是什么。另外在到 Sprint 之前，Leader 或者 Manger 已经计划了整个团队的开发目标和计划，可能比较粗，但基本是基于这个前提进行的 Sprint 切分，比如三个月，或一个月要做什么，而且产品或市场人员也有所了解，这个时间通常是根据以往经验得出。
其次在 Sprint 会议上，讨论的 Story Point 不要超过目标 Team 的平均产量，讨论多了，基本上也排不进来，少了会有空档期出现。所以这里往往要结合以往的数据，和 Leader 的经验，挑选出可以讨论或必需讨论的内容。数据我们可以在后面的 JIRA 工具中帮我们自动整理出，目的是为了能让大家保持高效、稳健的实现目标，甚至持续增长。
如果一个 Story 太大，需要继续拆分成多个，直到每个 Story 可以端到端（end to end）测试验收，而且要保证拆出来的 Point 最大也不要超过 8（Point 是斐波那契数列，1,3,5,8,13 为单位）。这样是为了每个 Story 可以按时完成，并且可以早期看到可能的风险和依赖。
在 Sprint 开始的过程中，如果有需求变更，通常处理有两种方式。
针对需求的增量变更，需要新建一个新增部分的 Story ，并和 leader , 开发，测试人员沟通，评估 Point，如果 team 能保证在这个 sprint 里完成的话，可以将它拖到这个 Sprint 里来。
如果是修改，或删除某个 Story, 同样需要找到 leader 和开发沟通，评估优先级。在评估优先级前，需要将它先设置为 “no release” 标签，表示可能不会在这个 sprint 上线。如果优先级高，和 Team 成员一起评估是否能在需求变更情况，依旧完成上线标准。如果答案是"是"，重新评估它的 Point ，注意这里的 Point 是包括原有的加上修改的部分，然后再设置回 “release ”标签。
所有的变更数据都会在最后的 report 中体现出来，这样我们可以看到每个 sprint 我们实际 plan 的任务有多少，变更的有多少。这对后面做计划将很有帮助。
<未完待续....>
Last updated