13组-Alpha冲刺-总结
一、基本情况
1.组长博客链接
https://www.cnblogs.com/cyt199709/p/15585212.html
2.现场答辩总结
3.全组讨论的照片
4.分工情况
| 工作流程 | 组员姓名 | 具体分工 | 组员工作量比例 |
|---|---|---|---|
| 登陆界面 | 陈艺天 | UI | 12% |
| 温致鹏 | 功能 | 13% | |
| 主界面 | 陈艺天 | UI | 15% |
| 温致鹏 | 功能 | 10% | |
| 设置栏 | 陈艺天 | 功能 | 12% |
| 温致鹏 | UI | 13% | |
| 个人中心 | 陈艺天 | 功能 | 14% |
| 温致鹏 | UI | 11% | |
| 总工作量占比 | 陈艺天 | 53% | |
| 温致鹏 | 47% |
二、总结思考
2.1 设想和目标
（1）我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述 ？
答：我们的软件首先要解决用户桌面过于混乱的问题。我觉得定义的比较清楚，因为市面上产品有太多可以供我们借鉴的了。同理，因为本组成员都是相关应用的资深用户，所以对典型场景都会比较了解。
（2）我们达到目标了么?（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
答：从实现程度上来看已经八九不离十了。但目前还没有投入市场，所以用户调查不足。
（3）用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
答：用户量也需要投入市场后一段时间再做评定，按正常进度进行的话肯定是离目标更进一步的。
（4）有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
答：经验教训可能就是喜欢临时抱佛脚吧。如果重来一遍肯定会更加迅速高效完成任务。
2.2 计划
（1）是否有充足的时间来做计划?
答：因为是毕业班。没有学弟学妹们时间那么多，所以时间显得有点仓促。
（2）团队在计划阶段是如何解决组员对于计划的不同意见的？
答：这个很简单。每个成员负责不同的模块，全权负责，这样就没有不同意见了。
（3）原计划的工作是否最后都做完了? 如果有没做完的，为什么?
答：：原计划的工作肯定事都做完了。没做完的可能就是和预想的那段差距吧。比如UI的和谐美观程度等等。但是我们时间实在不多，所以只能以实用为主。
（4）有没有发现做了一些之后看来没必要或没多大价值的事?
答：有吧。比如有一些功能其实是画蛇添足的比如个人中心里面的一些东西啥的，因为我们这个APP是没有服务器的也没有相关连锁产品，所以这个东西颇有点画饼的意味。
（5）是否每一项任务都有清楚定义和衡量的交付件?
答：基本都有。具体可以看每一轮的Alpha冲刺。
（6）是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
答：项目分为四个模块，有条不紊进行。本着以实现功能为主，所以功能实现了，测试下没什么bug可以正常运行就行。
（7）在计划中有没有留下缓冲区，缓冲区有作用么?
答：留了两天左右的缓冲区。缓冲区没有起到作用，因为都按时完成了，哈哈。
（8）将来的计划会做什么修改？（例如：缓冲区的定义，加班）
答：因为Beta冲刺周期缩短，所以缩短至1天。
（9）学到了什么? 如果历史重来一遍, 会做什么改进?
答：统筹协调规划能力提高、C语言代码运用能力提升、抗压能力提高。如果再来一遍肯定更加快速完成任务。
2.3 资源
（1）我们有足够的资源来完成各项任务么?
答：有的。时间=资源。
（2）各项任务所需的时间和其他资源是如何估计的，精度如何?
答：根据代码量来确定。根据后续完成情况来看和估计得差不太多。
（3）测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
答：软件比较小， 我们叫了其他几个同学来测试，完全足够。我们从来没有觉得美工设计和文案是很简单的事。
（4）你有没有感到你做的事情可以让别人来做（更有效率）?
答：有。毕竟人外有人天外有天吧。我感觉在座的大部分人的水平都是随便把我们两个吊起来打的。大家代码的功力水平都不一样，只是因为我俩负责这个项目得独立完成。
（5）有什么经验教训? 如果历史重来一遍, 会做什么改进?
答：经验教训可能就是喜欢临时抱佛脚吧。如果重来一遍肯定会更加迅速高效完成任务。
2.4 变更管理
（1）每个相关的员工都及时知道了变更的消息?
答：两个人。他考研复习回来的时候宿舍里说一句就OK。
（2）我们采用了什么办法决定“推迟”和“必须实现”的功能?
答：站立会议！站立会议！站立会议！开了六次呢。
（3）项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
答：可以稳定运行（检测），误报率在10%以下，能够抗基本干扰（戴帽子、趴在桌子上等）。
（4）对于可能的变更是否能制定应急计划?
答：项目太大可能管理不来，但是我们的项目很小。就算是重做也没什么问题。但是目前加起来2000行的代码确实比较繁琐，毕竟现在面临升学、就业压力，很多事情顾不上。
（5）组员是否能够有效地处理意料之外的工作请求？
答：我们的工作都是按部就班的，基本没啥意料之外的。
（6）学到了什么? 如果历史重来一遍, 会做什么改进?
答:统筹协调规划能力提高、C语言代码运用能力提升、抗压能力提高。如果再来一遍肯定更加快速完成任务。
2.5 设计/实现
（1）设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
答：设计工作在团队作业发布的前10天左右，由组长（陈艺天）完成。从时间来看未雨绸缪没啥问题，人选上看，陈艺天没有面临考研，自然会比温致鹏更适合。
（2）设计工作有没有碰到模棱两可的情况，团队是如何解决的？
答：没有的。1就是1，2就是2，泾渭分明。
（3）团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
答：团队主要使用UML来协助设计和实现。这些工具在一定程度上理清了项目的流程、队友的实现思路，指导了项目的完成。
（4）比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
答：项目开始的UML和现在的状态存在一定的偏差。偏差来源主要是使用的技术方法不同。UML文档计划更新。
（5）什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
答：当然是主界面。承担了软件的主要功能。在测试的时候出现了拖拽不进去、闪退等情况。设计的时候个人认为是没办法预见的，毕竟很多时候写代码就是摸着石头过河（对我们这种代码渣来说）。
（6）代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
答：代码复审交给各个队友分别进行。比如组员A负责的模块由组员B审核，组员B负责的模块由组员A审核。大家都比较严格执行了代码规范。
（7）学到了什么? 如果历史重来一遍, 我们会做什么改进?
答：统筹协调规划能力提高、C语言代码运用能力提升、抗压能力提高。如果再来一遍肯定更加快速完成任务。
2.6 测试/发布
（1）团队是否有一个测试计划？为什么没有？ 是否进行了正式的验收测试？
答：想要有。但是理想很丰满现实很骨感。毕竟不能算是实战项目，个人认为最大的意义就是巩固旧知识学习新知识，毕竟是课程设计嘛。进行了验收测试，验收标准可以看项目需求分析报告。
（2）团队是否有测试工具来帮助测试？
答：暂时没有使用测试工具。
（3）团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
答：主要看CPU占用度。在实现各种功能如拖拽、自动整理的过程中内存占用情况。
（4）在发布的过程中发现了哪些意外问题？
答：未出现意外问题。
（5）学到了什么? 如果历史重来一遍, 会做什么改进?
答：统筹协调规划能力提高、C语言代码运用能力提升、抗压能力提高。如果再来一遍肯定更加快速完成任务。
2.7 团队的角色，管理，合作
（1）团队的每个角色是如何确定的，是不是人尽其才？
答：软件四个模块每人负责各个模块的UI和功能，基本上人尽其才了，毕竟人力资源有限（只有2人）
（2）团队成员之间有互相帮助么？
答：难兄难弟再不互帮互助等着挂科么。（疯狂暗示）
（3）当出现项目管理、合作方面的问题时，团队成员如何解决问题？ 每个成员明确公开地表示对成员帮助的感谢 （汇总至组长博客）：
答：
陈艺天：我感谢温致鹏对我的帮助， 因为某个具体的事情: 熬夜写代码很累，第二天给我买了杯奶茶。
温致鹏：我感谢陈艺天对我的帮助， 因为某个具体的事情: 每天早出晚归准备考研， 出了代码的任务别的都没时间做，所以感谢他完成了其他琐碎的事情。
（4）学到了什么? 如果历史重来一遍, 会做什么改进?
答：统筹协调规划能力提高、C语言代码运用能力提升、抗压能力提高。如果再来一遍肯定更加快速完成任务。
