敏捷小记：第一次迭代的应用总结

注：本文由 思步网 的特邀嘉宾 sungubbi 所写：

 

第一个Sprint 完成，历时三周。上午进行了迭代成果的展示沟通，下午进行了内部总结会议。

这是公司第一次尝试敏捷实践，在没有系统地接触过敏捷，也缺乏相关培训的情况下。当然，在推行前，我们内部进行了一些自学，并且指派的QA 接触过敏捷团队。我们挑选了一个公司的内部项目，进度压力相对没有那么大可以避免大家直奔结果而放弃过程，团队氛围较好较其它项目组更容易接受新事务，团队负责人尝试意愿高、态度够积极，再加上团队的分管领导主动提倡本次尝试。所以，第一个Sprint 的推行相对还算顺利。

在这个迭代中，尝试的实践如下：

1） 集中的办公区

在本次总结中，得到最多赞同的一条。集中的办公，使团队的沟通成本大大降低，效率也得到了适当的提高，并有力地促进了团队文化的形成。

2） SPRINT 规划与估算

此项仍然得到了所有项目成员的拥护，主要作用在于项目成员对于项目的范围、目标、进度安排均较以前有了清晰的认识，虽然存在偏差但估算过程令项目经理对项目的掌握能力增强。

但在执行的过程中仍然反思了一些问题。第一次的估算集体过于乐观，原估算两周完成的任务，实际上用了三周时间，并且还有一些完善性工作未完成。在SPRINT 中的BACKLOG 定义时，对那些技术预研、需求前期摸底类的工作未定义在BACKLOG 中，但实际上这些工作占用了较多的时间，且属关键路径任务。

改进计划：

l  识别技术预研、需求范围确认等工作，并列为BACKLOG 的任务包。

l  大的任务包需要更细的划分，例如新增用户，使程序间的耦合度降低。尽量使每天的工作输出可编译、可执行、可测试

l  适当预留缺陷修复的时间

3） 每日立会

这条也得到了大多数团队成员的认可，表现为对当天的工作目标清晰、明了。但也有一些大家未意识到、通过本次总结会总结出来的不足：

立会前，大家都没有事先思考哪些信息需要在会议上得到确认或支持，立会气氛较为沉闷，目前会议的效果主要是认领了任务。改进建议：

l  主动地将工作中的问题（技术或配合或业务等）在会议上提出，鼓励认领一些非本岗位的工作，提高自身技能。可能需要SCRUM MARSTER 做适当的引导。

l  在每天下班前，通过团队的短暂例会，将第二天的计划工作内容进行预览，使大家在第二天的立会前有时间进行有目的的思考。

l  提高会议的效率，在会议上不纠结过于细节的问题，对于细节问题可会后择时讨论。

l  早立会中提出的任务应是当天可以完成，如果当天不能完成就需要对该任务进行分解，使大家知道功能点在计划完成时间之内每天的进展

4） 进度墙

虽然本次迭代使用了进度墙，但是项目成员中仍无一人能够很好地表述项目的进展情况，不知道哪些任务已经到了哪些阶段，与之相关的下道工序不知道何时开展。

改进计划：完善进度墙，进行阶段划分，将每项任务的进展通过阶段进行明示。

5） 代码走查

本 阶段安排了代码走查的工作。初期采取的方式是每隔几天，安排一段时间（例如半天）对代码进行集体走查。走查的结果是发现的多为规范性问题，问题的严重或重 要程度都较少。后来将走查的范围改为代码、产品功能展示。团队成员对代码走查的认同度不太统一。部分认为走查非常好，有必要，发现了规范性的问题，学到了 编码规范以及别人的编码技巧等，这些以新手居多；另一些人则认为走查未发现重要的问题，但时间较多，是否有意义？

改进计划：阶段性的代码走查仍然会保留，但会收敛走查的范围。并通过结对编程的方式对代码的质量进行控制。

6） JUNIT

大概是目前公司做得最规范的项目了。项目组普遍认为使用JUNIT 进行单元测试耗时又没有效果。纠其原因是产品的逻辑层几乎分布在前台，而后台JAVA 部分逻辑十分简单，应用JUNIT 如同杀鸡用牛刀，而造数据又需要一定的工作量。

但出于日后回归测试、重构等需要，最后决定将继续尝试一段时间，可能对JUNIT 的应用范围稍做收敛。

7） QTP

也是项目组普遍认为鸡肋的实践。在本次迭代中，QTP 录制是在DEMO 完成之后就开始进行。由于是一个新的模块开发，所以测试人员即承担了手工测试的任务，同时还要完成QTP 的代码编写，造成了测试人员的工作紧张。而此阶段，自动化测试并未得到开展，等同于QTP 的产物并未得到实际应用。

测试组提出的建议是：将QTP 的编写时间放在程序编写完成之后，而不是DEMO 完成之后，这样可以减少测试代码的修改时间。另一个建议是在下一个迭代的需求阶段测试小组的相对空闲期，对上一迭代的内容编写自动化测试脚本。

QTP 是应用敏捷初期项目组最有期待的实践，他们迫切地希望解决回归测试中的测试工作量的问题。而本次迭代中由于是新模块，并不存在回归的问题，QTP 的作用未得到显示。

QTP 工作将继续进行，并参考测试组的意见进行完善。

8） 每日构建

本次迭代，初步建立了每日构建的环境，进行了短期的尝试。目前每天都有一份当日构建报告，但并没有成员对报告内容进行关注。这也是下阶段需要重点改进的地方。

 

总 的来说，已经在实践的几个敏捷方法中，管理性的工作相对容易执行，而技术性的工作执行中存在较多的困难、疑惑。在迭代初期，大家对这些方法与实践还抱有较 高的热情与好奇，在迭代的中后期，又有些陷入日常事务中，逐渐模糊了敏捷的每天都要思考如何进行改进的目标，在今天的总结会议中，大家又似乎有种恍然大悟 的感觉。正如项目经理所总结的：我觉得我学习了，但还未学习到。

形似而神不似。可不是？但这个团队还是勇气可嘉的，加油！