事后分析（beta版）

设想与目标

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

   我们的软件是一个分布式并发服务器，解决的是使用服务器的问题。在分析说明中有清楚的定义。

2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?

   团队的目标基本达到了，原计划的功能全部达到，也按找原计划的交付时间进行交付。但是不算达到原计划的用户数量，因为基本没用户在使用。

3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么？有什么经验教训?

根据参与测试的人员，我们发现用户对重要功能的接受程度和我们事先的预想一致，也证明着我们离目标更近了。

计划

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

有，在整个开发过程中的时间分配较为合理；

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

对于团队中的不同意见，我们会进行集中讨论，根据讨论的结果选取最优的一两个意见；

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

原计划的工作几乎全部完成，

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

没有，开发的软件难度不大，一切都按照流程进行开发。

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

没有做到，有些小功能和函数的没有衡量交付件。

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

项目整个开发过程较为顺利，整个过程中没遇到较大的风险；算的上意外的是有些并发编程的学习较为困难，有些知识没有搞懂，对进度有些影响。

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

没有留下缓冲区。

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

计划基本完善，开发流程已经接近尾声，不会再有修改。

资源

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

项目是用C++语言来编程的，项目中的每个成员基本都有学习过C++，且对集成开发环境较为熟悉，所以资源算充足。

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

我们是将软件所需的要求划分成多个模块和函数，分配每个成员每天需要完成多少任务。

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

我们是将软件所需的要求划分成多个任务，每天都大致完成几个任务，精度是计算到每天。

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

·各项功能的测试时间充足，团队每个队员完成一个模块后，都会进行简单的功能测试，而且到最后会有总体测试提供。

·人力和软件/硬件资源充足，我们是七个人的小组，每个人都各司其职完成自己的模块，也会对别的队员提供自己的想法和帮助。

·我们的项目基本不需要美工设计。

·文案方面，通常是我们组长来进行任务分配，每个人完成一个部分然后写总结，组长再把每个人的总结进行整合。

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

·江周勉：我负责项目中的线程模块的开发，也学习了相关的知识，开发流程中也没遇到什么困难，但是可能交给更懂并发编程的组长来做可能效率比我更高.

·邱棋浩：作为组长，我在整个项目中承担着领导和协调的角色。虽然我也参与了其他模块的开发，但考虑到他在需求分析和项目管理方面的经验，将更复杂的任务分配给他可能会更加高效。

·宫旭：在项目中，我负责协程模块的设计。虽然我已经有相关经验和知识，但如果将这个任务交给更加专注于协程技术的人可能会更有效率。

·李伟东：我是负责整个服务器框架当中的io模块的，这个模块的核心实现步骤是在改写linux的epoll方法，整体实现的难度较大，在队长的帮助下也是顺利的完成.

·赵光明：作为协程调度模块的开发人员，我负责设计和实现高效的协程调度系统。由于我在过去的项目中负责了协程调度模块的设计和优化，我具备处理协程任务调度和协程切换的经验和能力。因此，将协程调度模块的任务交给赵光明能够保证高效完成。

·李昊旃：我在项目中负责设计和实现可靠的配置系统。由于我对配置模块有深入的理解和经验，因此他可以在规定的时间内完成设计工作，确保配置模块满足项目的各种需求。

·钟海超：我负责的是整个服务器框架中的日志模块的开发，因为我并不太熟悉日志功能开发，所以在开发过程中遇到了不少问题，花费了不少时间。因此，我觉得或许可以让其他人来做。

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

组员在每个模块的开发中都学习到了相应的知识，我们也都意识到了团队配合的重要性。如果重来一次，我们会重新分配模块任务，让每个人学到不同的知识。

变更管理

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

成员都在一个班级，见面较为容易，并且消息基本通过微信工作群传达，传达速度较快。

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

首先判断这个功能的重要性，重要级别高就优先，其次看它的实现难度，如果成员们都解决不了就暂时推迟。对于重要功能就肯定是要实现，附加的额外功能若实现不了就可以选择放弃。

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

对于我们来说，项目出口条件就是程序满足规定先前指定的要求，并且运行中没有遇到bug

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

没有，项目流程较短，没有安排应急计划。

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

我们每个人都实现了自己模块预计的功能，没有意料之外的工作请求。

设计/实现

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

设计工作	人员	哪几天	理由
日志模块	钟海超	1-2	各模块的设计和编程工作由自行选择决定，任务量都较为接近
配置模块	李昊旃	2-4
线程模块	江周勉	4-7
协程模块	宫旭	4-7
协程调度模块	赵光明	5-8
IO协程调度模块	李伟东	6-8
Hook模块	邱棋浩	5-8
测试	李伟东	8-9	细心有耐心，有过测试软件的经验
需求分析说明书	邱棋浩	9-10	作为组长，之前有过做需求分析的经验

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

对于项目中的命名空间是使用统一的还是根据灭个组员自己的习惯来命名，经过讨论后决定使用统一的命名空间进行命名。

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

团队没有单元测试，由于大家都对测试比较陌生，没有测试的经验，本次开发主要以实现代码为主。

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

各模块都出现过不少bug，因为小组成员都是第一次开发这类项目，难免会出现bug。

重要Bug：问题出现时，在测试日志模块的功能。make好之后，我在终端执行可执行文件，没有日志输出

原因：造成该问题的原因是没有对 LogAppender 的 m_level 成员进行初始化。

没有想到这些情况的原因是在开发过程的疏忽。

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

成员会在完成每天完成任务后对当个的代码进行检查。最后汇总大家的时候互相查看代码，看有没有自己审核时没发现的问题。

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

加深对项目的认识，学好基础知识十分重要。重来一遍会重视测试和代码复审。

测试/发布

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

我们对测试有一个粗略的计划，对各功能进行了测试。

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

我们还没进行正式的验收测试，只是我们自己测试过。

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

无

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

主要是成员自己的检查和测试以及组员间的相互测试。这些测试工作较为简单，作用一般。下次应该改进学会专业工具进行跟踪。

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

暂无发现。

名字	角色	团队贡献分	可验证贡献
邱棋浩	TEST	49.9	功能代码撰写，测试，博客，分配工作
钟海超	DEV	13.21	功能代码撰写，博客
江周勉	DEV	18.46	功能代码撰写，博客
李昊旃	DEV	13.41	功能代码撰写，博客
宫旭	DEV	13.52	功能代码撰写，博客
赵光明	DEV	13.1	功能代码撰写，博客
李伟东	TSET	18.37	功能代码撰写，博客