Beta阶段事后分析

1. 设想和目标

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

我们在Beta阶段任务主要分为两部分，一类是对原功能的扩展，一类是新的博文功能。我们通过规格说明书定义功能，至少比Alpha阶段清楚多了。典型用户和典型场景还是沿用的Alpha阶段。

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

基本达到了目标。但是计划实现的功能太多了，最终只实现了大多数功能，一些非核心功能就被弃掉了。我们在展示的前两周发布，并且达到了预计的访问量（原计划600，现在达到了802），只是注册量还差一点（原计划300，现在达到了244），不过这个结果已经远远优于Alpha阶段了。

1.3 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？

提高了。主要体现在文档更为明确了，我们会根据数据库文档和规格说明文档进行功能定义，不必在开发过程中去纠结应该做什么，开发功能的速度明显优于Alpha阶段。而且我们的分工更佳明确，两名后端一人负责一大块，减少了沟通的花费，效率确实上升了。而且我们优化了贡献分分配的公式，更佳简洁明了，弱化了PM主观因素。

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

Alpha阶段结束的时候访问量为220，现在已经突破了800，我认为用户量还算达到了目标。不过在发布后又出现了很多问题，比如有些资源提示404（是课程中心的问题），还有同袍认证存在问题，以及用户上传的资源丢失等等，这些问题都是我们之前从未预料过的。但是也有用户反馈说获取到了很难获取的资源，这一点我们也很欣慰。实际上，我们在Beta阶段新增了很多诸如课程收藏、资源评价等等提高用户体验的功能，但是现在还没有得到用户的反馈。

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

尽早宣传，由于我们宣传得比较晚，导致最终的用户量和汇报时用户量相差比较大。应该把反馈功能尽早衔接到网站上，而不是依赖于用户群。

2. 计划

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

有的，实际上在Alpha阶段发布之后就已经开始考虑Beta阶段的功能了。

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

在讨论的时候PM主张先对原有功能进行扩展，而组员们的大致意见是先实现博文功能，以更快速地得到反馈。这一点PM最终还是听从了组员们的建议。

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

没有做完。因为我们Beta阶段少了一名前端开发，同时可支配的时间比Alpha阶段要少（因为各种大作业和考试，尤其是编译占得时间很多），导致时间一直很紧张。

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

有的。主要是后端开发了很多功能最终由于前端比较紧张没能衔接上。早知道这样真应该减少一些功能，提高软件工程的质量。

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

只要按照说明文档那样实现就可以交付了。前端的话会事先商量，并对原型图进行适当改动。但是感觉定义得不是很清楚。

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

基本按照计划进行，最后阶段有些脱节，主要是没有想到那一阵子这么忙……

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

没有设立缓冲区。

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

减少任务量，并明确各个任务的优先级。

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

精简要实现的任务，设立优先级，根据优先级依次实现任务，这样就算有突发情况导致任务没做完也能保证最核心的部分都实现。

3.资源

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

并没有，我们少了一名前端开发，Beta阶段我们用来做软工的时间也少了很多、

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

首先我们有了Alpha阶段的开发经验，我们会把要实现的功能和Alpha阶段已经实现的功能进行对比，比较一下难度，因为Alpha阶段任务的实现时间是已经确定的，所以可以以此估计任务所需的时间。

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

我们有专门的测试人员，而且后端实现的功能也会简单进行测试，这部分资源是足够的。我们这里没有单独的美工设计和文案人员，后期的宣传大家都做了一定工作。

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

没有，我们分工都很明确了，是可以让别人来做，可是别人也有自己的工作啊。

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

我们一定要在Beta阶段开始前尽可能拉人。

4. 变更管理

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

是的，重大的决定我们会在会议上宣布，如果没有开会的条件也会在群里争取大家的意见。至少我们会让和变更密切相关的成员第一时间了解到变更。

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

先大约估计了一下各个功能实现的成本，先实现时间确定、成本较低的功能，也考虑了功能的重要性，但没有将这一点放在主要位置。主要还是时间太紧了，担心最后的结局是一个重要的功能没实现完，其它功能也没时间实现了。

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

后端有接口说明文档，前端有原型设计图，如果有临时变更也会事先打好招呼，感觉定义得还算清晰。

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

我们大概知道接下来要做什么，但是计划还不是很详细和明确。

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

如果没有分配太多任务的话，还是可以有效处理的。这也和其他学科的压力相关。

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

主要学到的是应变能力。Beta阶段我们的变更不算太多，主要体现在Beta阶段刚开始的计划上，但一旦确定了大体的方向，后面变更得就很少。

5. 设计/实现

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

大部分设计工作都在Beta开始前以及第一周开头这一部分，主要由PM负责，是合适的时间和合适的人。但也有少部分设计是在开发过程中进行的。

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

当时首页的原型设计太难实现了，后来就大致想做得简单点，却没有额外画新的原型设计，对于前端确实是个模棱两可的情况。我们有过交流，我们交流了彼此的思路，最终效果挺满意的。

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

我们主要是依靠说明文档，定义了输入和输出格式，测试的时候只是自己编写测试样例去测试。

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

博文功能Bug最多，这里主要是前端，一是人手不足，二是bug不太好解决，本身实现难度也比较大。在发布之后我们发现搜索的结果有小概率会出现不全的情况，因为我们的编码不涉及搜索逻辑的部分，所以就没太在意，再加上这个问题出现概率较低，而且出现了也很难注意到。

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

感觉并没有严格按照代码规范，一些遗留的不符合规范的变量名并没有及时做修正。

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

我们在这一阶段太过注重功能的实现了，时间又紧，人力资源又少，一直处于一个很紧张的状态。如果重来一遍我们会放弃一部分功能，将更多的时间用在代码管理上，保证软件工程的质量。

6. 测试/发布

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

测试计划不是很详细，主要是前端和后端都忙着开发，测试工作基本全部由测试人员独自完成。

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

有，除了功能测试之外，还进行了压力测试，优化之后又测试了几次。

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

功能测试使用java版本的selenium，负载测试采用jmeter和badboy实现。

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

我们一开始保证正确性的模拟的最大用户量是30+，这个结果已经很差了。之后我们为进程分配了更多的资源，将用户量稳定在100出头。最终PM和后端又针对性能的瓶颈（课程贡献分计算）做了优化，最终大幅度降低了访问时间，能够承受住140+用户的连续访问。

感觉应当提高测试的频率，降低测试的时间，降低测试的成本。有时候后端需要确定优化的效果，需要依靠测试来确定性能瓶颈有没有被解决。感觉应当每名成员都掌握部分测试能力，这样不必完全依赖于测试人员，自己打个招呼就可以随时测试。

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

过去的文件消失了，怀疑是被误删了，好在都是开发人员上传的文件，不涉及用户上传的文件。

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

Alpha阶段中性能瓶颈不明显，没有感受到优化的重要性。如果重来一遍，我们会在开发过程中就注意尽量使用花销较小的实现方式，比如遍历数组尽量不通过下标访问等等，这些细节可以提高一部分性能。

7. 团队的角色，管理，合作

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

和Alpha阶段一样的分工，同学们经过了Alpha阶段的提高，对自己的本职工作也很了解了。

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

经常互相帮助，有不懂的问题就跟群里问一问。

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

及时沟通，线上说不清楚就私下说，大家住的都比较近，基本所有的问题都能通过沟通解决。

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

理解了沟通的重要性，以及如何明确地将任务分配给个人。

总结:

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

可重复级(Repeatable)，我们有了一些经验，也制定了一些标准，但是还不够成熟。

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

创造阶段。大家的目的都是让产品做得更好，所有人都在主动为项目贡献自己的力量，无需监督。同时为实现功能实现的技术成员也会进行自学。

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

从口头分配任务到文档分配任务，功能的实现有据可依，成员分工明确，交集更少，降低无用沟通。

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

代码质量，开发过程太过仓促了，重视了功能，忽略了代码的管理，导致代码缺少结构性。

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

围绕被激励起来的人个来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作：我们在分配任务的时候充分信任组员的能力，相信他们能够完成任务

在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈：我们遇到困难的时候经常私下见面，线下交流的效率远高于线上。

散伙前合影：