第一次迭代开发心得
第一次迭代在辛酸悲苦的8周后终于落下帷幕。N瓶雀巢（无打广告嫌疑）的陪伴 ，与同伴激烈的思维碰撞，是体验，更是收获。从一开始的一头雾水，到现在的略懂略懂，其间，冷暖自知。少不了的小抱怨，在尝到小成果的甜头后都烟消云散，化为第二次迭代的积淀，化为bug显著减少的庆幸，化为对老师，队友的感恩。说完心路历程，以下严肃的做一次自我总结。
设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
- 我们的项目是做一个帮助辅导员查寝的APP-智能查寝，结合学生的生活实际，要解决的问题很明确，就是返回给辅导员同学们在不在寝室的结果，并在此基础上实现能通过语音通话，视频通话，一键拨号联系学生。
- 智能查寝一开始的定义就是基于大学生的生活实际和导师的老师查寝经历的，而我们和导师的身份和生活实际完美契合定义，所以，APP的定义从一开始就很明确。
- 智能查寝的用户分为两类：教师+学生，在界面中都有明显的区分标识，进入的用户类型不同，就有不同的场景与之对应。教师：发布查寝。学生：接受查寝。
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
在第一次迭代中，原计划实现等级较高的功能：注册，登陆，信息绑定，信息验证，学生端上传位置，上传照片，老师端发布查寝，接收查寝结果。基本功能在此次迭代中已经按时完成，剩下的就为附加功能和提升用户体验感的优化上面了。
3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
相比起上一阶段的懵懂，特别是在代码复查之后，发现原来不知不觉中，整个团队的代码风格都趋于规范化，后台端向java规范靠拢，前端向Android规范靠拢，都在使劲的向规范化看齐。工程质量有了一定的提升，至少从对方团队对我方代码规范检查上来看，大毛病是没有的，基本上做到的统一风格（悄咪咪的吐槽一下，像建议这种就不要扣那么狠的分了吧，毕竟没有实质性的错呀，委屈巴巴😢） 。
计划
1. 是否有充足的时间来做计划?
由于我们团队在结对编程阶段就一直保持沟通，无论是组员间还是和导师间，所以总体上来说，计划时间紧凑，但由于时间紧，任务重，还是没有充足的计划时间。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
在每次的小组会议中，PM首先发言，引出本次会议要解决的问题，然后各小组成员提出自己的意见，发言完毕后思维碰撞开始啦！激烈的讨论如火如荼的展开，也正是这种形式，使得每一个成员都能充表达自己的真实想法，最终，以多数人的胜利收场。毕竟，真理掌握在大多数人手中的。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
第一次迭代的计划，在第十二周中完成了，交出了四分之三的合格半成品。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
在初始的小白阶段，由于对啊、Android框架的不全面了解，做了许多现在看来lowlow的界面。随着知识面的扩充，强迫症的意识不允许我接收这样的“小小丑”，于是，全盘推翻的事情是家常便饭。但我不后悔之前的付出。也正是有了此前的“无用功”，才能有拔高的基础。感谢那个奋斗的自己。
5. 是否每一项任务都有清楚定义和衡量的交付件?
对于每一项任务，我们在计划中已经将它细化到了个人层面。在每一次的小组会议中，也会就个人进展情况做说明。大家心中都有行走过的地形图，这就足够了。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
很庆幸，我的每一个队友都很认真负责，加之在真个团队的监督和导师的指导下，项目在第一次迭代阶段完美的按照计划进行。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
缓冲区？！所谓的缓冲区是指我们做其他科作业的时间吗？！
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
看着进度表，缓冲区是不存在了，加班已成为日常，不用修改啦。
资源
1. 我们有足够的资源来完成各项任务么?
资源是要靠自己的。正所谓自己动手，丰衣足食。图书馆也不是白泡的，很多意想不到的学习资料足以让你目瞪口呆。加上付费的FQ资源，足以满足你求知若渴的💗。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
计划总是那么完美，然而计划赶不上变化来的快。所以，我们只能做好充分的准备来迎接未知的变化。至于精度嘛，不能总是保持高效且时间安排总会有意外的冲突。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
就第一次迭代完成的情况来说，测试的时间是明显不够用的，我们只能按照功能实现的优先级从上倒下依次测试。美工设计方面我们计划在第二次迭代中完善。提升用户体验感也是我们追求的目标之一。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
如果一位Andriod大牛来做我的工作的话，我想，效率是成倍数增加的！可惜没有如果。委屈巴巴
变更管理
1. 每个相关的员工都及时知道了变更的消息?
群聊的优势在团队合作中得到了充分的发挥。队员要变更任何计划，都在群中吼一声，不仅队员间及时知晓了变更消息，导师也能掌握项目的进展情况，帮助稳定项目的大致框架，及时纠正倾斜之处。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
我们将功能按照必要程度排了优先级，对于那些优先级高的功能，没有推迟的理由，只能提前完成。其余优先级低的功能，是要实现，但在时间上可以稍微宽松一些。人性化的做出微调。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
在目前的认知阶段，我认为，项目出口的条件就是在满足需求的同时经得起各项测试，能做到提升用户体验感的优化是极好的。
4. 对于可能的变更是否能制定应急计划?
变化永远都来得那么突然。我们不能保证能预测所有变化，但还是在我们的脑洞范围内猜想了各种情景，对能想到的突发情况，制定了相应的plainB。
5. 员工是否能够有效地处理意料之外的工作请求？
不知道要庆幸多少次我的靠谱的队友了。关键时候毫无怨言的扛起大旗，敬佩敬佩！
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
项目的设计工作在项目开始初由整个团队和导师一起沟通完成。做到的全员参与，全员了解，全员赞同。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
在制定计划的时候，我们就有意识的将每个小功能的实现细节计划到了每个人头上，避免了日后遇到模棱两可的问题。现在看来，是十分机智的做法。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
我们运用了UML文档来协助我们完成项目。事实上，UML文档不仅协助我们明确了项目的需求，还帮我们理清了整个项目了逻辑。像一盏这路灯。当然，一开始完成的ULM文档不是完美的，随着项目的推进，各成员对项目进展的了解，对UML文档进行了增添和修改，不变的，是照亮目标的灯光。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
在第一次迭代阶段，暂时没有发现大问题的Bug，不满意都体现在了用户体验不是最佳的欠缺上。在接下来的迭代中，会针对提高用户体验感这一大的突破点增加人力时间的投入，完善不足。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
代码复审还没有进行，代码在协作中有了规范。
测试/发布
1. 团队是否有一个测试计划？为什么没有？
具体的测试计划在现阶段还没有完成。因为项目还没有竣工，成员对整个项目还没有全面掌握。我想，只有在项目完成后，成员们才能知晓薄弱之处，可能存在的缺陷。到那时做出来的测试计划才更有针对性，测试效率也越高。
2. 是否进行了正式的验收测试？
真正的验收在第十六周进行，第十二周完成了第一次迭代审查，交出来四分之三的合格半成品。
3. 团队是否有测试工具来帮助测试？
就目前阶段而言，时间和人力方面都限制了我们采用测试工具帮助测试。但在余后的开发中，一定会紧跟前进的步伐，使用测试工具来提高效率和精准度。
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
软件还没有发布，暂时不用考虑测量并跟踪软件的效能，但在发布后，会组织专门的人员搜集用户的使用体验，意见和建议，修复Bug，发布新版本以提高用户体验感。
5. 在发布的过程中发现了哪些意外问题？
还没有发布呀
团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
团队就像一个小家庭一样，每个人都有自己的职责。首先要尊重大家的意愿，在满足大多数人的前提下作协商，尽量做到皆大欢喜。但每个人也有为大局意识，如果牺牲小我能换取大我，那这种牺牲是值得的。我们团队在这些方面充分以人性化为前提，尊重了大家的意愿也充分发挥的个人所长。
2. 团队成员之间有互相帮助么？
我们的团队之间，都有密切的合作关系，互帮互助是合作的必要条件。我们也确实做到了。再次感谢大佬们在我电脑罢工期给予我的帮助！实名感谢！
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
首先，沟通是解决问题的桥梁。我们通常会以线上沟通和线下会议沟通的方式进行，如果还不能解决，那么导师伸出援助之手。
总结
1. 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
属于CMMI一级，完成级
2. 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
磨合基本完成
3. 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
- 大家彼此更加熟悉，互相的配合会比之前更有效率
- 代码更加规范了
4. 你觉得目前最需要改进的一个方面是什么?
- 增加代码的可读性和可维护性
- 增加团队极限编程的时间
- 制定测试计划，如果各方面条件允许，利用测试工具协助测试
