团队作业10——事后分析（Beta版本）

 目录  

一、设想与目标

二、计划

三、资源

四、变更管理

五、设计与实现

六、测试与发布

七、总结

八、图片和贡献分分配

 

一、设想和目标

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

我们的软件要解决的问题是用户能够正常使用四则运算app，app可以出题，判断对错，显示结果，录入错题库的问题，同时在beta阶段加入注册登陆功能，设置简单版和复杂版。定义得也比较清楚，包括出题，判断对错，显示结果，录入错题库。

用户主要针对学生，老师，家长，场景主要是练习四则运算，做题。

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

时间上面还是不够充分，因为后期碰到了一些问题，一切都没有想象的那么顺利。

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

小组通过微信，qq和电话等通讯工具一起协商讨论来解决意见冲突。

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

用户量并没有达到预期，但是就有使用过的用户来说，功能（重要）是符合他们的要求的。离我们最初的梦想还是有一些距离的。

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

Beta阶段我们由于模拟器和设备等问题，等于把所有的内容全部重做了一遍。这样时间就会显得很不充分。如果可以重来我们会制定更细的任务清单，以使任务可以圆满完成。

二、计划

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

原计划的大部分工作基本在最后都完成了，还存在一个问题是注册登陆与主体功能不能融合的问题。

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

李志强（开发）：修复没法完成，早该换个思路。

申悦（开发）：环境没了解清楚，就开始着手写代码。

魏辉（PM）： 没有。

林方言（测试）：简单的测试用了太多的时间。

刘存（开发）：纠结于一些细节，然而主要功能还没实现。

徐璨（测试）：太在意界面。

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

是的。

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

整个项目做下来并没有完全按计划稳步进行。会出现一些问题，比如项目在注册登陆功能和主体功能链接的时候出现问题，后面用了非常多的时间去解决，也没有全部解决。是有估计到过程会遇到问题，但是时间成本还是不够，最后导致没有很好的解决。

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

有留两天的缓冲期，主要是为了解决突发问题和后期完善功能。

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

后期希望可以能再把团队聚集起来，一起完善一下功能和界面。

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

过程中会遇到很多的困难，解决的过程可能会比较艰辛，但是也收获了很多的解决问题的思路。如果历史重来一遍，一定会把每天的工作在做细化。



三、资源

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

技术方面通过学习我们组已经具备，小组换了pm后气象一新，整个环节的任务分布很合理。主要是时间不太够。这学期课程压力比较大。

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

时间资源方面这个阶段我们是计划到每天的每个时间段。整体来说还是OK的。


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

a.测试时间：时间还好，且做且测试是我们的原则，整体来说还是够的。
b.人力资源：人力资源方面还是够的，小组齐心协力。
c.软件/硬件资源：电脑配置有些低（毕竟大多三年前买的）内存不够运行模拟器。尴尬！
d.不需要编辑的资源：确实最开始低估了它们的难度，界面基本没做优化。

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

李志强（开发）：有些功能点的设计可能有些同学比我做得更快更好。

申悦（开发）： 因为自己对写代码挺感兴趣，并且相较我们其他组员来说，我有较多的编程经验，也有过项目经验。所以认为自己的任务并不需要分配给别人。

魏辉（PM）： 没有吧，相对来说我最适合做PM的角色。

林方言（测试）：有，自己不太认真。

刘存（开发）：有些美工方面可能女生来评价更好。

徐璨（测试）：自己很适合分配到的任务。

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

如果历史重来，我们会再细化分工。

四、变更管理

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

我们每天会定时召开站立式会议，队员大部分时间基本都在一起，有什么变动相互之间都知道，还通过我们的QQ群公告来通知变更消息。这个和beta阶段基本没差。


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

通过小组开会讨论的方式，最后由组长做出决策。


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

所有功能都能够实现，且做过测试后就“做好了”

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

有的，设置了缓冲期。

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

基本都能，组员积极性都是挺高的。

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

团结，主动，这是我们学到的。如果可以重来，我们会更加细化分工安排，同时更加严格的完成布置的任务，精确到各个点。

五、设计/实现

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

设计工作在开始冲刺前便完成了。由pm和主要码农，是合适的时间，合适的人。

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

讨论，一切以用户为中心。而后作出决定。

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

有运用单元测试，基本都是每个人测试自己的模块，在遇到实在不懂得问题，大家一起讨论，在测试结果符合后再合并到一起。测试过程没有采用工具，基本是手工测试，遇到问题就修改。最终完成后会具体再做测试。

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

测试和登陆最多，因为不熟悉怎么去做，所以经常碰到问题。注册登陆无法与主功能链接在一起。这个我们本来以为很好解决的，没想到最后，却，，

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

两个同学互相监督查看，有严格执行。

6.我们学到了什么? 

具体工作中：要贯彻落实代码规范，合理规划时间和安排分工，项目经理及时督促，团队之间多沟通，共同解决团员遇到的问题。

六、测试/发布

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

有的。

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

有的。

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

没有。主要还是用手机直接测试。

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

手动调试来跟踪软件的效能；测试工作有用。

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

在发布的过程中我们发现的最大的意外问题是注册登陆无法完美衔接。

七、总结

beta阶段后

我觉得我们的团队目前的状态依旧是已管理级。原因如下：

1. 在beta冲刺之前，我们团队有针对我们的项目（四则运算App）做过需求分析以及项目计划

2. 在beta冲刺阶段，我们小组每天会开站立会议和视频会议分析问题，并汇报自己的完成进度和完成情况。

3. 在beta冲刺后，团队就可以说是有了类似项目（安卓）的开发经验，一定程度上可重复类似项目（简单的）的软件开发工作。

4. 我们小组是有专门的测试人员的，通过测试可以保证app的质量和可用性。

我觉得我们团队还处于磨合阶段。理由如下：

1. 在beta冲刺之前，我们团队每个人都没有项目开发的经验，虽然每个人都有一定的JAVA语言基础，但是并不懂安卓

2. 在beta冲刺阶段，我们组采用根据每个人在Android学习的进展程度来分配任务，具体的分配上学的快的承担更多复杂的工作，学的慢的承担稍简单的工作，同时多负责一些文档的构建工作。

3. 在beta冲刺之后，增长的能力不多。

分工更合理，有更好的管理机制。

八、图片和贡献分分配
a. 博客要附上全组讨论的照片：

b.团队成员在Alpha阶段的角色和具体贡献：

1. 图表

名字	角色	团队贡献分	可验证的贡献
李志强	Dev	21.5	主要代码撰写
申悦	Dev	21	部分代码，博客
魏辉	PM	20.7	部分代码，分配工作，博客
徐璨	Dev	19.5	部分代码，博客
刘存	Test	19	测试，博客
林方言	Test	18.3	测试，博客

   2.说明：根据冲刺前的相关规定和安排  http://www.cnblogs.com/newteam6/p/6869558.html

 

 

感谢所有老师们，助教们的辛勤付出。谢谢！一学期很多，却收获很多，只言片语或许说不出太多的东西。惟愿您们工作顺利，万事如意。

附件：

CMM/CMMI将软件过程的成熟度分为5个等级,以下是5个等级的基本特征：
1． 初始级
软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。管理是反应式的。 

2． 已管理级
建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。 

3． 已定义级
已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。 目前，公司需要申请的就是已定义级别，通常称为CMMI3。由此，我们可知CMMI3是CMMI其中的一个等级。

4． 量化管理级
分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能。 

5． 优化管理级
可集中精力改进过程，采用新技术、新方法。拥有防止出现缺陷、识别薄弱环节以及加以改进的手段。可取得过程有效性的统计数据，并可据进行分析，从而得出最佳方法。 每个等级都被分解为过程域，特殊目标和特殊实践，通用目标、通用实践和共同特性。