团队作业6——事后诸葛亮分析

总结

设想和目标

1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

黄芯悦：本系统包括了社区内管理各项功能，并针对住户和物业人员两个角色给予不同的权限，从而解决社区管理混乱复杂的问题，达到减少人力资源的使用和降低管理费用、提高信息准确度和可靠性、改进社区管理和人员服务和建立高效的信息传输和服务平台、提高信息处理速度和利用率的效果。定义清楚并对典型用户和典型场景有清晰的描述。

2. 是否有充足的时间来做计划？

黄芯悦：有。

3. 团队在计划阶段是如何解决同事们对于计划的不同意见的？

黄芯悦：针对提出的不同意见，全组组员通过线上会议和群聊进行讨论权衡或以投票形式来决定最终意见。

 

计划

1. 你原计划的工作是否最后都做完了？如果有没做完的，为什么？

方晓莹：没有。大部分都完成了，小部分是能力不足或花费的时间较多，暂时搁浅。

黄芯悦：基本完成。剩下的一些细节由于时间不够而放弃了。

舒雯钰：由于没有涉足难度大的开发工作，所以我能完成我原计划的工作。

方子茵：没有完成计划工作，后台开发零基础，没有做好时间管理。

许嘉威：全部完成了，部分接口时间不足弃用功能。

利国铭：部分做完，因后台开发知识匮乏，没跟上节奏。

2. 有没有发现你做了一些事后看来没必要或没多大价值的事？

方晓莹：有一些，比如说过于纠结页面的某些样式结构，花费了大量的时间研究，最后还是舍弃了这部分内容，因为不合预想或不如之前的好。

黄芯悦：有，例如在开发页面时会对一些细节过于钻牛角尖，事后发现并没有必要纠结。

舒雯钰：没有。

方子茵：没有。

许嘉威：没有。

利国铭：没有。

3. 是否每一项任务都有清楚定义和衡量的交付件？

方晓莹：是，每一项任务都通过github的issue分模块定义，清晰标明了组员的任务情况、进度进展和交付情况。

4. 是否项目的整个过程都按照计划进行？

方晓莹：并没有严格按照计划进行。计划中某些比较困难的部分花费了较多的时间，也有些较简单的部分花费了较少的时间。虽然实际进度对后面的计划有一定的打乱，但是后期团队也加快了自己的脚步和对接进度，最后基本完成了我们定下的计划。

 

资源

1. 我们有足够的资源来完成各项任务么？

方子茵：有大部分资源，团队部分成员有开发经验，有引导作用。时间较为充分。

2. 各项任务所需的时间和其他资源是如何估计的，精度如何？

方子茵：由有开发经验的队友给出建议并根据自身情况调整；较为粗糙，实际开发中有其他不可预知的问题。

3. 用户测试的时间，人力和软件/硬件资源是否足够？

方子茵：测试时间足够；团队6人，人力资源足够；硬件/软件方面也没有较大问题。

4. 你有没有感到你做的事情可以让别人来做（更有效率）？

方子茵：没有。

 

变更管理

1. 每个相关的员工都及时知道了变更的消息吗？

许嘉威：和项目有关的功能改动和对接过程中的BUG，我们采用了GITHUB团队的项目展板进行及时的记录和issue推送，同时在交流群里或私下及时告知任务负责人去执行这个任务。我们可以通过项目展板和issue上的消息和问题具体描述知道自己需要做什么，总体来说在整个项目过程中每个成员接收变更消息的速度良好。

2. 我们采用了什么办法决定“推迟”和“必须实现”的功能？

许嘉威：在项目中我们会提前决定好整个项目所需实现的功能，以及各组内决定实现的逻辑。对于不可抗力因素难以实现的功能，我们会决定从简到繁的方法，先实现简单的功能，再到逻辑复杂的功能，先实现整体框架，再到具体细节。其次，在功能的实现顺序上，会很大程度影响项目的完整性和用户体验的属于必须实现和优先实现的功能。

3. 项目的出口条件（Exit Criteria）是否得到清晰的定义？

许嘉威：我们项目的出口条件是：后端单元测试通过率100%，方法覆盖率100%，分支覆盖率90%以上，保证后端接口正常；前端页面交互顺畅，基本功能无异常，浏览器适配正常；整体项目功能完整，用户使用体验良好。

4. 员工是否能够有效地处理意料之外的工作请求？

许嘉威：在本次项目中的意料之外的工作请求就是一些前后端交互的BUG修复。成员都能及时高效的接收BUG反馈和及时处理部署。

 

设计/实现

1. 设计工作在什么时候，由谁来完成？是合适的时间，合适的人么？

舒雯钰：在第一周的时候，全体队员一起进行了项目功能的设计；在第二周后台开发人员进行了数据库的设计、  前端开发人员和后台开发人员进行了接口的设计，随后UI进行了原型设计；以上工作都是在合适的时间由合适的人完成的。

2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？

舒雯钰：起初，UI进行原型设计时参考的项目架构图与接口的设计有出入，经过询问后得知参考的不是同一个架  构图。讨论后决定参考同一个架构图，以接口的设计为主，对一些功能进行调整并体现在UI上。

3. 什么功能产生的Bug最多，为什么？

方晓莹：住户相关和人员管理的部分；因为功能相对其他页面来说较复杂和多样，bug出现的也十分多样。

4. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

方晓莹：没有严格执行代码复审，一是时间限制，二是团队里多半是第一次接触项目代码，不熟悉代码复审的环节和流程。初期严格执行了代码规范，但到后期出于时间的紧迫，没有很严格执行代码规范，但基本的代码规范是严格遵守的。

 

测试/发布

1. 团队有没有测试计划？为什么没有？

利国铭：我们有测试计划，而且因为有了计划，测试人员可以不用胡乱测试。

2. 有没有做过正式的验收测试？

利国铭：没有，因为时间赶所以只是将流程跑了一遍看看有无问题。

3. 团队是否有测试工具来帮助测试？

利国铭：没有，我们采用人工测试，通过不断运行代码来检查bug。

4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

利国铭：每天都在测试，如果添加一个新的功能就会立刻测试；有用，会及时发现存在的问题；测试的内容应该更加全面。

5. 在发布的过程中发现了哪些意外问题？

利国铭：在个别浏览器下会出现界面编排错乱。

6. 我们学到了什么？如果历史重来一遍，我们会做什么改进？

利国铭：通过运用软件工程的知识去将进行开发可以使得我们能更加高效地完成项目，敏捷开发的流程也对项目的完成有着不可或缺的作用；如果历史重来一遍，我们会将需求分析的更加透彻，找到用户迫切需要的，不可或缺的功能，在开发上亦先将所需知识深入学习，以便开发的顺利进行。

 

全组讨论

 

 

团队成员在Alpha阶段的角色和具体贡献

 

贡献分规则

本组共6人，所有人贡献分的总和为120分，每人持有基本参与分10+项目贡献分10。

1. 基本参与分中的10分是基础分数，不变动

2. 项目贡献分中的10分是在完成项目的过程中，队员们根据讨论情况、参与部分、完成程度等方面去给除自己外的队员评分（满分10分），届时根据评分再取平均分（若两人平均分相等，则队长决定两人分数±1）。

 

名字	角色	团队贡献分	可验证的贡献
方晓莹	Dev、Test	10+9.5 = 19.5	前端开发，对接测试
黄芯悦	Dev、Test	10+8.3 = 18.3	前端开发
舒雯钰	UI、Test	10+7.6 = 17.6	UI、集成测试
利国铭	PM、Test	10+6.6 = 16.6	PM、集成测试
许嘉威	Dev、Test	10+9.3 = 19.3	后端开发，对接测试
方子茵	Test	10+6 = 16	集成测试