功能π的敏捷之旅

本文里会以一个功能π的开发流程为例,展示公司内一个敏捷团队的软件开发实践。

项目背景

客户R是澳洲最大的在线房地产广告平台。公司团队是协助R客户创建一个针对中国市场的房产信息广告平台,用来展示澳洲以及其他海外房产,方便国内投资者。

作为一个全功能的交付团队,整个团队的人员一共11人,成员包括TL * 1、BA * 1、UX * 1、QA * 1、Ops * 1、Dev * 6。客户方面Delivery Lead * 1 和 Product Owner * 1, 两人均在澳洲。

客户负责提供项目的Roadmap,优先级以及初步的需求。后续由公司开发团队完成从需求分析、交互设计、功能设计、实现、测试、以及部署上线的全生命周期的工作。

功能π的敏捷之旅

下面以一个功能π的开发流程为例,展示笔者所在项目的开发实践。

计划

项目的路线图Roadmap是由Trello来管理的。Epic需求会由客户PO记录在Trello中。Trello board中设置的有不同的列,如Backlog, Planned, Next, In progress, Completed等。每列中卡片由上而下代表优先级的递减。Trello board作为项目high level需求的管理工具,可以很直观的了解项目整体的进展状况。

每两周全团队会进行一次计划会议,类似IPM,但是主要是根据Roadmap上的优先级,确定近期的开发计划。
最终的输出是一个具体的task列表。其中会包括:

  • 当前进行中的任务
  • 新加入的功能π
  • 需要fix的bug
  • 技术卡

计划会议上会把上述列表中的任务逐个讨论,目的是团队对于近期的优先级有一致的认识,以及对每个任务的内容做澄清。

团队JIRA作为需求管理工具,并同时使用物理Kanban墙以方便站会时讨论。计划会议中计划的任务会在JIRA kanban board中挪至Selected for Dev列。

对于新功能π而言,PO首先会在Trello上创建卡,并设置优先级。开发团队会按照优先级将功能π计划到后续的开发中。

需求来了

功能π开发的第一步就是由BA对客户提供的需求进行进一步的分析、细化、澄清和确认。如果功能π还涉及到用户交互,UX也会参与到这一步。UX会基于BA的分析,对信息流进行梳理,完成用户界面和交互设计。最终的输出结果为Jira上的用户故事。

用户故事一般遵从As…I want…so that的格式。在用户故事的内容上,一般会包含下面信息:

  • 描述信息: 关于功能π的描述,提供更多的上下文信息
  • 验收标准(Acceptance Criteria)
  • 完成定义(Definition of Done)
  • UI相关设计文档

另外一些信息会在后续环节持续补充上去,如分解的子任务,受影响的模块,需要部署的模块等。
分析完成的用户故事卡片会被挪至Ready for Dev列,后续会有开发着手开发。

Story Kickoff

开发人员在开始一个新的任务前,会首先进行story kickoff。这个环节主要目标是大家对功能有正确的认识,同时避免技术坑,简言之就是确保在以正确的方式做正确的事情。kickoff环节会有QA,Dev, BA, UX以及TL共同参与。在kickoff中,Dev会首先介绍当前自己对这个功能的理解,用户如何与系统进行交互,如何验证功能完成、以及技术实现。如果是一对Pair在kickoff,一般会有经验较少的Dev来进行介绍。

Story kickoff成功后,Dev会对功能π进行任务分解,并按照优先级以及依赖关系排列子任务开发顺序。任务分解的结果也会更新到用户故事中,一般会在用户故事卡下建立子任务,方便追踪进度。

结对编程

团队一般采用结对编程(Pair programming)的方式进行开发。结对编程的优点在于快速的知识传递,无论是对于刚进入团队的新人,还是刚接触某个模块的老鸟,业务知识还是编程技能。

Pair

在功能π的开放中,这对Pair中的两个Dev会以TDD的方式,合作完成业务代码和测试代码的实现。测试部分包括单元测试和自动化验收测试两部分。对于验收测试的部分,Dev有时也会和QA一起pair完成验收测试脚本的编写。

团队中也会周期性的轮换pair,这样每个人都有机会接触到不同的模块,使得业务知识在团队内更好的传递。

每日站会

团队每天会使用Always On Video和客户一起进行站会,更新项目的进展。

持续集成

在站会中,每个人/Pair会更新一下三个方面的内容:

  • 上一个工作日的工作内容
  • 遇到哪些技术挑战,有没有风险?
  • 今天的工作计划

同时,团队会更新Kanban物理墙上功能π的状态。

持续集成

持续集成目前应该已经是软件开发的标配实践了,什么?你的团队还没?

持续集成

功能π的新代码每天都会多次提交到git, 持续集成工具会自动检测代码提交,并触发构建流水线。流水线中的验证环节会自动执行测试,验证系统功能正常与否,将构建物发布到软件仓库, 并最终将最新版本软件部署至测试环境。


持续集成

Code Review

每个工作日的5点至6点是code review时间。这个环节所有的Dev会集中在大屏幕前,集中review当天提交到git的代码。code review可以审查代码中的瑕疵,从基本的编码规范、代码坏味、明显的逻辑错误、以及功能实现上的疏漏等。同时,code review也是很好的knowledge transfer的方式。

持续集成

Story Signoff

Dev完成功能π的开发后,会邀请BA,QA,UX和TL进行story signoff。Dev会在本地或者测试环境中准备好测试数据,向参与Signoff的各位同事演示功能。期间,QA会要求Dev按照多个测试场景进行多次演示,以确保功能基本完整。UX也会按照设计Mockup对功能实现进行比对,确保在各个屏幕尺寸下显示符合设计。
Signoff通过后,Dev会更新kanban墙上功能π对应的故事卡的状态至 Ready for QA。

QA

QA会从看板墙的Ready for QA列中将功能π对应的故事卡更新至 In QA, 并在测试环境中按照设计的测试用例进行验证。

如果发现功能问题,会记录至功能π的故事卡,并交由Dev修复,并再次Signoff后,继续QA环节。
验证无误的话,功能π会被部署到预生产环境(Staging环境)。这样客户可以在预生产环境对功能进行review。

最终,π的故事卡会被挪至Ready for Release,并在下次上线时部署至生产环境。

部署上线

团队的持续集成流水线中包含了部署上线的阶段。如前所述,每次构建成功,都会将最新的软件版本部署至测试环境。发布到预生产环境和生产环境会按照项目和业务要求,手动触发。

对于暂时不需要发布上线的功能,如需要等待销售或市场部门配合,团队会使用功能开关(Feature Toggle),将新版本部署至生成环境,但并不上线新功能。

feature toggle

另外,在部署流水线中,也集成了一部分的自动测试。当新版本在预生产环境和生产环境部署完成,但并未正式切换前,这些自动测试会被执行,以确保系统功能正常。

持续集成

至此,功能π就完成了它的敏捷之旅,成功上线!

推荐阅读更多精彩内容

  • 本文以我在ThoughtWorks中的E项目经历为依据,覆盖了ThoughtWorks日常独立交付项目中主要的敏捷...
    袁慎建阅读 3,699评论 8 33
  • Android 自定义View的各种姿势1 Activity的显示之ViewRootImpl详解 Activity...
    passiontim阅读 124,906评论 16 537
  • 篇前话 经历过传统的软件测试工作,每天的任务就是写测试用例,跑测试用例,改测试用例,报bug,验bug。测试用例和...
    Clare_可乐阅读 908评论 0 4
  • 2015年11月ThoughtWorks发布的技术雷达提到一个新的主题——产品环境下的QA(QA in Produ...
    BY林子阅读 2,432评论 0 9
  • 你不相信 星星真的会掉在地球上 长不大的孩子唱着永恒的歌谣 我想和你一起慢慢变老 月亮偷听了谁的秘密 把它藏在床底...
    無魚阅读 67评论 3 3