2020-11-13 ITIL项目跟踪日记（2）

今天跟着团队开站会。

（一）站会

昨天联系了开发负责人，让她开站会时叫上我。

开发负责人在组织开站会上没有经验，虽然之前参与过的项目也开过站会，但她只是参与者。

因此一上来，开发负责人的第一句话是问我，怎么开？

我于是直接接了过来，“今天由我来主持一次，以后你来”。

按照电子看板的顺序，从上往下过，没有按照其它团队习惯性的去用“经办人”进行过滤。这样对迭代的进展了解更具有整体性。

在站会中，测试人员说：刚写完了一个模块的测试用例，由于前面另外一个开发提交了一个模块进入待测试，她要去优先进行测试，没时间再写其它的测试用例了。

趁此机会，向团队讲了下团队整体的概念。

“大家要摘掉自己习惯的那顶帽子，后端、前端、测试。我们都只有一顶帽子，叫开发工程师。当然YQ还戴了顶SM的帽子。只是大家在专业技能上有侧重，领取任务时可以选择自己擅长的领域，但是当某些任务出现停滞的时候，我们要跨领域领取自己力所能及的任务。例如测试忙不过来的时候，其它人应该考虑去根据测试用例做交叉测试。测试应该优先写测试用例”

团队的电子看板：

团队约定的工作流程：开发完成子任务后，将子任务放入已完成。所有子任务都完成后，将故事的状态仍保留在“处理中”（还是改成“待测试”？——没记住）。这与以前的一些团队约定不一样，有些团队加了待测试、测试中、测试完成栏目。——让子弹飞一回儿吧，看看这样的流程跑起来有什么不方便没有。如果团队觉得顺畅，那就这样跑好了。

测试用例是挂在史诗下的，没有挂在故事下——这个可能得视情况，如果一个测试用例就是针对一个故事的，那还是应该挂在故事下。让团队跑跑看吧，看看后续会发生什么。

还有个悬疑问题：会议即将开始的时候，SM问我要不要叫PO参加。我问她事先有和PO约没有，她说没有，但有些需求上的疑问，于是我问这些疑问能几句话说清楚吗，她说不能。于是我说那先不要叫，站会后专门拉PO讨论下需求。 我觉得这个操作没毛病。但现在想，以后是否要让PO参加每日的站会呢？让PO看看我们新的项目管理模式，团队协作模式，可能会扩大敏捷的影响力。

（二）需求澄清

站会后，团队就需求上的一些疑惑向PO进行了询问——是询问，不是讨论！

例如，

1、设备台账需求上没有对哪些字段需要必填进行说明，是否要进行限制？PO的回答是除了设备编号必填外，其它的不用限制。但实际上，设备名称这种东西怎么也得是必填吧？开发是否可以向PO提出建议来呢？

2、设备数据导入时，设备编号是excel填好了导进来还是先空着，导入系统后自动生成？目前的添加功能中是自动按照规则为设备生成编号的。发现PO在这里也没有想过，说不太清楚。我于是插了句话：是什么角色，在什么情况下要进行这样的导入操作？PO解释说设备管理员，有一批设备需要录入系统时，先在excel中整理了，再导入。然后大家达成一致，设备编号在导入系统后自动生成。

以后得通过实际案例，教会开发人员采用用户故事的思考方式来澄清需求。