很多人都好奇，一个敏捷项目上面的BA一天忙忙碌碌的都在做什么，不像开发童鞋实现了很多功能，也不像PO（product owner）童鞋决定业务方向。那BA每天都在做什么呢？我们讲个故事吧~
在这之前，先说说几个敏捷项目中和BA相关的阶段，他们也基本涵盖了整个敏捷项目的所有环节：
- 需求分析 (Requirement Analysis)
- 用户故事确认(User Story Confirmation)
- 迭代计划 IPM (Iteration Plan Meeting)
- 开卡 (story kick off)
- 站会 (Stand Up)
- 结卡 (Sign Off)
- 成果展示 (Showcase)
- 复盘(Retro)
现在，我们一起看看这个找女票的项目。
故事的开端要从小白童鞋要帮小明童鞋能找到女朋友说起。
那天，小白童鞋找到小A
“听说你做BA的，帮我哥们找个女朋友吧……”
好的！
小白递上了自己觉得还挺全面的小明的信息。
小A拿过来一看，怎么还有体重，真个么……真的……详细……嗯……
| 姓名 | 小明 |
|---|---|
| 年龄 | 33 |
| 体重 | 保密 （吨）（为什么要说体重，且单位就暴露了好嘛 啊喂！） |
| 职业 | *** （为了谁也不黑，就匿了吧，别对号入座了） |
| 爱好 | 在家里宅着 |
| 开心的事 | 喝可乐 |
| 不开心事 | 无聊，没人陪我喝可乐 |
小A挠挠头，既然答应了，就得开始行动起来了。
需求分析 (Requirement Analysis)
小A：“我能和小明聊聊么？”
小白：“不能……”
小A：……那就只能问问小白了。
小A问了小白一系列的问题，从小明对女票的性别要求一路问到身高体重年龄家室，基本上没有任何特殊的信息。正常人看来，小明的要求已经很低了。
小A 内心OS：听上去没啥问题，为啥就觉得不太对呢？于是小A又寻找别的方向来问。
小A：“之前有过女朋友么？”
小白：“没有……”
小A：“没找过么？”
小白：“怎么说呢，他太宅了，没法认识新朋友，而且有点邋遢吧”
小A心里突然有点想法，继续问道： “那，有可能是因为邋遢所以认识不了新朋友么？”
小白：“有可能，他那个邋遢呀，我是真的看不下去了，别提别的姑娘了……”顺着这个线索，接下来小A又问了些问题，最后给出了自己的看法。
我们最终的目的是为了让小明能找到女朋友，现在没有女朋友的原因是：小明过于邋遢，因此别人不愿和他交朋友，没法认识新的朋友，就没法有女朋友了。
我们要做的是：
- 让小明改掉邋遢的坏习惯
- 让小明有新的爱好
- 帮助小明找到新的女朋友
那首先，我们要做的第一步是：帮他改掉邋遢的坏习惯。
小白眼睛一亮：“行，我给你组个团”
小结：到现在为止，BA从PO也好，用户也好手上拿到些需求，这些需求有些清晰，有些模糊，有些只是表面上的痛点，或者只是结果类的，BA需要去深挖，就像这个找女票的例子，最后“歪楼”成了提升自己。
在BA的日常工作中，在拆分故事卡之前，需要深入的了解需求，找到用户真正的痛点以及深入分析痛点的原因，挖掘背后真正的需求，进行分析。
用户故事确认(User Story Confirmation)
根据小A的分析，我们要做的是：
1. 让小明改掉邋遢的坏习惯
拿到这个任务之后，小A还是需要进行更详细的深入细节分析，以及最终和小白小明的确认。小A自己对这三个任务进行了细致的分析拆解，小明改掉邋遢的坏习惯，那怎么改变呢？小A列了以下几个维度:
1. 小明要保持自身的卫生
2. 小明要保持居住环境的卫生
3. 小明要提高自己的生活品质
随后，对于之前提出的点，小A都进行了类似的分析拆分，于是小A得到了一批像下面这样的用户故事
作为：小明
我希望：保持自身的卫生
因此：我可以一直保持自己卫生干净从而改掉邋遢的坏习惯
AC1: 小明每天要换干净的衣服出门
Given: 小明需要出门
When: 小明挑选衣服
Then:
1.衣服不能是昨天一样的
2.衣服需要是干净的
小明带着这堆用户故事，找到了我们小白，小白表示，很满意，可以开始实施了
小结：当BA了解清楚了需求之后，需要给他们一定的时间，去细化，将他们拆成大小和功能都合适的用户故事，每个用户故事都要尽量满足INVEST原则，这样才能在后面交给我们的开发同学进行实现。就像故事中小A准备好了很多用户故事（user story）。在这之后，需要和我们的客户或者是业务负责人进行确认，确保我们的每一个用户故事都是满足业务需求的。
每张卡在放到迭代Backlog之前，都需要和客户业务负责人进行确认，确保业务，设计细节满足需求。
迭代计划会议 IPM (Iteration Plan Meeting)
小A带着这用户故事，和小白以及小白组的团进行了亲切友好的沟通，俗称IPM （迭代计划会议），这个团里有 小代 和 小Q
首先，我们的小白介绍了自己的诉求：“让小明改掉坏习惯，从而找到女朋友”
“我想让小明找到女朋友，根据我和小A的分析，第一步，我们需要先让小白改掉些坏习惯，变的不那么邋遢！呐~ 背景就这么多。”
接着小A说介绍了拆解的小目标，包括下面这个用户故事
作为：小明
我希望：保持自身的卫生
因此：我可以一直保持自己卫生干净从而改掉邋遢的坏习惯
小明每天要换干净的衣服出门
Given: 小明需要出门
When: 小明挑选衣服
Then:
1.衣服不能是昨天一样的
2.衣服需要是干净的
这时候小代同学说话了：“衣服不能和昨天一样的话，那可以和前天一样么？或者周五能和周一一样么?”
这时候小Q同学说话了：“怎么定义不一样？扣子不一样就算不一样，还是必须款式颜色都不一样算不一样”
小A说: “嗯嗯，你们说的对，应该再清楚一点，你们看哈
- 衣服相邻的两天不能是一样的，也就是说，如果周一穿了红色的衣服，周二就不能穿，但是周三及以后可以有一天穿。
- 衣服不一样，意味着要么颜色，要么花纹款式，二者至少有一个不同，扣子不一样不算不一样”
小代和小Q同学表示详细可以，同时小白也认同。大家达成了一致，我们的用户故事变成了这样
作为：小明
我希望：保持自身的卫生
因此：我可以一直保持自己卫生干净从而改掉邋遢的坏习惯
AC1: 小明每天要换干净的衣服出门
Given: 小明需要出门
When: 小明挑选衣服
Then:
1. 相邻两天衣服不能是一样的
例如:第一天是红色的衣服，第二天不可以穿这件，第三天就可以了。
2. 衣服的不同需要至少满足下面两个条件
1. 颜色不同
2. 款式不同
3. 衣服需要是干净的，在穿之前必须是洗过的
紧跟着 小A让大家给这个卡估了点
小结：在迭代计划会上面，大家需要对细节达成一致，BA或者PO（业务负责人）需要给团队中的每个人讲清楚，事情的背景和诉求，BA需要讲清楚后续大家需要做的事情，并且需要给问题以回答
IPM（Iteration Plan Meeting）迭代计划会议主要是跟客户保持沟通与信息更新的一个会议，同时和开发达成一致
开卡 (story kick off)
开完了IPM之后，小A将已经写好在系统里面用户故事，在物理墙上做了可视化，形成了看板，在这个看板上面，挂着我们刚才的故事
作为：小明
我希望：保持自身的卫生
因此：我可以一直保持自己卫生干净从而改掉邋遢的坏习惯
AC1:小明每天要换干净的衣服出门
Given: 小明需要出门
When: 小明挑选衣服
Then:
1. 相邻两天衣服不能是一样的
例如: 第一天是红色的衣服，第二天不可以穿这件，第三天就可以了。
2. 衣服的不同需要至少满足下面两个条件
1. 颜色不同
2. 款式不同
3. 衣服需要是干净的，在穿之前必须是洗过的
小代同学告诉小A说想开这个卡，因此现在小A 小Q都围在了小代同学身边，小代同学说：“这个卡我要做两个事情：
- 保证小明的相邻两天衣服不同
- 保证衣服穿之前是洗过的
我们到时候check的场景是
- 小明第一天穿红色的衣服，第二天不是红色的，第三天是红色的，且洗过
- 小明第一天穿衬衣，第二天是T恤，第三天是同一个衬衣，且洗过
- 小明第一天穿红色衬衣，第二天是黑色T恤
大家看这样可以么？”
小Q同学说：“看下第四天的情况吧，不能和第三天一样，但是可以和第一天或者第二天一样”
小A同学说：“洗过是没有味道没有污渍的哈”
小代和小Q看着小A……
小A笑着说：“好，我加到用户故事里面”
作为：小明
我希望：保持自身的卫生
因此：我可以一直保持自己卫生干净从而改掉邋遢的坏习惯
AC1:小明每天要换干净的衣服出门
Given: 小明需要出门
When: 小明挑选衣服
Then:
1. 相邻两天衣服不能是一样的
例如:第一天是红色的衣服，第二天不可以穿这件，第三天就可以了。
2. 衣服的不同需要至少满足下面两个条件
1. 颜色不同
2. 款式不同
3. 衣服需要是干净的，在穿之前必须是洗过的
1. 不能有污渍
2. 不能有异味
check 场景：
我们到时候check的场景是
- 小明第一天穿红色的衣服，第二天不是红色的，第三天是红色的，且洗过
- 小明第一天穿衬衣，第二天是T恤，第三天是同一个衬衣，且洗过，第四天是第二天的T恤且洗过
- 小明第一天穿红色衬衣，第二天是白色T恤
小结：开卡，story kick off过程中，BA需要让Dev讲清楚，整个卡的范围scope，以及大家一起聊清楚卡的验收场景，根据AC（验收标准）来判定怎样才算整个卡结束，进入到测试阶段。同时，也可以补充一些之前没有想到过的细节，让Dev QA 都清楚卡需要做些什么。
每张卡在被分配给Dev之前，Dev需要根需求输出方，需求验收方一起达成理解一直，这个沟通的过程称为“开卡”
站会 (Stand Up)
自从整个团组了之后，大家每天早上都会开一个小会，为了不让整个会时间太长，都站着开……俗称站会，每个同学说说自己昨天在做了什么，今天要做什么，遇到什么困难。
在今天的站会中，小代同学说：“我昨天开始做让小明每天换衣服的卡，今天要继续做，但是昨天我遇到一个问题：小明家里没别的样式的衣服，都是一毛一样的衬衣，做不到不一样”
小A：“嗯……我找小白想想办法吧，你先做其他的AC吧。”
小A同学找到了小白说出了了遇到的困难，小白说：“这样啊，我今天晚上让他下单，明天就送到了……”
小A：“那就再好不过了，尽快能解决，这个卡就不会被block住了”
第二天的站会小A说：“我昨天细化了后面要做的故事
今天要继续细化”，然后对小代说：“昨天我问了小白，今天衣服都一样的事情就可以解决，你可以去check一下。”
小结：每天的站会是大家沟通的时间，每个人都知道大家的进度，同时遇到有问题的人能够及时提出来。
每天BA都需要参加站会，更新自己做的事情，同时通知到Dev一些新的信息
结卡 (Sign Off)
所有的问题都已经解决了，按照时间小代的计划，第一个用户故事应该已经可以check了，果不其然，小代问了问小A和小Q的时间，大家表示下午可以，所以就约好了下午大家一起把这个卡sign off了 俗称 desk check
时间来到了下午，小A和小Q聚集在小代准备好的场景下，
大家一起回顾了下验收场景：
- 小明第一天穿红色的衣服，第二天不是红色的，第三天是红色的，且洗过
- 小明第一天穿衬衣，第二天是T恤，第三天是同一个衬衣，且洗过，第四天是第二天的T恤且洗过
- 小明第一天穿红色衬衣，第二天是白色T恤
小代开始模拟第一个场景：
- 第一天小明穿了红色的衣服，干净， check 过！
- 第二天小明穿了黄色的衣服，干净， check 过！
- 第三天还是红色，干净， check 过！
小代开始模拟第二个场景：
- 第一天小明穿衬衣，干净， check 过！
- 第二天小明穿衬衣，嗯？
“意外意外…… 我再调试一下” 小代说到。
于是小Q和小A各做各的事情去了，过了一会儿小代说OK， 小Q和小A就又聚了过来
这次顺利的过完了所有的场景
小Q说：“我还想看下第二天白色T恤如果当天染上了污渍，下次穿污渍消失。”
于是，小代模拟了场景，并顺利通过了小Q新加的验证场景。
自此，小A 小Q 小代结束这张卡的验证，这张卡自此进入了测试阶段，小Q开心的拿着卡测试去了~
小结： sign off的过程是需要 BA QA Dev 对Dev做出来的结果进行一系列的验收工作，保证功能的完整可交付。
Dev把自己对应的卡开发完成提交代码后，需要根据需求输出方（BA+UX）在测试场景下showcase验收需求，否则不可以将卡挪到下一个泳道
成果展示 (Showcase)
忙忙碌碌的日子过，整个迭代结束了，看上去已经有了明显的成效，需要给小白看下这段时间的成果，于是我们需要showcase
这天，小白在场。
小A说：“大家好，这段时间我们针对：让小明改掉邋遢的坏习惯，进行了如下的行动，我们实现了：
- 小明要保持自身的卫生
- 小明要保持居住环境的卫生
- 小明要提高自己的生活品质
下面我们一起看一下我们的实现”
这时候小A用模拟小明分别展示了穿衣，居住，交友等一系列场景。
小白表示很满意, 同时问了些问题。
小A同学也都一一做了解答
这次showcase就在这样轻松友好的氛围中结束了。
但是，鬼知道小A在准备这次showcase之前经历了什么，showcase前10分钟的模拟小明不工作，衣服颜色不正确，衣服样子不改变等等。
还好有惊无险。
小结：为降低项目风险，每个迭代的功能完成后，会跟客户showcase，将本迭代完成的功能演示给客户看
复盘(Retro)
迭代结束了，我们看看有什么可以改进的，下次别再出同样的错误
小A同学主持了这次复盘会议，分别让大家都写了 well, less well, suggestion 也形成了需要做的action
小A，小Q，小代拿走了各自的action 开始了下一轮的迭代……
小结：每个迭代结束，BA需要参与复盘，在整个过程中大家一起回顾好的不好的，并且承担一些改进行动
就此我们敏捷项目上面，一个BA的职责基本上介绍完成了，做软件项目其实和上面的故事是一样的。都需要BA同学在整个过程中承担相应的责任。从详细的分析需求，给出用户故事，到最后用户故事的实现进入生产，每一个环节都和BA息息相关。因此作为BA需要有足够的耐心细心以及一定的经验来保证每一个功能的完整，进而完成整个项目。
当然团队里面的每个人都需要为我们整个项目负责，BA是其中的一部分，也是不可缺少的一部分。每个BA都在努力，让项目更好的实现客户，用户的需求。
网友评论