第六次团队作业——Alpha冲刺之事后诸葛亮
一、设想和目标：
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件主要是解决计算机相关专业的同学找不到 适合自己的具有专业实践性质的兼职来锻炼自己的问题，以及中小型计算机相关项目难以找到合适的兼职人员的问题。
是。
是。
2. 是否有充足的时间来做计划?
是，张栋老师整整留了一周来给我们做产品需求规格说明书，这期间我们经过了相当详细的考虑，而且在第一次展示了说明书以后我们也根据老师的建议将计划 进一步修改完善。
3. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
我们采用的是每个人认真的阐述自己的观点并指出为何别人的观点不适宜于我们的项目，而自己的观点高明在哪里。在所有人阐述完毕以后我们再举行民主投票，采用支持者最多的观点。
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
用户量与我们事先的预想不太一致，因为我们事先预想的是做一个通用的兼职交流平台，这里面 对于兼职的种类是没有规定的，而在老师的建议下我们修改为只为计算机相关的兼职提供交流，用户量显然是减少了很多。
用户对于重要功能的接受程度我们暂时无法得知。
确实更近了。
这里面的经验教训就是我们在人手、资源完全不足的情况下 不应该选择一个过于宽泛的产品定位，而应该做精做好。
如果历史重来一遍，我们会认真考虑好我们的产品与类似的产品差异化的点在哪里，而不是像现在这样差异化不够明显。
二、计划：
| 姓名 | 你原计划的工作是否最后都做完了? 如果有没做完的，为什么? | 有没有发现你做了一些事后看来没必要或没多大价值的事? | 是否每一项任务都有清楚定义和衡量的交付件? | 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到? | 在计划中有没有留下缓冲区，缓冲区有作用么? | 将来的计划会做什么修改？（例如：缓冲区的定义，加班） |
|---|---|---|---|---|---|---|
| 胡泽善 | 没有做完。没有做完是因为我高估了自己学习应用新知识的速度并且低估了实际的工作量。因为这是我第一次在项目中编写安卓前端代码，我经常到做的时候才发现我需要学习一项新的知识来完成需求，这大大拖慢了进度 | 例如在编写头像的选择模块时，我以为比较复杂，需要用到一些开源库，所以我花了大量的时间去网上查找阅读相关资料，结果却发现只需要简单的调用系统提供的组件就可以了。这说明要想真真的掌握安卓的知识，仅仅是了解的话很容易走弯路 | 不是。因为我们的项目经验缺乏，规划不够成熟。我们经常遇到在实现代码时才发现预想的实现方法无法达到目标，需要改变策略。同时为了完善项目，网络接口也变更了多次，这导致我的前端代码在编写时变化较大，所有不是每一项都有清楚的定义 | 不是，比如我突然发现安卓后端的代码存在问题，而我无法修改，编写安卓后端的人也正好没空修改，或者修改需要时间。我在缺少数据的情况之下就无法继续编写下去，因为无法调试；当时没有估计到的风险就是不得已在项目进行中重新修改数据库，或者根据数据库重新修改前端代码。因为我们当初认为讨论的很细致了，而实际上还是有细节没有讨论到，导致两端的功能理解不一致，无法对接 | 没有留下缓冲区 | 将来我们将会把缓冲区定义为在完成一个大的功能后留下一天的时间来回头自己查看自己编写的功能是否不慎留下了没有实现的点，又是否留下了遇到过的BUG而忘记修改了。同时也可以考略下个大任务的实现是否修改；我们组一直都没在写项目时加班的概念，我们仅仅在Alpha版本的展示前加班改正了已知的BUG。这是因为我们认为加班是因为自己的不够自律，是对自己不遵守规划的补救，我们不会把完成计划寄托在加班上。当然，如果中间的大总结发现问题会要求加班解决 |
| 彭 巍 | 做完了 | 基本没有 | 基本没有，后台接口是根据原型设计的，如果有需求变动，再根据需求调整 | 是的 | 有留下缓冲区，是为了应对可能的突发情况，比如遇到一个功能需要学习一下知识才能完成的情况，或者遇到比较难改的BUG | 交给前端的东西应该和前端商量好，再去做 |
| 洪佳铭 | 由于分配搭配的工作较为简单，所以计划中的工作都已经完成 | 在开发过程中还是做了一些现在看来没有多大价值的事，毕竟是第一次，没有什么经验，走了一些弯路 | 是的，每一项人无都是经过充分的讨论以及比较之后才进行实施的 | 项目进程与原本的计划还是有些许的偏差，由于后台接口的部分问题，部分内容并没有完美实现，由于没有经验，事先没有考虑到项目的复杂性 | 计划中留下了缓冲区，缓冲区给我们的项目带来更多的容错率，是我们后期没有遇到太大的困难 | 接下来会考虑到项目进程中遇到的突发问题，以及遇到问题如何解决 |
| 张建明 | 做完啦 | 没有 | 没有。大致知道做什么就开始做了 | 这个差不多按照计划走的 | 有的，大家进度不一样。还是有作用的。就是休息时间变少了 | 没什么修改的。按时完成计划的任务就行了 |
| 吴宇轩 | 做完了 | 原先的一些计划功能模块后面发现可以与其他的合并 | 一部分有，有些还是按定义去写，视实现情况收尾 | 有时候临时有事当天的计划不能及时完成，会造成拖延 | 预留一小段时间，缓冲区有用，用来弥补了正常计划中没完成的工作 | 多为意外不能完成任务的情况预留时间 |
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学到了在项目中尽量为日后可能的修改提供空间。如果重来比如留下可供修改的接口等，这样子的话既能提高项目的可扩展性，也能避免去修改前面已经编写好的代码。学到了计划并不能完美地执行，过程中可能会遇到许多的问题需要重新讨论解决，如果重来一遍，我们不会过分地注重计划，而是注重过程。
三、资源：
1. 我们有足够的资源来完成各项任务么?
当然有
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
每天就想着完成指定的东西,没有考虑精度
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
确实低估了.美工排版确实是个难题
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
当然不会.相反我觉得我更有效率
四、变更管理：
1. 每个相关的员工都及时知道了变更的消息?
是的，我们建立了一个群，有问题随时发到群里，大家都会经常查看群，看到问题都会尽快做出反应，寻找解决办法；代码使用GIT管理，大家都可以看到最新的代码。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
功能基本上是刚开始就确定好要做哪些功能，所以都是必须实现的；我们主要根据难易程度和重要程度决定先实现哪些功能。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
并没有清晰的定义，但是目前的目标就是已经完成对接的功能要可以正常运行。
4. 对于可能的变更是否能制定应急计划?
我们的人员比较少，大家各负责一部分，所以变更属于谁负责的那部分，谁解决。
5. 员工是否能够有效地处理意料之外的工作请求？
这种问题我们都会先反馈到群里然后大家讨论决定。
五、设计/实现：
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
是由胡泽善来完成的。是由合适的人但是时间太紧，不太合适。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有，比如说我们在用户名到底是用来作为登录的账号还是仅仅作为除账号以外的身份标识有了分歧。这一分歧直接导致数据库的设计和前端要求的不一致，最后我们是尽量减少数据库的修改，另外添加了一个属性达成目的。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
我们有使用UML以及思维导图来展示我们的设计成果。这些工具很有效，能够直观的表示功能而不会出现语言上的分歧
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
各个列表显示功能的BUG最多，因为列表加入了各种刷新以及异步加载后很容易出现多线程以及接口导致的BUG。发布之后还发现我们的我们的简历无法显示。
因为当时没办法细致的考虑到代码的实现方法，实际编写的时候互相之间不了解对方的实现方法，容易出错。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
我们组人手不足，所以没有能够进行代码复审，更多的是依靠测试时发现BUG并修复。代码规范执行不严格，注释的编写细致度不一致。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学习到了实现时也要抽空整理出简洁但是描述了所有必要信息的文档。如果重来一遍我们会要求所有人都对自己的代码作出细致描述。
六、测试/发布：
1. 团队是否有一个测试计划？为什么没有？
团队没有测试的计划，由于时间较紧，所以没有考虑到测试的问题，在后期才开始考虑测试
2. 是否进行了正式的验收测试？
进行了正式的测试验收，在项目交付前进行了系统的测试
3. 团队是否有测试工具来帮助测试？
团队没有使用测试工具来帮助测试
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
团队事使用人工使用来测量软件效能的，从结果来看，这些工作还是起到一定的作用的，但是效率不高，后面会考虑利用工具来实现
5. 在发布的过程中发现了哪些意外问题？
发布过程发现部分功能存在bug，于是在发布前又进行了一次修复工作。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学到了测试是一个很重要的环节，因为在测试的过程中会发现开发过程中没有发现的问题。如果再来一遍，我们会事先做好测试的计划，并且准备好测试的工具
七、总结：
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
二级
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
磨合
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
对自己分工的工作的完成度更高了
你觉得目前最需要改进的一个方面是什么?
沟通交流上还需要加强
