跌跌撞撞地敏捷之路——为什么进度那么慢

日期：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环境，而编译打包比较慢。编译打包时，除了我们这个系统本身的代码，还需要将我们依赖的平台框架代码一起编译打包（平台也正在开发中），所以比较耗时。那是不是能够这样搞呢：提供两种打包方式，一种是连同平台代码一起编译，适用于平台代码有问题的情况，另一种则是只编译打包我们系统的代码，绝大部分情况都只会用这一种，这样效率可以提高一些。

评论

6 楼 Hotpepper 2009-03-30  

引用

有一点，我在敏捷的时候，不大会做。向博主请教一下：
比如多个组并行工作，其中一个组抽取某些类（或者重构出某个类、某个功能）和另一个组类似，那怎样合并比较好呢？我的意思是：既然功能一样，那么系统里面只要存在一份好了，不要2份。

一个系统中，对同一个事物，不应该存在着两份抽象。假如两个类功能类似，就应该重构出一个父类，然后将差异封装到各个子类中。如果相同的逻辑存在两份，明显代码中存在着“臭味”，为何不消除呢？两份相同代码，意味着双倍的维护工作量。

5 楼 Hotpepper 2009-03-30  

澄清下我们的项目背景：
1、项目启动前，人员并未到齐；
2、规格发出评审前没有召开澄清会议；
3、项目中已到位的3位成员对产品SE发出的规格评审后各自反馈了意见，然后产品SE单独单对单的和各个成员沟通、交流、澄清他们提出的疑问。然后项目就启动了。
就是这三个原因导致了方案反复讨论、确认的问题。正常情况下，规格发出评审前，产品SE应该召开一个规格澄清会议，为项目组成员讲解规格内容，澄清功能需求。产品SE发出规格评审后，在收到项目组成员的review表单后，应该再召开评审会议，和所有的项目组成员一起确认他们反馈的review意见，确保他的意图能够明确的传达到各个项目组成员中，这样就可以大大减少由于理解不同而导致的项目开发过程中对方案的反复讨论现象。
这样做并不是所想要将一切不确定因素在项目启动前期消灭，就是想要做也做不来，大家都知道这是不可能的，敏捷是拥抱变化的，但在大的方向上、架构层次上，应该尽量减少可以在前端就规避的、因为开发人员与产品SE理解不同而导致的反复讨论问题，sprint周期本身就短，经不起这种折腾。
其实我们本身也是象metadmin说的那样在执行的，只不过有这样一个大背景在而导致出现了这个问题。

引用

metadmin  7 小时前   回复  删除
我非常赞同博主的分析，很有同感。

我对方案发表一下自己的看法：
1，首先方案也是分层级的；比如系统设计框架方案，技术架构方案，模块划分方案等等；
2，越抽象、越底层的方案，尽量不变的；
3，类设计等方案，可以不断迭代，不断优化。

4 楼 andyandyandy 2009-03-30  

metadmin 写道

我非常赞同博主的分析，很有同感。我对方案发表一下自己的看法：1，首先方案也是分层级的；比如系统设计框架方案，技术架构方案，模块划分方案等等；2，越抽象、越底层的方案，尽量不变的；3，类设计等方案，可以不断迭代，不断优化。有一点，我在敏捷的时候，不大会做。向博主请教一下：比如多个组并行工作，其中一个组抽取某些类（或者重构出某个类、某个功能）和另一个组类似，那怎样合并比较好呢？我的意思是：既然功能一样，那么系统里面只要存在一份好了，不要2份。------------------权限管理圈子欢迎您：http://accessmanager.group.iteye.com/

继续重构，使之统一。
tdd的用处在此大发神威。

3 楼 andyandyandy 2009-03-30  

我觉得你们的沟通有问题。
1，应该是先理解了产品SE的东西之后，讨论解决方案，然后开始工作。
2，如果有变化产生的话，是SE提出的，那么重复一。
3，如果有变化产生的话，是开发者提出的话，应该反映到SE，然后重复一。

在我看来，平台还没有稳定的情况下，对于具体实现就不用找专人测试了，tdd足矣。平台稳定了以后，再加入也不迟。

感觉测试环境有点复杂，不知道能简化否。

2 楼 metadmin 2009-03-30  

我非常赞同博主的分析，很有同感。

我对方案发表一下自己的看法：
1，首先方案也是分层级的；比如系统设计框架方案，技术架构方案，模块划分方案等等；
2，越抽象、越底层的方案，尽量不变的；
3，类设计等方案，可以不断迭代，不断优化。


有一点，我在敏捷的时候，不大会做。向博主请教一下：
比如多个组并行工作，其中一个组抽取某些类（或者重构出某个类、某个功能）和另一个组类似，那怎样合并比较好呢？我的意思是：既然功能一样，那么系统里面只要存在一份好了，不要2份。


------------------
权限管理圈子欢迎您：
http://accessmanager.group.iteye.com/

1 楼 liujunsong 2009-03-30  

家有千口,主事一人.
没有最终负责人的会议注定是没有结果的.