打造工业级 App 开发流程 (JIRA+CI/CD)

本文章不光是方法论,更有工作中得出的最佳实践。主要是用来解决和回答以下问题。

  1. 如何实现从想法到产品的快速落地

  2. 如何保证在团队高速发展时,开发效率依旧高效

  3. 如何保证快速迭代时,依旧高质量的交付

  4. 如何保证执行层面的公开透明,并建立良好的风控体系

  5. 如何体现团队或个人价值

  6. 如何将产出量化

为了回答上述问题,我们需要先熟悉以下概念和工具

  1. Agile

  2. Scrum

  3. 任务管理 JIRA

  4. CI 平台 Travis / TeamCity

  5. App 打包发布脚本工具 Fastlane

开发流程

虽然接下来要讨论的是在移动端的实践,但实际上针对其它开发场景,基本的开发流程极其相似。主要包括:

需求定义,评审,功能拆分,方案设计,开发,代码审核,CI/CD, 黑/白盒测试,上线发布这一套标准的工作流。

如果针对更大的需求/项目,还需要引入项目评审,优先级评审,跨部门合作评审 (依赖梳理), L1 (估难易度), L2 (细化的成本估计) ,RoadMap 制定,Milestone 设定,集成测试,灰度验收等等。

如何根据不同的阶段,制定更合理的开发流程,和资源利用?

我们知道,在软件开发中最重要的资源,就是团队规模,和已掌握或拥有的技术栈。这些资源会根据产品的不同阶段有所不同,不同的资源可以配合不同的流程,保证产品的快速迭代和交付。

通常情况下,我们将产品分为三个阶段,当然还可以再细分,但先以大的方向看,分为产品原型期(初期),发展期(中期),成熟期(后期)。

在产品原型期,也就是从 0 到 1 的阶段

在这个阶段,团队规模越小越好,越精越好,开发可以身兼测试。

App 端的技术栈选型不用太受限,也不用太追求极致性能和体验,即使大量的三方库使用也是可以的。但有一点要注意,要管理好它们,分门别类,能做封装的就做一层封装,以方便以后替换。也切记不要盲目引入,尽量采用主流的开源框架,耳熟能详的开源框架优先使用。

开发流程上,针对核心功能点,保证其有完整的开发流程,其它非核心需求不用刻意追求流程化。什么是核心功能,需要根据产品的定义。例如电商类 App 中,用户账号体系,登陆注册,商品成列,交易属于核心,尽量走完整 Scrum 流程。其它非核心功能,比如样式,设置,启动画面,频道,可以做放一个大的 task 或 story 统一管理即可。

一句话总结就是,小而精,轻而快

在产品发展期,也就是从 1 到 10 阶段。

团队的规模依然需要保持精干,以资深为主,需要配合专业的测试人员。

App 端的技术选型需要配合产品的需求,有清晰的方向。对三方库的使用或二方库的开发需要有针对性。比如一个电商的 App ,在这个阶段,不要花太大力气在动画和交互上,而针对核心交易流程,商品展示流,需要有可沉淀下来的库或对相关三方库有足够的了解。这个阶段的选型原则是,对产品的核心技术方案要在自己或团队足够掌握的范围内做出选择,而不一味追求流行。如果技术沉淀不够,继续使用三方,但一定要花大力气逐步替换。

对于开发流程,这个阶段人员有一定的增长,所以可以尝试从业务或技术方向进行模块化划分,如果是5人以下的团队就不用切了。切的话,无论是从业务角度还是技术角度,Scrum 模式依旧是有用的,做产品需求和做技术需求流程基本类似。只是在技术需求上,产品经理就是开发自己,对开发人员有一定的文档写作能力要求,这也是为将来做更大规模的重构和架构设计奠定基础。当拆出来的团队有两个以上时,团队之间的依赖尽量在其中一个团队中独立完成,换句话说,这个人或团队需要有端到端的设计和交付能力,尽量避免出现一个功能卡在另一个团队开发过程中。这也是为了让所有人都能理解业务,并做好信息的共享。所以这个时候 Scrum 团队里的成员有可能是临时存在的,当相关任务结束后,成员自然回到各自的团队中。

一句话总结就是,确定技术方向,沉淀核心技术,建立基础的开发模式。

在产品成熟期,也就是从 10 到 100+ 阶段。

基本上产品已成型,也获得了市场认可。团队的规模可以根据对未来市场的增长规模,产品的规划,逐步增加人员,这个时候人员的增加是梯队式的,有资深,也有中级,初级等等,还有架构师,Release 工程师,配管等等,根据需要设定岗位和人员。

这个时候的技术选型关注点更多是在性能体验和系统扩展能力上,及开发效率的提升。模块化也好,性能优化也好,体验升级也好要做的事情很多,但核心还是一点,根据产品的核心卖点,重点投入人力,千万不要面面俱到。比如在还没有基础库时,就开始花大力气研究模块化,要搞模块化,先要搞清楚如何切,模块与模块间的信息如何交互,协议如何制定,如何自测集成之后再来想这些事。你可以看到其中一些事情,在基础打好后,做起来就自然而然了,千万不要本末倒置。如果你的产品是展示型的,建议花力气在信息的动态化,个性化上,无论是推荐算法还是自动化配管,总之能提升核心产品体验和用户粘性上的事更为合适。

另外,在开发效率上,我通常的做法是定期讨论并列出,目前开发过程中遇到的三大瓶颈,然后评估开发成本,制定优先级,列为技术债,和产品沟通后,依次排期解决,让团队看到短期和长期的目标与方向。

在这个阶段的开发流程,会稍复杂一些,但还是会遵循 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 中目标是什么,要做哪些 Story/Task,他们的优先级是什么等等,让所有人都知道每个人需要做什么,目标是什么。

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 的任务有多少,变更的有多少。这对后面做计划将很有帮助。

<未完待续....>