宇宙最帅XX--事后诸葛亮分析

Posted 2021-01-19 wzf5156

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

名字	角色	团队贡献分	可验证的贡献
郭旭	服务端	95	软件设计、代码编写、测试
夏翔	服务端	90	代码编写
王锴	用户界面	90	用户界面设计、代码编写
邵伟源	用户界面	91	用户界面设计、代码编写
韦智锋	客户端	88	代码编写
何卓仟	客户端	85	代码编写

 

一、设想和目标

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

我们的软件是用来解决我们在日常生活中被各种杂七杂八的聊天软件频繁干扰的问题。所以我们的聊天软件的定义就是一款纯聊天的聊天软件，不会被各种没必要的、或者说是看似很有必要实际上却又不是非要不可的信息所打扰，这个定义的方向是十分明确的。而且对于典型用户和典型长场景是有比较清晰的描述，用户会用什么各种字符来作为用户名和密码，我们在用户说明中明确提出我们对于用户名和密码中字符的一些限制，那些字符不能够使用等。

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

在开始做这个项目的时候，我们时间还是比较充裕的，我们每个队员都是能抽出时间来开个会做计划。

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

队员之间比较和睦，不同的意见由大佬们决定，而大佬们意见往往比较一致。

4.用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

用户量、用户兑重要功能的接收程度和我们事先预想的十分一致，虽然我们离目标还是比较远。

 

二、计划

1.是否有充足的时间来做计划?

前期的时间比较充裕，在第五周和第六周计划时，由于接连两门考试需要备考所以使得我们在最后两周的计划时间被严重压缩。

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

大家意见相对统一，但是也会出现分歧，主要是看谁的方案实现难度小，以及对项目后续发展，项目的扩展性有利。

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

没有，未完成的部分包括聊天功能的具体对接还存在一些问题，以及之前想要实现的文件、图片传输和离线聊天部分功能。

具体原因是考试影响了一部分计划的执行；但主要是我们前期对这个项目的代码量和实现难度估计不足。

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

没有

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

较少，大多数时间都是写到哪看到哪。

6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

没有，由于考试影响到了我们的进度流程，并且一部分功能模块交付较晚，拖慢了整体进度。这两个问题都没有事先预计到，中间考试时间突然调整加剧了情况恶化，功能模块交付的问题，主要是由于实现难度偏大并且学习成本较大。

7. 在计划中有没有留下缓冲区，缓冲区有作用么?

没有，本身考试压缩了我们的开发周期。缓冲区能减少成员的心理压力，给出足够的休息时间，提高成员的开发热情

8.将来的计划会做什么修改？（例如：缓冲区的定义，加班）

增设缓冲区，增设进度监管的角色。

 

三、资源

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

有足够的学习资源来应付这次开发。

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

没有严格的计算时间。

3.测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

低估了项目的实现难度，导致后期没有足够的时间来进行完整的测试。

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

基本没有，因为虽然我们成员的代码能力有强有弱，但对于开发我们经验和水平基本在同一起跑线上，所以没有多大区别。

 

四、变更管理

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

可能有短时间的延迟，上传到github后我们并不会立刻关注到，有时候发生变更后变更者会遗漏通知其它成员

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

基于‘实现难度是否过大’和‘功能是否在软件运行流程不可或缺’的原则决定是否实现和可否推迟。

3.项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

我们的出口条件是基本完成登录，注册功能，和基础聊天功能，并完成功能对接并且没有易被发现的bug。

4.对于可能的变更是否能制定应急计划?

可以

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

可以

 

五、设计/实现

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

设计实现实在做了需求分析之后的，是由我们队员们共同完成的，那从我们的角度来说是合适的时间，也是合适的人。

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

没有。

3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

否。不了解。

4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

报的发送和接收中产生的bug最多，因为聊天实际上就是各种包的传输。没有。

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

一个个功能块进行复审。基本上都执行了代码规范。

 

六、测试/发布

1. 团队是否有一个测试计划？为什么没有？

有计划。相应的测试在初步进行得比较顺利，但是因为各小组的进度不同步，但是在后来测试进行得比较困难。

2. 是否进行了正式的验收测试？

有。

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

否。

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

团队没有测试并跟踪软件的效能。

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

服务器的效率并没有我们想象中那么高，消息的延迟比较严重。