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)，咱们有了一些经验，也制定了一些标准，可是还不够成熟。

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

创造阶段。你们的目的都是让产品作得更好，全部人都在主动为项目贡献本身的力量，无需监督。同时为实现功能实现的技术成员也会进行自学。

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

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

你以为目前最须要改进的一个方面是什么?

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

对照敏捷开发的原则, 你以为大家小组作得最好的是哪几个原则? 请列出具体的事例。

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

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

散伙前合影：