敏捷实践总结（四）——Scrum第一个Sprint实践经验积累

接触Scrum时间不长，开发中遇到的问题比预想的要多很多。

Scrum上面说了，每一个Sprint的时间设置在2——6周是比较合理的。我认为一般的项目一个Sprint4周比较合理。由于我们的pj项目不是很大，真正开发起来一月个差不错项目就哦了。所以第一个Sprint采用的是一周时间，这样能动性强了，但是暴露出了更多问题：

1、由于第一个迭代过程中，涉及到开发环境的配置及搭建，这些如果分别算是一个story，那么时间怎么评估怎么算呢？其实这些东西挺花费时间的。算的话，时间怎么计算合理？不算就肯定得让团队加班加点儿。结果我们采取的方式比较折中。以大家每天的工作时间*0.6为有效编码时间，以拍扑克的方式去平均数，估算每个story时间，留出足够的时间空余；

2、传统开发方式的影响。评估过程中，每个story的颗粒过细，建立story应该是站在用户的角度去考虑需求，然后一会儿就又去建立一个story：这个xx项目调试的调试工作。我认为：既然敏捷开发是每个人在开发的过程中再确定系统具体的需求，那么就应该综合考虑某一条线功能的复杂性与粒度问题。不用每个功能都分得特别细；

3、由于第一个迭代时间非常短，可以说，完成的都是一些准备工作与已知的技术攻坚，直接导致第一个迭代没有出任何可视的项目成果。这里是有悖于敏捷精神的。第一个迭代中，最好出一些可视的项目成果，领导查问起来，尽管团队成员都做了很多，但是不至于拿不出可视的东西。

另外，尽管我们第一个Sprint没有出项目成果，但是出色的完成了准备工作，使我们过分乐观了客观现实，导致我们第二个sprint的开发大大受阻。

年前因为赶时间，由于与jc系统交互的webservice中的方法，并不是全部通过了单元测试，也就是说，有些实现方法编码还是有问题的。由于系统之间彼此交互的东西很多，做假数据继续进行开发不是没有可能，但是非常浪费开发人员的时间，不然就得等jc那边调试好相应方法；如果仅仅是这样还算是幸福的，如果修改方法名或者参数，那么不仅jc系统那边对应的方法重新改、重新部署，我们这边所有开发人员都得跟着重新换接口。

4、彼此依赖，无法进行。由于我们pj系统的现有需实现的功能，都需要与jc系统做交互。之前的实现是将我们pj系统中需要的数据，从jc拷贝到我们系统中来，这样设置，我们前期工作比较好开展。而现在是jc系统那边维护唯一一份数据，而我们这边与jc做沟通调试webservice的人员没有完成，我们组其他成员就无法正常进行开发。影响项目进程。

5、会议太频繁。尽管我们第一个Sprint只有一周时间，但是由于出现了上面依赖问题，我还是召开了Sprint实施中召开了迭代计划会议。商讨其他story以及时间。每日的站立会议以及后期的评审会议、反思会议……

6、照猫画猫、生搬硬套之嫌。第一个Sprint，由于大家对Scrum还不是很熟悉，实施起来有些呆板有些生硬，这也是刚开始实施敏捷开发过程时，很容易犯的问题。

7、开发过程中，好多人都在看别人写的代码，时不时就会传来抱怨声一片片~~~这里只想说两句话：一、快速看懂别人代码的思路，是一种能力；二、写单元测试，从我做起。

目前项目中亟待解决的问题：

项目组成员应坐一起开发，沟通不及时会浪费更多的时间；

jc那边webservice方法的单元测试；

查询效率问题以及连带产生的hibernate优化、代码优化、思路优化问题。

敏捷团队之所以敏捷，是因为项目组中有：具有大局观令人敬服的组长、各有专攻沟通能力强的组员以及和谐的团队。然后坚持“以人为本”的方针，实现有限时间内的最大价值。提高团队成员的主观能动性，这是敏捷开发最基础的。不能做到这一点，就又回到了之前的呆板的开发模式中，敏捷开发就无法敏捷。