| 团队名称 | 打代码一定要笑 |
|---|---|
| beta阶段随笔集合 | 团队作业第六次——beta冲刺+事后诸葛亮 |
设想和目标
1. 做这个项目的背景、意义是什么？要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
这个项目背景的是现代大学生对于浪费时间在琐事上愈发的厌恶而引发的，意义在于节约碎片化的时间。要解决大学生不想去取快递及其他生活琐事。定义的很清楚，典型用户就是学生，典型场景：一个住在3楼的大学生，周末有个快递到了，可他不想去拿，想在宿舍呆着，于是他用‘取经’发布了一个任务，住在同一栋楼5楼的另一个人刚好愿意去拿快递，他在取快递的路上通过‘取经’查看到了3楼同学的任务，帮他顺路拿了还赚去了积分。
2. 项目达到目标了么（原计划的功能做到了几个？在原计划之上是否有所拓展)
原计划的功能基本都完成了，还拓展了一些功能，比如忘记密码，管理员日志等。
3. 和alpha阶段相比，团队软件工程的质量提高了么？在什么地方有提高，具体提高了多少，如何衡量的？
和alpha阶段比，团队软件工程的质量提高了，具体体现在大家对于发现的bug都能很流畅的配合协调解决，不会出现像alpha阶段时互相掣肘的情况。
4. 设想用户量是多少, 用户对重要功能的接受程度和我们事先的预想一致么?
设想是一个福大的师生量，调查的用户对于功能都是肯定的，主要还是在界面美观上有所建议。
5. 有什么经验教训? 如果历史重来一遍，我们会做什么改进?
对于美工的态度吧，从用户反馈中来看有点太过于忽略美工的重要性。
计划
1. 和alpha阶段相比，每天是否时间规划的更好?
和alpha阶段相比，因为事前制定了每个人的详细工作，所以每天的时间规划都更好。
2. 团队在beta阶段是如何解决队友对于计划的不同意见的？
对于不同的意见一般通过讨论解决，我们组的所有人都是讲理且价值观差不多的人，一般讨论到后面都会有统一意见。
3. 你们原计划的工作是否最后都做完了? 如果有没做完的，为什么?
基本全部完成。
4. 是否每一项任务都有清楚定义和衡量的交付件?
是的，质量是不能放松的。
5. 项目是否出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
beta阶段还好，没有大的意外，按部就班吧。
6. 在计划中有没有留下缓冲时间，缓冲时间有作用么?
有，经历alpha阶段的意外后，我们提前预留了3天的加班时间，最后用了两天。
7. 我们学到了什么? 如果重来一遍, 我们会做什么改进?
组员学到了很多了新技术，而且配合的更好了。
资源
1. 有足够的资源（可以是时间、开发资源等）来完成各项任务么?
这次时间时间资源是够的，就是人手有点不足，拖得久了点。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
经历alpha阶段，我们对于所需时间的预估都变得更好了，精度控制在一天以内。
3. 和alpha阶段相比，测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
这次测试花费了3天的时间，不停的修修改改，还好时间充足，即使完成了。人力又有点不足，毕竟我们组只有6个人。美工设计的话，就按最低要求进行了。
4. 变更的组员工作如何？如果未变更是否项目完成效率会更高？变更的组员学到了什么？对于可能的变更是否能制定应急计划?
变更的组员工作还算可以，就是速度偏慢，未变更的话也不会更有效率，变更的组员学到了新的关于前端的知识，我们对他的工作，安排了另一个同学兜底防止意外。
5.有没有感到某个成员做的事情可以让别人来做（更有效率）?有什么经验教训? 如果历史重来一遍, 你们会做什么改进?
没有，大家各司其职，即使有的同学慢一点，也不会影响到大局。
设计/实现
1. 项目是否经历重构？为什么需要重构？
有，Controller重构过，因为一开始的设计不合理,方法之间的耦合程度比较高，出现一个地方出现错误的时候，会大面积的受到影响，不易定位错误的位置同时，修改一处代码可能会牵一发而动其身。
2. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
有进行单元测试。现在的uml文档会更加明确，相互之间表达更加明确了。
3. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
管理员操作影响用户端的bug是最多的，因为管理员端和用户端的负责人不一样，所以有些地方理解不一样，导致最后的呈现结果有差距。
4. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
代码复审由各自大模块下不同模块的负责人进行，要求严格执行项目开始时规定的设计文档。
5.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
有些产品细节还是要明确，否者会出现理解上的偏差。
测试/发布
1. 和alpha阶段相比，测试工作有提高吗？在哪些地方提高了？
有，测试的范围和次数变多了很多，力求细节。
2. 团队是否有一个测试计划？
是。
3. 团队是否有测试工具来帮助测试？
Visual Studio等。
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
软件测试由测试人员进行性能测试，从软件实际运行结果来看有一些效果。
5. 在发布的过程中发现了哪些意外问题？
管理员操作导致用户端显示意外，出现无法操作的‘死任务’。
6.我们学到了什么? 如果重来一遍, 我们会做什么改进?
对于软件的测试可以尝试使用更为专业的工具，传统的方法有点落伍。
团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
在alpha的基础上，林昌锴同学撞到管理员端，保证用户端的统一性。
2. 团队成员之间有互相帮助么？
有，大家有问题都会在开会时提出自己还未解决的问题，对于自己了解的方面都会去帮助。
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
出现这种问题时，一般都是通过开会讨论决定的。组长在其中进行了解及调解。
总结
1. 组员们自我总结
在beta总结博客里有，留个传送门。
传送门
2. 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
第三档次，吧。
3. 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
规范阶段
提高软件工程的质量
1. 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
这点没有考虑，我们只考虑了规范，没有想过进一步的提高，
2. 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
至少开发规约要遵守
3. 其它软件工具的应用，应该如何提高？
我们运用很多新工具，都是靠CSDN的大佬的文章一步一步摸索的，还是需要多去查资料，才能很好的运用。
4. 项目管理有哪些具体的提高？
要更注重细节的确定，否者实施了在修改很麻烦。
5. 项目文档的质量如何提高？
多参考其他大企业的公开文档。
6. 对于人的领导和管理， 有什么具体可以改进的地方？
小团队主要还是制度管理为主，人情管理为辅。
项目展示
1.演示视频
演示视频
提取码：x3g2