事后诸葛亮分析

事后诸葛亮分析

一、设想与目标

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

项目的目标是让大学生清楚认识到，提早进行理财会对现在及以后的生活培养出一个好的习惯，知道自己支出在什么地方，价值是多少。定义的清楚，对用户和典型场景有清晰的描述。

1.2、我们达到目标了么?

基本达成目标，按原计划时间交付。

1.3、用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?我们离目标更近了么?有什么经验教训? 如果历史重来一遍,我们会做什么改进?

没有上线，用户量暂时为0，我们在不断接近目标，有富于时间的话应该可以完全实现目标。

教训：相关用户界面不够优化，有提升空间，时间分配和人员分配不够合理，组员之间的沟通与配合应该更加密切，一开始设计过于潦草，导致bug太多太麻烦。

改进：制定时间安排表，积极分配任务，配合更加紧密。拒绝拖延症，尽早完成。

二、计划

2.1、是否有充足的时间来做计划?

有，在最开始做项目的时候就有了大概的计划，然后在项目进行中的时候不断及时的完善计划。

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

讨论，然后看人数，如果都犹豫不决的话就听从经理的。

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

大部分原计划工作都已经实现，因为时间原因和技术原因，一些功能可能难以实现

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

没有把，我暂时觉得做的事都还算有价值。

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

有。每一项任务例如编程，界面，优惠，测试都有清楚定义分配，都是确保质量的交互。

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

基本按照计划进行，没有出啥意外。风险就是可能会遇到死机的情况，因为电脑配置不够，又或者有组员因为一些私人问题没有参与进来导致临时更换人员负责而导致有点混乱和拖沓。

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

有，在周末设置缓冲区，有一定的作用，缓解组员压力，事半功倍。

2.8、我们学到了什么? 如果历史重来一遍,我们会做什么改进?

组员之间的交流不够密切，组员有时上交任务的时间过晚导致博客撰写时间紧迫，时间上也应该进行修改，因为后期临近考试月，所以应该早期完成更多的工作。人员分配存在问题，有些分配过多有些分配过少，需要及时交流以便及时增添删减人员

三、资源

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

没有，所以上不了线

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

任务所需时间根据目测难度估计的，精确到小时。

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

测试时间和人力和软件/硬件资源足够，美工设计有点低估了难度，预估的时间不够。

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

我做的事就是测试和撰写博客，我的事当然可以别人来做，但是他们或许做别的会更有效率，每个人的不同的能力和实力都不一样都有一个最适合的来匹配。

3.5、有什么经验教训? 如果历史重来一遍,我们会做什么改进?

教训：时间分配欠佳。计划后半段临近学期末，事务变多导致进展缓慢，发现bug后难以更改，队员提交任务较晚。队伍较欠缺沟通。

改进：每周必须制定并更新作业任务安排表，及时按时完成任，如果因个人原因需要换人要及时上报并且提前沟通。积极举办并参加会议，前后端和测试人员充分交流，遇到问题和大家一起解决。

四、变更管理

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

是，有变更信息我会第一时间通知相关队员。

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

需要变更的时候投票决定，投票不能解决的时候采取听从pm策略。

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

有清晰的定义，实现了基本功能，界面也算能用。

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

能，因为是大家一起表决所以表决完就可以实施计划。

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

能，可以大家一起完成。

五、设计/实现

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

设计工作是在选题确定之后，由全队来完成，是合适的时间和合适的人。

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

有，负责设计的同学在遇到这种情况之后可以上报，然后团队讨论之后取最优解。

5.3、团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

在每个模块开发完之后，都有用py和vs studio进行单元测试。其他工具并没有使用，UML没用进行更新状态没有区别。

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

界面bug最多，因为大家都对界面的学习相对欠缺，有想到这种情况，但是不太好解决。

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

代码复审我们是一起分工复审，这样更快速，保证了基本的代码规范。

5.6、如果历史重来一遍,我们会做什么改进?

改进：每周必须制定及更新作业任务安排表，及时按时完成任务，如果因为个人原因需要更换人员，需提前沟通并且重新分配任务；必须积极开会议，前后端和测试人员充分交流，及时解决问题，拒绝摸鱼，尽量让产品界面更加完善，能上线。

六、测试/发布

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

有相关测试计划

6.2、是否进行了正式的验收测试？

进行了正式的验收测试

6.3、团队是否有测试工具来帮助测试？

有，我们团队用了JMeter、IDEA、Burpsuite、AWS以及项目管理工具等来帮助测试。

6.4、团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

测量效能主要有软件是否正常运行，运行速度是否高效率，运行效果是否令人满意等，压力测试使用jmeter进行测试，从结果上来看是有效果的。改进的话就是提高服务器的效能，加快相应速度。

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

目前尚未上线，所以发现不了问题。

七、团队的角色，管理，合作

7.1、团队的每个角色是如何确定的，是不是人尽其才？

每个队员根据自己的擅长领域确定角色。必须人尽其才。

7.2、团队成员之间有互相帮助么？

团队成员虽然沟通较少，但一方有难5方支援，有难题发上群聊大家都会尽自己所能一起协助解决困难。

7.3、当出现项目管理、合作方面的问题时，团队成员如何解决问题？

通过队内交流讨论一起解决分歧问题，如果不能解决问题就由pm定夺。

八、总结

8.1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

达到CMMI中的三级。

8.2、你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

磨合阶段

8.3、你觉得团队在这个里程碑相比前一个里程碑有什么改进?

这是我们第一个里程碑。

8.4、你觉得目前最需要改进的一个方面是什么?

时间管理能力。

8.5、对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例

线下会议，组内分歧沟通，每日任务进度汇报。

8.6、代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？

每个成员遵守代码编写规范，要有必要注释，组员之间要有必要沟通。测试人员必须对每次提交代码进行审核。

8.7、整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？

架构如何提高：必须要有足够的知识储备，架构需要对整个项目都有比较深入的理解。

重构方法提高质量：在添加新功能时进行重构，在修改bug时进行重构，在代码复审时进行重构

质量提高：减少bug数量，减少完成时间

8.8、其它软件工具的应用，应该如何提高？

通过学习使用其它更加适配该项目的软件，提高效率。

8.9、项目管理有哪些具体的提高？

更加紧密的沟通，积极举行线下会议，采取每个人的意见撰写最为合适的项目管理。

8.10、项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？

通过对输入数据的每天的统计

8.11、项目文档的质量如何提高？

学习相关最适配软件

8.12、对于人的领导和管理， 有什么具体可以改进的地方？

我们对于人员分配较为模糊，可以更加具体一点，这样效率就能更加的高。

九、会议照片及角色贡献

9.1、会议照片

9.2、角色贡献

名字	角色	团队贡献分
陈嘉喜	算法开发	20
宋鲲宝	PM	20
李伟辰	测试	20
黄聪	后端开发	20
谢晓岚	后端开发	20
张洪	前端开发	20