第一次迭代开发心得

第一次迭代思考总结

　　上周我们完成了第一次迭代开发的验收，自我感觉良好，看见一个项目从自己手里从抽象变成具象，还是挺有成就感的。下面就来分享一下我的第一次迭代开发的心得。

设想和目标

　　1. 我们的软件要解决什么问题？

• • 　　我们的软件的目的是让辅导员老师查寝简单化
  • 　　典型用户：在校大学生，辅导员老师

        2. 基本实现第一次迭代计划的目标，第一次迭代开发的任务大致如下

• • 　　登陆注册
  • 　　信息验证绑定
  • 　　照片与位置的绑定
  • 　　照片与位置的上传

　　3. 暂未投入使用，用户目前只有我们开发人员。项目难度对我们来说难度不是很大，但是要学习很多新东西，要投入大量 的时间消化理解新知识，而学习的这个过程又是特别枯燥的。但总体来说，我觉得我们每个人都有巨大的收获。

计划

　　1. 开发的计划。我们对这个其实计划的并不是特别明确，没有特别的去计划开发进度。这导致我们在验收前一天才开始做模块的集成，而这一天的工作量就很大，我们在集成过程中碰到了很多之前没有遇到过的问题，虽然验收时没有出现bug，但是我们知道这存在幸运的成分。

　　2. 分工计划。我们对分工还是很明确的，基本上是3:2。Android开发三人负责，后台程序两人负责。自我感觉这个分工还是挺合理的。虽然中间经历了分工调换，但是也没有特别大的影响，大家对自己负责的模块完成的还是很好的。

　　3. 项目进展的很顺利，虽然有突击完成的成分，但是alpha版本的迭代计划全部按计划完成了

　　4. 一些小问题。首先，我们没有任何开发经验，这导致我们对项目的细节没有处理的特别细致，没有给自己留下一些缓冲时间，完全是在deadline前一天赶工进行模块集成的，还好大家自己的模块都写完了，也没有出现什么大的问题，不然肯定后悔死。其次，就是Android Studio这个东西经常出一些小问题，之前我项目发给苏文江同学，他在build.gradle中添加了一句依赖库，再发给我就不能运行了，这个问题至今没有找到解决办法，中途我还把Android Studio卸载重装了两次。。。。

　　5. beta版本的开发中改进的地方。通过这次的开发过程，我们发现大家面对面一起做开发的效率其实比单人要高很多，因此决定，每周抽几个时间段，大家一起做开发（目前正在实施）。其次，我们明白了计划赶不上变化，要给自己留下足够多的缓冲时间，因此大家决定在老师给出的deadline前一周争取完后基本功能。

 资源

　　1. 时间资源对我们来说还是挺充足的。但是因为小组成员自己的一些安排，导致时间并没有被充分利用

　　2. 我们并没有对测试做系统的、详细的安排，通常大家都是自己测试自己的模块。而且大家也没有详细的记录测试中出现的问题，以及bug的复现情况。但是单独的测试人员又是不太现实的，因为我们还没学过关于测试的一些知识。

　　3. 在alpha版本的开发中我才知道一个美工的重要性，因为我们的界面是真的丑死了。

　　第一次迭代我的任务是要进行android开发，之前根本没接触过这些，所有的东西都是现学现用，而且感觉自己学的还不是很好。但总体来说还是收获挺多的的，也碰见了不少问题，尤其是在模块整合的时候。

变更管理

　　1. 在alpha版本的开发中，我们的开发意见较为统一，其实没有过特别大的变更

　　2. 对于核心功能，大家的认知是非常统一的，即使有问题，也会提出来大家一起解决，分歧比较大的时候回暂时搁置争议。所以，从一次迭代计划定下来后，就没有进行过调整，我们也清楚自己的工作效率，明白自己能够完成。

　　3. 我们没制定过变更计划。不是自信，而是根本没考虑过，下次迭代会注意这个情况。

设计实现

　　1. 项目的设计是在项目初期，也就是5-8周左右。由大家讨论以及和老师沟通后完成设计。

　　2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？没有

　　3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？仅使用过starUML来帮助设计，其他的没有。但是我们对各个功能的各个模块进行过简单测试

　　4. Android开发过程中遇到过形形色色的问题，因此安卓的每个activity都需要好好测试

　　5. 代码复审（Code Review）是小组间互相审查的，较为严格地执行了代码规范。而且我觉得评审我们代码的小组评审有失公允。首先，我们采用javadoc的注释规范，他们小组嫌弃我们注释过多，给我我们扣分了，很生气。其次，对于字符的判断，我没用正则表达式也扣了我们的分数，我们脑子里都是？？？？

团队的角色，管理，合作

　　

　　1. 团队的角色分工是自愿进行的，尽量符合了大家的兴趣，也能尽每个人的全力。

　　2. 团队之间交流很多，有非常好的团队氛围。我们只在技术实现上出现争执，团队非常团结。很荣幸能和这样的小组成员一起完成这个项目。

总结

　　我们是验收的前一天才开始进行相关模块的整合的，在这之前，前后台只做过相应的通信测试，没有具体的整合起来。因此，我们遇到的第一个问题就是在前后台的通信的JSON的数据解析方面出现了一些分歧，不过好在大家都乐于接受他人的观点，也懂得自身的不足，因此，这个问题很快就得到了解决。其次，也是问题最不起眼但最令人头大的问题——传参时数据类型不匹配。这个问题主要存在与我们前台的编写中，因为安卓界面多，任务重，因此我们分了三个人来完成这些，但因为大家在设置某个类型的时候没有注意，一个人设置了String类型，一个人设置的是int类型，导致Android的activity一打开就崩溃，这个问题我们在第二次迭代开发中一定会注意。再者，第三个也是非常蛋疼的一个问题。在模块组装之前，我们都对相应的模块进行过测试，确认没有问题后才进行组装。但有时候两个模块一起运行就会出现问题，我们检查出来其原因是我们在跑子线程的时候没有利用Android的handle机制去阻塞UI线程，导致我们的结果跟预期的不相符。

　　我们的代码块整合是我们组成员一起在天马园区内的学府时光进行的，从早上10点弄到学府时光打烊。。。。。。但是这次集体开发的经历还是很值得纪念的，我发现大家在一起进行面对面交流的时候，解决问题的效率要比仅通过网络高很多，有什么问题提出来，大家能够很快速的通过讨论把它解决掉。而且，我们在整合的时候，大家集思广益，有什么想法就提出来，好的予以采纳，坏的予以驳回，对大家其实都帮助很大。因此，我们组决定在第二次迭代的过程中，不仅仅要每周开会讨论，也要每周进行一次集体开发。

　　希望第二次的迭代开发，我们也能够圆满的完成任务