这是你熟悉的敏捷工作场景吗？（一）：我们组来了新同事

“吉米，你们组要来两个新同事。你知道他们的位置在哪吗？”原来是公司IS部门的文森特推着新同事的电脑和电话过来找位置。我们这是开放式的办公室，一个小组的人尽量挨在一起坐，方便大家交流，所以新同事的位置我们在前几天已经定好了。

“文森特，在我后面的是简，在她旁边的是路易斯。”

“谢谢吉米！”

“不用谢！”

“吉米，我们组的新同事明天来，你准备一下给他们讲讲我们组的工作流程吧！”这是我们组的开发经理托尼，他虽然年纪轻轻，但在软件开发上却是很厉害的角色。正因为这样，他当上了我们这个产品的开发经理。

“好的！”

公司里有一整套关于工作流程的定义，放在公司的Wiki上，每个人都可以随时查看。但是每个小组或者说每个产品又会有更加具体的流程，因为每个产品都有自己的特性。

“吉米，我们的Oracle数据库有哪个是开着的？”这是史蒂文，他是我们组的开发人员，他经常问我要数据库的连接信息。

“等一下，我发给你。”

我们是公司里最小的一个小组，现在只有四个人。加上开发经理托尼是两个开发，两个测试。爱米莉是专职的手工测试，我是自动化测试，需要的时候也会做手工测试。我们大家的角色并不是那么固定的。就像托尼，他不仅是开发经理，也是开发人员，也是我们的Scrum Master，而我不只是测试，我也是DevOps。

我们的产品经理在美国，我们的架构师在澳大利亚，我们的UI设计师在美国。我们的交流方式一般是邮件，电话还有Wiki。

现在我们组要加入两个新同事，是因为我们组又加了一个新产品，是一个公司内部使用的网页版的小产品。

这两个新同事，一个是开发，一个是测试。

第二天上班前，新同事们都来了，是前台带他们过来的，他们的文件架和文具都领好了。我教他们登陆电脑，把公司的文件服务器地址告诉他们，让他们从上面找需要的软件，先把工作环境建起来。

我们每天早上9点上班，9点半开早会。到了9点半，我们就都来到托尼的座位旁边。

“今天我们组来了两个新同事，开会前大家先认识一下吧！来，新同事先来！”

“大家好，我叫简，我来自……”

……

“好，介绍完了，我先说一下，我们这里每天早上9点半开早会，每个人必须在开会前到公司。简单说一下，早会我们主要讲的是你昨天做了什么，遇到了什么困难，需要谁的帮助，今天你准备做什么。我们每个人的工作都在Jira上列清楚了。好，开始今天的早会，吉米，你先来！”

“我昨天做的是BXX-103这个Task，昨天已经做完了，没有遇到什么问题，我已经把它拖到Done了，今天我会做BXX-108，早上我已经把它拖到了In Progress。下午我会给新同事讲一下我们的工作流程。”

“好的，我上午给他们先大概讲一下我们的产品。史蒂文，你呢？”

……

我们组的工作流程是这样的：

每年，产品经理和开发经理会先定出我们产品的里程碑，这些在我们产品自己的wiki上可以查到。你们看，在这个页面有写明几月几日达到哪个里程碑，还有明年的，后年的。这是我们产品的大方向。上面有写明增加什么功能，支持什么数据库、平台。这样，我们自己在学习的时候就会有一个方向。

有了大目标，我们就得有小目标，这个页面里有最近要Release的详细的目标。这些目标在Jira上有对应的Task，你们看这些Wiki 上的任务项都有对应的Jira 的链接。

那这么多的任务，我们又是怎么做的呢？我们是把任务都分拆到了一个个Sprint中，两周是一个Sprint，我们这里的开始时间是周二，结束时间是周一。每个Sprint 开始之前，我们会先开一个grooming meeting，目的是把准备在新 Sprint中做的任务搞清楚，搞明白到底要做成什么样，要怎么做。这个会议一般是每周一下午举行一次，具体的我们以后再说。除了这个会议，我们还有一个Planning meeting，这个计划会就是把grooming过的任务分配给每个人的过程，到了下周二上午大家就知道怎么做了。

计划会议之后，我们会收到开发经理发的Sprint Start的邮件，他会在邮件里列出我们这个Sprint中的所有任务。同时他还会创建一个叫Sprint xx Retrospective的wiki page，用来记录我们在这个Sprint中做得好，以及做得不好的地方，这个页面的作用是反思和回顾，也就是说，我们做完一个Sprint之后，在接下来的周一上午会开一个反思回顾会。不用担心，你们只要先有个概念就好。

当我们收到了Sprint启动的邮件时，说明我们要开始干活了，不过开发人员和测试人员的开始时间有点不同。

你们还记得早上开会时看到的Jira Task吗？我们的Jira中分了四项：Open, In Progress，Testing，Done。Sprint开始的时候，我们的所有Task都在Open列表中并且是按优先级排好序的。当开发开始做的时候，需要从Open中拖动自己名下那个优先级最高的Task到In Progress列表。然后开发到Github上把develop分支check out，在这个最新的develop分支上创建一个新的分支，当然这个分支是产品简写BXX-Task名字把空格改成下划线，也就是对应着Jira ID。注意，我们这里的develop分支就是一个主分支，每次发布就是从这个分支发布。不同的产品会有一点点不同，另一个网页版的产品，它的主分支是master，但是操作也类似。

开发人员创建好了自己的分支之后呢，就在这个分支上添加代码。注意，加了代码之后先根据Jira task的验收条件自测，如果通过了所有的验收条件的话，就可以提交代码。代码一提交，我们的自动构建会自动运行，如果构建成功，我们会收到一封邮件，告诉我们构建的版本的地址，构建结果。如果构建失败了，提交代码的开发人员会收到邮件，请开发人员先修改。如果构建成功了，接下来，我们的自动化会先跑一个冒烟测试，这个冒烟测试其实就是对已有功能做的回归测试。如果这个测试也跑成功了，请开发人员用这个版本再测试一遍你的新功能。同时，开发人员要找其他开发人员对自己的代码进行Code Review，并且把Jira Task分配给做Code Review的同事。自测没问题，并且Code Review也通过之后开发人员可以把这个Jira Task分配给对应的测试人员，具体怎么分配，我们下次做的时候再讲。

“那开发人员在做开发的时候，测试人员什么都不做吗？”简有点不解地问。

“当然不是，在Open中的Task并不全是开发人员的Task，也可能有测试人员的。比如测试人员要准备环境，要学习一些跟新功能有关的新东西，都可以创建Task！所以当开发人员正在写代码的时候，测试人员可以做自己的这些Task，也可以准备测试用例。一旦开发人员分配了Task给你测试，你就要尽早开始测试，说明这个时候你就可能要先停下你手头的其它事情。因为开发完了尽早测试才能尽早反馈，有问题尽早改。”

“哦，明白了。那测试出来有问题怎么办？”

"问得好，测试人员拿到Task之后，先从服务器上下载回对应分支的安装包，然后开始测试。一旦发现问题就可以直接找对应的开发人员，跟开发人员说清楚，有时可能直接要演示给他们看，或者把环境借给他们用，跟他们说了，确定了问题之后还要在对应的Task下面创建分支的Defect Task，用来跟进这些问题，并把这个Task分配给开发。"

"那开发人员这个时候可能在做另一个新的Task了，要怎么办？”路易斯问道。

“开发人员开始做新的Task了，也得先暂停。因为这个Task还没有拖到Done，说明这个Task并没有完成，它的优先级更高，只有当一个Task拖到Done以后才说明这个Task是完成的。所以，无论这个Task是在开发的手里，还是在测试的手里，大家都要关注它，驱动它完成。而且，每个Sprint我们都会有明确的目标，这目标是团队的目标，大家都要盯着这些目标，让这些目标在这个Sprint中完成，所以，做事的时候不能只盯着自己手里的事情，也要听听，看看别的同事在做的事情，没做的事情。如果有需要的话，可以伸手帮助别人。只有我们这个Team达成了这个Sprint的所有目标，我们的这个Sprint才是一个成功的Sprint。如果你自己的Task做完了，但是Team的目标没有达成，这也是一种失败。”

“那拖到Done需要达成什么条件呢？”路易斯又问。

“好问题！所有的bug都fix了，CI和自动化测试都返回正常的结果，测试人员测试通过，Team成员也对测试人员的工作进行了Review之后，确认没有遗漏什么测试点了。这时候，测试人员就可以把这个Jira Task分配回开发人员，开发经理把代码合进develop分支，CI和自动化测试develop正常，手工测试确认这个功能后，就可以把这个Task拖到Done。”

"所以最后是开发人员把Task拖到Done的？”

“不一定，可以是开发人员，也可以是测试人员。因为merge进去之后，手工测试还要验证一下这个功能，自动化测试的结果每个人都能收到，所以就看开发和测试的配合了。”

“我想问一下Team人员对测试人员的工作进行Review，是怎么Review的？”简问到。

“测试人员在测试开始前已经有准备一些测试设计或者测试用例，其实测试设计是在Story的澄清阶段做的一个大概的设计。测试设计要写在对应的Story的wiki page里，目的是在grooming meeting的时候大家一起先做个Review。后面测试的时候，具体的测试报告会新建一些子页面来存放，这些子页面中存放的内容有两种，一种是验证需求（在Jira中我们会在grooming的时候列出Acceptance Criteria)的测试，另一种是探索式测试时的Session sheet，Session sheet的大概内容有：Charter（在……条件下探索xxx），测试人员，测试开始时间，测试结束时间，测试环境、工具，测试数据，Test notes（记一些详细的过程），问题：出现了什么问题，对应的Jira Task，其它考虑：从这个测试中想到的其它的问题，比如想到了新的Charter。

测试人员测完后，对应的测试报告也要创建出来，然后叫上开发人员和其他的测试人员一起Review。Review的时候可以先介绍你这个Task是什么功能，测试设计是什么，你用了什么数据测试了什么等等。”

“好的。"

“当一个Sprint结束时，无论Jira里面的任务有没有全部做完，都要开始另一个Sprint。Sprint结束时会先做一个Demo，也就是把这个Sprint中完成的功能做个演示，产品经理和架构师，UI设计师以及所有的团队成员都要参加。为的是再次让大家确认所做的功能是不是符合预期。有没有什么要改进的地方？"

“那一般是谁做Demo呢？”路易斯问。

“开发和测试都可以做，可以自己商量！做的时候会录屏，录音。我们每次计划会也会录屏录音。做完Demo之后我们一般会接着开Retrospective meeting，也就是前面说到的反思回顾会。在这个会议上，Scrum master会先带领大家回顾前一次Retrospective的会议记录，看看之前我们遇到的问题，在这个Sprint中有没有出现，出现了有没有用之前提出的解决方案去做。接下来再看新的Retrospective页面，一开始的时候，我们有说到，在Sprint start的邮件中有这个Sprint xxx Retrospective 链接。这个页面创建出来后，我们在Sprint进行时如果发现了什么做得好的，做得不好的就可以及时记录在里面。那在开会时，大家就可以说说，做得好的谁记了什么，让他/她来说说。做得不好的，谁记了什么，发生了什么，原因是什么，解决方案是什么，大家一起讨论，讨论出解决方案后要清楚地记下来，并且创建一个Action，指定一个同事去跟进这个Action。开反思回顾会的目的是让我们越来越好。不针对谁，只是让我们找到更好的做事方式，不断进步和提高。

还有一个很重要的东西，就是我们每天要在Jira Task里log work，一般下班时，你就可以打开你的Jira Task，然后在里面写下你今天做了什么，花了多少时间。“

“这个log work的功能是不是用来跟踪我们有没有认真工作？”简问到。

“一开始我也是这么认为的，觉得这个东西就是为了统计我的工作时间，看我每天这七个半小时是不是在干活。但是后来我发现，它不只是这个作用。我每天把自己做的事情写下来，时间也写下来，这属于是我的工作日志，我一边写可以一边回顾我的这一天是怎样过的。同时我就可以反思，我是不是用了正确的方法，用了合适的时间去做我的工作？我的完成度有没有达到我早上的预期？这样下去，这个Sprint中的任务我能不能按时完成？

好了，关于工作流程，就先讲这些吧！今天的内容有点多，不用担心，我们以后一边做一边学习。”