1 敏捷成果展示关于本章
本章描述内容如下表所示。
1.1 对比数据
敏捷前后的数据比对如表1-1所示。
表1-1数据对比
1.2 敏捷成果总结
通过此次敏捷项目迭代开发，我们认识到以下几点：
1.持续集成是一个在实践中不断发展和完善的过程。
对于一个团队而言，引入持续集
成对于提高开发效率和规范开发过程是必需的。
ICP构建是整个持续集成的依据。
2.结对编程作用是尽量减少BUG率和提高工作效率，同时结对人员相互间也能提升
技能。
结对编程虽然很好，但不需要整个迭代过程中都使用结对开发，如下两种情况：
−修改BUG或维护系统时，开发人员并不太希望结对，因为这种情况下全部盯着
调试代码没什么太多好处。
−迭代期间的重复工作，问题解决方案已经明确确定，结对的意义也不是太大。
3.信息共享和沟通非常重要。
敏捷项目想获得成功，项目组成员之间必须保持良好的
沟通，共享彼此的信息。
良好的沟通可以保证理解需求的时不会出现太大偏差，编
码时也不会出现修改了别人的代码，而别人却不知道的情况产生。
2 敏捷经验总结关于本章
本章描述内容如下表所示。
2.1 项目实施流程
2.2 设计人员在项目中扮演的角色以及经验总结
缺少
2.3 项目负责人在项目中扮演的角色以及经验总结
在项目实施过程中，项目采用敏捷迭代开发模式。
初次尝试敏捷开发模式，对各方面流
程都不熟悉，只能在实践中摸索前进。
项目进行过程中，采用了头脑风暴、故事卡、故
事墙、站立会议、结对编程等一系列敏捷流程，头脑风暴让大家对需求有了一个更好的
掌握。
故事卡、故事墙、站立会议让大家可以对项目每个Story的进度有了一个直观的
知晓，结对编程从一方面来说减少了BUG率，也从另一方面加强了结对人员间的沟通
能力。
2.4 开发人员在项目中扮演的角色以及经验总结
敏捷中开发人员主要工作流程任务模块的认领→头脑风暴→Story编写→故事卡→结对
编程(功能的实现)→单元测试→功能测试。
1.参与头脑风暴之前要对自己负责的模块充分了解。
并有自己的实现思路，在头脑风
暴中可以将自己的思路结合SE的讲解将需求进一步明确。
作为开发人员头脑风暴
之后的效果应该是绝对明确自己的功能需求，并且有清晰的实现方案。
2.敏捷中的功能点一般都是划分的很细小，所以在Sotry中要尽量的将功能点提醒清
楚的描述出来，相关测试人员应该也要提供相应的测试方案在Story上面体现。
3.故事卡的编写，需要用最简单明了的语言展现出自己的功能点需求。
4.结对编程在互相学习和积累经验的同时，沟通尤为重要。
所以在明确需求的情况下，
对于实现方案的问题上还是要注意与相关结对人员做好沟通的，要在意见统一的情
况下在进行实施，并且一定要严格监督对方的代码质量。
5.站立会议，就是把自己的进度报告给组内的其他人员，并且关注他们的进度变化，
另外如在开发的过程中遇到的问题也可以及时在会上沟通交流。
6.单元测试就是根据自己的代码做有针对性的测试，单元测试绝对不只是一种形势，
测试要求覆盖到每个代码分支，毕竟有些代码实现上的Bug隐患不一定是测试能够
覆盖到的。
2.5 测试人员在项目中扮演的角色以及经验总结
1.敏捷使测试人员更活跃与项目当中。
2.头脑风暴，让测试对功能点了解更清楚，对测试的点把握更准确。
3.敏捷过程中，每个功能按照story划分后，每个story的方案设计和UT测试都参与
进来，让测试对需要测试的代码流程和测试方案设计有很大的帮助。
3 敏捷实践总结关于本章
本章描述内容如下表所示。
3.1 我们应该继续做什么
1.头脑风暴
能使我们更加清晰自己的需求和实现方案
2.结对编程
降低代码BUG率，提高代码质量，还可以提高个人技能
3.故事墙故事卡
可以清楚的看到其他模块的进度。
4.Story
详细的展现模块的需求和开发方案
3.2 我们不应该继续做什么
1.工作效率总感觉没有太大的提高，每个人应该提高工作效率，避免不必要的加班。
2.执行力、主动性不够。
分派下来的工作没有很好的完成，总是需要叮嘱，缺乏主动
性。
3.没有及时真实地掌控项目组成员每天的工作进度，而是停留在所写的工作进度报告
上。
4.头脑风暴，开展的过于迅速。
5.敏捷团队要衡量自己的速度，不能让自己过于疲惫，保持一个长期的恒定的开发速
度。
6.每天的站立会议应该是在确认自己的进度，并把技术上面好的建议和意见共享给大
家，而我们却没有完全做到。
3.3 我们还应该做什么
1.在整个持续集成过程中，我们信赖的依据就是持续构建，其中对单元测试可靠性有
一定的要求，这样对于我们开发人员，如何保证写出高质量的单元测试便是一个挑
战，TDD是一个不错的实践，它完全从需求出发，逐步完善测试用例，不断减少
与需求的偏差来尽量满足需求。
同时引入测试覆盖率也利于我们审查我们的单元测
试。
本次项目没有做到测试驱动开发，主要有时间方面的因素，也有个人因素。
−对于一个没有接触过TDD的团队来说，首先对TDD理念不熟悉，项目迭代周
期较短，时间上也不允许开展TDD。
−从个人上说，TDD对一个人的个人素质和综合能力要求很高，TDD要求在写代
码之前首先你要很详细的了解需求，然后进行一些总体设计，再开始写测试，
这种测试的编写对一个人的要求很高。
写的不好有可能会影响整个项目的进度。
2.头脑风暴可以提倡全组人员参加，这样的话可以让每个人对整个工程都有大致的了
解。
3.提高项目组成员执行力和主动性。
4.制定良好的周工作计划。