跌跌撞撞地敏捷之路——为什么进度那么慢
日期：2009.03.25
????? 今天的站立会议花了我们不少时间，原因大家觉得如果不花点时间分析下原因，并找出对策，极有可能会影响sprint的交付。目前的状况是：这个礼拜sprint就要结束，可实现的功能顶多只有一半。
1.没有按照story优先级来完成story???
????? 按照昨天晚上我们的初步分析，一个原因是由于我们中间有部分人没有严格按照sprint计划决定的优先级去完成story，导致到目前sprint即将结束，而在sprint计划上确定要完成的主要功能却只实现了一小部分。
解决方法：在product backlog中为story增加一个importance字段，用于标识story的优先级，优先级越高其数值越大。当然了，sprint backlog做为product backlog的一个快照，其中的story也必须有importance标识，同时贴在白板上的story卡片中也必须有这个importance标识，且story卡片按照importance值的从大到小、由高到低的顺序贴在白板上，团队成员必须按照这个顺序由上往下地完成这些story。当然，scrum master也需要在这个过程中进行监控，确保团队成员没有犯错。
????? 白板上的story卡片可以将product backlog中story条目的完整内容（也可以简化些，但至少importance和预估算值不能少）写上去，如附件。我们在两个sprint中，story卡片上只是写着story name，结合这两次sprint的开展情况来看，卡片上的信息太少了。在开发过程中，很少有团队成员会再去打开保存着sprint backlog的excel文档看里面的内容，所以有些记性不太好的成员，比如我，没过几天就忘了story的估算值了，而在站立会议上等成员汇报完昨天的工作后，scrum master统计完成工作量时偶尔还得跑去打开excel去查看story的估算值；同样的，那个importance值在这个sprint中差点失去了它的作用。白板放在最显眼的地方，每个只要转个身就能看见，且每天站立会议上大家都要对着白板，所以把story信息在卡片上写完整，大家就不会遗忘些什么了。
?
2.方案反反复复的讨论
????? 在这个sprint的开发过程中，我们发现花在讨论方案上的时间太多了。
????? 比如说，在项目启动前，产品SE输出的规格文档中已经划分好了各个层的职责，并初步定了各个层的接口定义，然后在sprint开发的第一天，所有的团队成员先一起将这些接口的定义确认一遍，在这个过程中有人有疑义，就把产品SE拉过来讨论了一番，最终经过激烈的争论，好象花了一个下午，大家搞清楚了产品SE的意图、以及确定了接口的定义。在设施的过程中，负责实现某个接口的成员（昵称A君），觉得接口定义还是有问题，就和我讨论，旁边的同事听着我们的讨论，觉得我们的理解和他的理解不一致，认为我们理解错了产品SE的意图，就和我们“争执”了上来，然后又把产品SE拉上了，讨论象漩涡，很快把其它的成员给卷了进来，我、A君、B君认为我们是按着一开始确定下来的方案来实施的，而产品SE却坚持我们错了，这可把我们给急坏了，就这样大家有风风火火的争论着，最终又花了几个小时把方案明确了。后来B君在实施过程中遇到一个问题和我讨论，讨论完确定解决方法后，我认为这个有必要向产品SE澄清、确认下，就让他和产品SE说声，结果这个确认除了B君、产品SE外，又把C君和我拉了进去，就这样又半个多钟头过去了。??? 就是这样，出现过不少次方案反复讨论的过程。
????? 解决方法：1）每次方案讨论，必须有个时间限制，初步规定为半个钟头，在这半个钟头内大家必须聚焦到问题上，不能发散。（如果在规定时间内无法达成统一意见呢？我自己这样认为：如果在规定的时间内无法得到答案，那么先结束这个讨论，让大家先冷静下，自己再综合之前讨论中其它人的观点考虑下，半个钟头后，大家再来讨论，这样可能比一直聚在一起讨论效果好些，在激烈讨论的氛围内人更加会固执己见的）。顺便提下，scrum中的一切事情都有时间盒，这个应该贯彻到底。2）每次讨论，项目SE与产品SE必须一起在场，两者少一个人都不要讨论，否则就会出现重复确认、讨论的现象。3）每次讨论后，都要简单输出一个纪要，内容包括：讨论的问题、最终确认的方案、以及达成这个方案是基于什么前提条件确定的，然后将这个纪要发出来，大家确认无误后就归档，一来可以做为项目的文档输出的一部分，二来防止后面大家可能会忘记。
????? 疑问：敏捷开发侧重于代码，而不是文档，那么大部分项目都应该会出现我们这种在实施过程中经常讨论方案的问题吧？除了我们自己确定的解决方法，还有其它更加高效的方式吗？还是说，类似大的方案、方向性的东西，应该在项目启动前就都应该是固定下来呢？思考中。
3.测试的问题
????? 在我们这个项目中，测试人员（测试部的）投入1.5个人（其中有一个人只能投入50％），测试人员负责测试用例的输出、进行IT测试、SDV测试，UT由开发完成。为了测试能够开展IT，我们承诺为服务层接口单独包装下，以服务的形式报出去（其实本身也有这样的实际需求），这样测试人员可以通过RMI的方式来测试我们的功能。测试人员反馈我们开发的在整个过程中只关注开发，很少将测试人员考虑在内，开发人员写完代码后，从界面上串通功能后就认为OK了，从不测试报出去的服务接口是否可用，而IT一跑起来就出现问题，问题的根源是代码中没有处理对外暴露服务的这种分支，这样导致测试进度阻塞。
????? 我认为这个服务接口本身就是我们系统的一个功能，就要求团队成员必须自己先调通服务接口，然后才能让测试人员进行IT，而scrum master则认为IT测试本来就是用来测试功能的正确的，所以服务接口是否能够跑通也应该是IT测试中的一项内容，如果由开发来保证这个，可能存在重复劳动。
????? 我同意scrum master的这个观点，测试本来就是用来发现代码问题的，IT跑起来发现有错误，这证明IT是有用的，测试是有成效的，因为发现问题了（不过，开发人员只关心界面是否调通，而不考虑服务接口这个功能也确实不应该）。之所以IT进度被阻塞，主要是因为每次改完代码后，需要重新搭建IT环境，而编译打包比较慢。编译打包时，除了我们这个系统本身的代码，还需要将我们依赖的平台框架代码一起编译打包（平台也正在开发中），所以比较耗时。那是不是能够这样搞呢：提供两种打包方式，一种是连同平台代码一起编译，适用于平台代码有问题的情况，另一种则是只编译打包我们系统的代码，绝大部分情况都只会用这一种，这样效率可以提高一些。
