事后诸葛亮分析
Author：歪瑞古德小队
Project：海岛漂流
集合贴：团队作业6：复审与事后分析
一、会议照片
二. 设想与目标
-
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们所设计的是一款以信会友的匿名游戏化社交应用。其主要功能是：为用户提供线上信件交往的环境，它与传统的电子邮件不同，我们的软件会通过用户之间的距离来计算送达时间，模拟更加真实的信件环境。除此之外，我们还提供了树洞模块，海岛模块等，给用户的社交提供了多元化的环境。
典型用户：青少年
典型场景：
在信息化的现代体验不一样的社交，感受以往信件交流的乐趣。
-
用户量，用户对重要功能的接受程度和我们事先的设想一致么？我们离目标更近了么？
我们的用户量目前为300多，虽仍未到达预期数量，但是随着时间的推移以及应用商店的上架，我们的用户数应该会有所增加。目前用户对于程序还是比较满意的，不过距离我们的目标仍然有一段距离，我们正在朝着目标前进。
-
有什么经验教训？
在这次团队任务中，最大的问题在于前后端交互比较困难。由于今年是在线上开发，导致有时候前端在开发时遇到不懂的接口寻找后台开发人员时找不到开发人员。因此导致一些时间的流失。
三、计划
-
是否有充足的时间来做计划？
在开发软件的流程中，我们每一步都是做好了规划，并且组长也经常督促组员进行任务的完成。所以我们是非常重视计划的制定，因此是有充足的时间来制定计划的。
-
团队在计划阶段是如何解决同事们对于计划的不同意见的？
由于计划阶段是项目开发的前期，因此我们十分注重彼此之间的交流。因此我们也经常通过组内会议来讨论，而一旦出现了分歧，我们也会就大家的观点一起进行分析，找出其中的利弊进行权衡。这样一来，大家的观点也能得到统一，同时也增进了彼此之间的感情，有利于项目的进展。
-
你原计划的工作是否最后都做完了？如果有没做完的，为什么？
我们项目的进展还算顺利，目前我们的工作都完成了。
-
是否每一项任务都有清楚定义和衡量的交付件？
是的。我们每一项任务都由组长记录并且及时交代组员进行完成。我们项目的博客也按时交付。
-
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的？
我们项目基本按照计划进行，没有出现任何大的意外。小意外就是项目在最后打包的时候出现了一些问题，不过最后也是顺利解决。
-
在计划中有没有留下缓冲区，缓冲区有作用吗？
有。主要是用于计划之外的任务安排，例如项目功能没有出现预期的效果，我们就需要进一步的协商改进，因此需要缓冲区。
-
我们学到了什么？如果历史重来一遍，我们会做什么改进？
对软件开发有了更加深刻的理解，每一天都有每一天的任务，每天也都有每天的困难。如果重来一遍，我们会制定更加详细的计划，提高计划的执行效率。
四、资源
-
我们有足够的资源来完成各项任务吗？
是的。我们团队成员都是自己的工作室，在工作室中已经积累了一定的项目经验，因此我们开发起来比较容易，大家合作起来也是得心应手。
-
各项任务所需的时间和其他资源是如何估计的，精度如何？
任务所需的时间主要是根据任务量进行估计的，同时会增加一些相应的缓存区防止意外情况。客观上根据功能的难度进行判断，主观上根据自己平时编程所需时间来判断。综合两者得到结果
-
测试的时间，人力和软件/硬件资源是否足够？对于 那些不需要编程的资源 (美工设计/文案)是否低估难度 ？
测试时所需的时间和人力资源是足够的。我们的程序的接口对硬件的要求比较低，因此我们可以在比较理想的情况下进行测试。在美工方面，由于队伍中的设计师也是刚接触这项工作，因此完成上确实有点吃力，不过资源还是足够的。
-
你有没有感到你做的事情可以让别人来做（更有效率）?
在团队PM的带领下，每个成员都充分发挥了自己的作用，大家积极的投入到大项目中，因此完成任务的情况都是很理想的，不过对于个别任务的分配，我们也可以考虑更加优的选择，这样也有利于项目的开发
-
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
在任务分配的时候，有时候不一定某项任务就一定只能由某个人去做，大家可以共同做出自己的选择，选自己更加能够担任的任务，这样也可以做的更加得心应手。
五、变更管理
-
我们采用了什么办法决定“推迟”和“必须实现”的功能?
主要是通过时间和任务量上的考虑。因为任务分配是提前的，因此有时候难免会有些不可抗力因素阻碍了项目的顺利进展。
-
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
对于我们的海岛漂流应用而言，所谓“做好了”就是能够实现所要求的基本功能，我们的程序也许不是十全十美，但是我们会在收到反馈之后进行一定的调整，慢慢的调整我们的应用。
-
员工是否能够有效地处理意料之外的工作请求？
我们的团队成员彼此之前是和平相处的，大家平时除了一起工作之外，也会一起聊天，交流学习问题等，所以大家对于意料之外的工作请求是能够互相体谅的。
六、设计/实现
-
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作主要是在项目初期完成，是经过大家共同决定的。而且我们的设计师也是能够且最能够胜任这份工作的。
-
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
基本没有出现过这种情况。假如出现了是由大家进行讨论之后PM作出最终决定
-
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
我们用到了单元测试工具，这边为了测试不用模块的功能。这些工具也是极大了提高了我们的测试效率。
-
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
代码复审主要是由开发人员和PM斤进行。在代码复审时会严格查看开发人员的代码规范的。
七、测试/发布
-
团队是否有一个测试计划？为什么没有？
有，我们项目的测试计划是直接对接口的功能进行测试，并且对各种边界值进行测试，使我们的程序有足够的健壮性。
-
是否进行了正式的验收测试？
是的。我们对测试的结构撰写了测试报告
-
团队是否有测试工具来帮助测试？
主要还是通过APP还有POSTMAN进行测试。压力测试方面采用JMeter进行测试。
-
团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
我们通过进行多种选择的尝试来达到最好的效能。从结果来看，这有利于我们更好的了解我们的程序的性能。
-
在发布的过程中发现了哪些意外问题？
主要是发布平台的严格，程序未按预期正式上线。
八、团队的角色、管理、合作
-
团队的每个角色是如何确定的，是不是人尽其才？
首先我们是根据各自的兴趣主动选择，大家都尽到了自己的能力。
-
团队成员之间有互相帮助吗？
有的，在遇到困难时，我们的组员会向组内询问求救，有能力的同学会帮助解决问题
-
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
因为我们有自己的任务表，所以我们的分工是非常明确的。当出现项目管理问题或者合作问题时，PM会此时进行协调。
九、总结
-
你觉得团队目前的状态属于CMM/CMMI中的哪个档次？
我觉得我们的团队能够达到CMMI三级，定义级。 我们能够对项目的实施有自己的一整套管理措施，并且也能够保障项目的完成，而且，我们也能够对特殊情况做出及时的调整。
-
你觉得团队目前处于萌芽/磨合/规范/创造阶段的哪一个阶段？
我觉得我们到达了规范阶段，我们对于项目的开发都有自己的流程。
-
你觉得目前最需要改进的一个方面是什么？
用户量的提高
-
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
对于项目，我们都是尽早交付的。并且我们也欢迎用户进行反馈并及时做出调整。
而在项目过程中，我们的业务人员和开发人员是一起的。
团队要定期反省如何能够做到更有效，并相应调整团队的行为。
-
项目管理的质量具体应该如何提高？代码复审和代码规范的质量应该如何提高？
项目管理质量：
开发者要有自己的一套管理体系
代码复审：
测试人员测试功能无误后交由复审人员进行代码规范的复审
代码规范：
项目初期制定一套代码规范，并且开发人员必须严格遵守
-
其他软件工具的应用，应该如何提高？
对于其他的诸如测试工具，数据库设计工具等，我们应该尝试使用，有助于项目的高效率开发
-
项目跟踪用户数据方面，计划需要提高什么地方？例如你们是如何知道每日/周活跃用户等数据
由于这是一个我们自己开发的程序，因此我们可以通过日志系统来监控用户的活跃度。
-
项目文档的质量如何提高？
对于项目文档，可以通过模板来辅助。同时也需要文档撰写者有一定的经验，同时借助其他工具辅助文档的描述，包括图形等。
十、团队成员在Alpha阶段的角色和具体贡献：
| 名字 | 角色 | 团队贡献分 | 可验证的贡献 |
|---|---|---|---|
| 黄钰朝 | 后台开发&PM | 22.3 | 担任项目的管理，任务规划，博客撰写，海岛功能模块开发， 信件功能模块开发，对项目进行细节处理 |
| 丘丽珊 | UI设计 | 19.1 | 担任全部UI设计包括一些元素的设计，会议照片的设计以及成员照片设计 |
| 黄煜淇 | 后台开发&架构 | 19.2 | 定时任务开发，时间胶囊模块开发，海岛动态模块开发，架构文档撰写 |
| 陈宇 | 后台开发&测试 | 19.0 | 树洞模块开发，海岛动态模块开发，测试文档的撰写 |
| 余圣源 | 前端开发&测试 | 21.1 | 邮票界面开发，树洞界面开发，时间胶囊界面开发，打包为安卓应用 |
| 张文俊 | 前端开发&测试 | 19.3 | 海岛界面功能开发，草稿箱界面开发，帖子模块功能开发， 辅助打包安卓应用 |
