4. Beta阶段总结分析报告

4.1 事后诸葛亮会议：

4.1.1设想和目标

1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
解决大众博客很难满足个性化需求问题，当前博客网站不够个性化，相似的界面和复杂的操作促使我们设计开发出一个符合审美，有个性化功能的博客。

典型用户：

• 本系统的拥有者（博主）
• 普通游客
• 已认证游客

典型用户场景：

1）博主小周

姓名	小周
性别	男
职业	武汉大学研究生在读
知识层次和能力	研究生，有一定计算机知识储备
动机、目的、困难	动机、目的：记录碎片知识和心情，在项目中提高编程能力，搭建一个符合自己审美和功能的个性化专业博客
用户偏好	扁平化设计风格，个性化功能
用户比例	相当于占50%
典型场景	登录博客，编辑博文选择相应的tag发布；在搜索框输入关键字搜索；修改或删除曾经的博文，也可修改博客风格以及相应功能；可以增加、删除、查看、修改代办事项和ToDoList分类，随时查看校内网通知。
典型描述	我用我喜欢

?

2）普通游客小李

?姓名	小李
?性别	男
?职业	学生
?知识层次和能力	大学，从小使用使用电脑
?动机、目的、困难	动机、目的：浏览网页，发现好玩的新鲜事，学习他人的知识。困难：网上无用的知识太多，不容易找到好资源
?用户偏好	有风格、有深度的干货
?用户比例	50%
?典型场景	这个博客真棒，我喜欢

?

3）认证用户小王

????姓名	小王
????性别	男
????职业	武汉大学研究生在读
????知识层次和能力	有一定的计算机知识储备
????动机、目的、困难	动机、目的：在网上寻找有意思的内容，能够随时随地看到最新资讯
????用户偏好	功能齐全，操作简洁，资讯丰富
????用户比例	占20%
????典型场景	认证前浏览相关博文，留言；认证后查看武大官网最新资讯
????典型描述	比普通游客多一个特权，有意思

?

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

在alpha版本和beta版本中，我们在每个冲刺周期之前都会召开冲刺会议，并且绘制甘特图，在会议上进行任务认领。同时，用燃尽图的方式进行项目管理，并且使组员了解每一个开发节点。alpha阶段我们已经制定了详细的计划并且顺利施行。在beta版本中，我们先对alpha版本的功能缺陷进行修改，然后加上需要修改的内容后做了准备和调整，这种方法促使我们提前将系统完成，并且帮助我们省了很多的事情。

Alpha版本计划：

Beta版本计划：

3.团队在计划阶段是如何解决同事们对于计划的不同意见的？
如果有团队成员有不同意见，我们会首先在讨论组里面进行交流，一般来说这种方式可以解决80%的问题，如果无法解决当前的问题，会在每日会议里面进行讨论，实际模拟问题的解决方式，最后达到一致意见。

4.用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
由于本项目的特性，其中一个（一类）用户是针对博主，由于我们alpha版本就是针对这个用户，所以实现了几乎所有重要功能。同时alpha版本针对普通游客的功能也和预想一致。对于beta版本的认证用户，已基本实现了功能。

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

按照原计划工作已经完成。

6.有没有发现你做了一些事后看来没必要或没多大价值的事?
由于时间紧，任务重，所以我们做的每一件事情都是经过认真讨论确定下来的，基本没有浪费时间做无用的事情，当然，也没有别的时间来供我们浪费。

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

在《规格说明文档》中，定义了系统功能描述验收标准，对于每一个检验点，都有相应的输出规定，我们开发的过程也是这样衡量任务是否完成的。

4.1.2 计划

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

在alpha和beta版本迭代过程中，都进行了部分分工的调整。虽然没有出什么意外，但是之前的工作分配产生的问题其实带来了风险。

这种状况确实没有估计到，因为我们一直以为，计划好每一个版本的工作，认领好每一个工作，就可以完成好每一个工作。但是在计划过程中，并不能在计划的同时就评估这个计划是“好”的，其实计划并不那么好，而且需要根据实际情况随时调整。所以我觉得这是没有估计到，也不可能被估计到的情况。好在这些都没有印象到项目进度，但是以后会注意这样的情况。

2.将来的计划会做什么修改？
暂时没有什么需要修改的，如果在使用过程中有bug，会及时修改更新。

如果博主有新的需求，会在未来进行添加和修改。

4.1.3 资源

1.我们有足够的资源来完成各项任务么?
虽然项目计划很紧凑，压力也比较大，但是基本上可以协调资源来完成任务。

2.测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
beta版本的测试相比较alpha阶段完善了很多，除了功能测试，还进行了性能测试。

我们团队的PM作为不需要编程的资源，将设计、文案设计的还可以，没有低估其资源的难度。

4.1.4 设计/实现

1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
PM领导团队共同决定，在整个项目开发之前完成了《规格说明文档》，也包括了原型设计和数据库设计，所以比较合适，所有小组成员都参与了。

2.我们学到了什么?
这一次开发经历最主要的就是学会了团队配合下的整个开发过程并实际应用了一遍，在此过程中我们不断磨合提高在完成项目的同时也快速提高了个人能力。

3.团队是否有一个测试计划？
我们在每个版本的项目计划中，包括了测试计划。虽然时间很紧，但是我们一般在冲刺周期的最后一至两天进行集中测试。

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

我们使用siege进行压力测试

选择对用户正常访问过程中经常访问到的文章列表、文章内容，进行了三种测试：

• 短时间平均时间访问
• 短时间高并发访问
• 长时间平均时间访问

具体测试结果见：http://www.cnblogs.com/mia0502/p/7787913.html

4.1.5 总结

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

目前团队已经顺利度过了磨合期，我认为已经达到了规范阶段。

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

小组成员提升自身的水平进而提升效率。

3.我们小组什么地方做的比较好？

我们组的配合程度还是比较不错的，合作起来非常的顺利，并且善于沟通总结，在遇到问题的时候能够积极地询问其他组员的意见共同解决。

4.下个阶段需要改进什么？

没有下个阶段了，期待大家后续的合作

4.1.5 全组照片

4.2 团队成员在Beta阶段的角色和具体贡献

姓名	角色	团队贡献分	可验证的贡献
周明浩	Dev+Test	19	实现功能接口，压力测试
黄金筱	PM+Test	18	完成文档，功能测试
王枫	Dev+Test	22	实现部分功能
刘烨	Dev+Test	21	完成部分功能，功能测试

?

cs