BA可以藏着需求

项目背景：

员工离职界面，由三块组成，

　　基本信息：“离职人姓名”“年龄”“性别”；

　　财务信息：“本月工资是否结清”“本月奖金是否结清”；

　　其他信息：“培训费是否赔偿”“笔记本是否归还”

 

客户需求：

希望能提供Excel导入。

 

情景1

BA分析完需求后，会把客户需求全部灌输给DEV，然后讲述自己是如何拆分这个需求。经过一番激烈的讨论后，得出下面两种拆分结果：

　　A方式：

　　　　stroy1：基本信息，财务信息，其他信息导出

　　　　story2：基本信息，财务信息，其他信息导入

　　B方式：

　　　　stroy1：离职人姓名导出和导入

　　　　stroy2：年龄导出和导入

　　　　stroy3：性别导出和导入

　　　　stroy4：本月工资是否结清导出和导入

　　　　stroy5：本月奖金是否结清导出和导入

　　　　stroy6：培训费是否赔偿导出和导入

　　　　stroy7：笔记本是否归还导出和导入

最后，由于势单力薄（DEV和QA一致选择A），以及从团队士气考虑，BA最终接受了A。

 

情景2

BA分析完需求后，只告诉DEV做离职人姓名导出和导入，经过一番激烈的讨论后，只会得出一种结果：

　　A方式：

　　　　stroy1：离职人姓名导出

　　　　story2：离职人姓名导入

等这两个story live（一定是live，而不是code complete）后，再加入年龄导出和导入。

 

分析情景2的利弊

弊端：

（1）情景1有个讨论的过程，避免BA分析的盲区。

笔者认为，BA在需求分析阶段是和PO，顾问，项目总监一起参与的，从很大程度上已能避免分析盲区，如果再与DEV讨论，只会得到相反的效果。

 

利端：

（1）避免从程序的角度拆分story。

拿上例来说，DEV较难接受先写insert name into employee1再把,age加进来，写全insert name,age,sex,... into employee1最是最完美的（做程序就要做到最完美，而且要充分考虑未来，最好能把想到的全做了^ ^???）。所以拆成select和insert，是A方式出现的根本原因。“KISS理论乱掰”推荐一看。

 

（2）避免重复修改。

只完成姓名后，BA看时，会提出针对它的单个修改意见，而这个意见，能避免后面的story犯同样的错。（这是不是也是种避免浪费呢^ ^）

 

（3）避免DEV陷入“多任务写名字”的痛苦。

如果全部做好后，BA，QA看时，会提出3个需求变更，外加4个bug，7个任务同时压到1个DEV身上，其他DEV由于对代码不熟短期难以提供有效帮助。（可不可以说又陷入了“瀑布式”呢^ ^）

 

（4）避免领域专家的出现

不同的Story，分配给不同的DEV去做，参与（亲身完成一个story）比讲解（code review，pair）更能让代码在团队中传播。更重要的是解决领域专家离职带来的问题。

 

写在最后

如果您觉得情景2不合适，那么，请立即去做这件事：进行story拆分的培训，带领DEV走出思想固区。