Beta阶段项目总结
Beta阶段项目总结
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件是组队APP，要解决的是用户不方便找志同道合的队友的问题，定义很清楚，就是提供给用户一个组队，来寻找队友的平台。我们的典型用户就是想要参加活动的人，典型场景就是不知道怎么找队友。
2．是否有充足的时间来做计划？
时间较为充足，基本满足项目的需求
3.团队在计划阶段是如何解决团队成员对于计划的不同意见的？
我们对每个人的意见列在一张纸上，然后共同讨论每项意见是否可行，然后投票决定去掉哪一项意见。
2.用户量、用户对重要功能的实现的接受度和我们事先的预想一致吗？我们离目标更近了吗？有什么经验教训？如果历史重来一遍，我们会有什么改进？
用户对功能基本满意，只是觉得有点单调，功能稍微简单，没有太多的功能，用户量没有完美预想的那么多，但是还可以，基本满足。
我们离目标又近了一步，软件发布可以使用了。
经验教训：要重视用户的体验，首先界面要做的美观一些，与用户的交互很重要。
改进：将界面做的更加美观，增加与用户交互的弹出式对话框。
3.计划
1.你原计划的工作最后是否都做完了？如果没有做完的，为什么？
基本完成，有一小部分没有实现，原因是要求的技术太高，我们的水平很低，达不到开发实现的要求。
2.有没有发现你做了一些后来看来没有必要或没有多大价值的事？
有，发现有一些代码重复编写，本来可以进行封装的，导致浪费了时间而且代码非常的冗余。还有查找资料，学习什么的好多东西都不是主要的，跟开发这款APP没有关系。
3.是否每一项任务都有清楚定义和衡量的交付件？
没有，我们只是制定一非常初步的计划，交付件参考同类APP的设计结果，我们自己的交付件并没有进行全面的定义
4.是否项目的整个过程都按计划进行？
没有按照计划进行，因为开始预想比较乐观，但是实际开发起来却发现并没有那么简单，出现的问题很多，需要再次查询资料才能解决，有的功能太复杂只能放弃。
5.在计划中有没有留下缓冲区，缓冲区有什么作用？（例如：缓冲区的定义，加班）
有，虽然每次冲刺是10天，但是我们小组成员都清楚10天不会完成的太好，还需要加时间完成，并进行软件的测试和推广。
6.将来的计划会做什么修改？
增加学习的时间安排，对时间的估计不要太乐观。要慢慢来。
4.我们学到了什么？如果历史重来一遍，我们会做什么改进？
我们会将用户体验放在首位，要将界面设计得美观一些，而且要详细地估算时间，不能盲目地觉得差不多就可以，要提前将相关知识点进行学习。
5.资源
1.我们有足够的资源来完成各项任务吗？
学习资源足够，图片资源不好找，需要长时间地在网上查找符合自己意愿的图片
2.各项任务所需时间和其他资源是如何估计的，精度如何？
各项任务与其他资源估计的时间方法较为一致，只是任务的精度较高，其他资源精度较低
3.测试时间、人力和软件/硬件资源是否足够？对于那些不要编程的资源（设计/文案）是否低估难度
测试时间不太足够，在测试时经常发现bug，需要大量的时间来修改，然后再重新测试。
对不要编程的资源低估了难度，到真正做的时候发现无从下手
4.你有没有感到你做的事情可以让别人来做（更有效率）？
没有，我们团队任务分配较为明确，暂时还没有发现让别人来做更好
6.有什么经验教训？如果历史重来一遍，我们会做什么改进？
要重视界面的美化，要提前学习相关的知识，要详细估算所耗费的时间。
7.变更管理
1.每个相关的组员及时知道变更的消息吗？
及时知道，我们在小组QQ群中即时更新项目情况，每个人都能及时收到消息。
2．我们采用了什么办法决定“推迟”和“必须实现”的功能？
我们通过团队会议，分析现在所耗费的时间来变通地决定是否需要推迟某一项功能点，分析现在最重要的功能点是什么。大家一起讨论决定。
3.项目的出口条件（Exit Criteria——什么叫“做好了”）有清楚的定义吗？
有，基本功能都能实现，按照正常流程不会出现问题，允许一定量的小bug的出现。但是不能影响正常使用。
4.对于可能的变更计划是否能制定应急计划？
可以
5.员工是否能够有效地处理意料之外的工作请求？
能够有效处理。
8.我们学到了什么？如果历史重来一遍，我们会做什么改进？
我们会加强团队成员之间的联系，对于每个人的想法要及时地进行分享，团队成员共同决定是否采纳。
9.设计/实现
1.设计工作在什么时候，由谁来完成？是合适的时间，合适的人吗？
设计工作在项目开发之前，由团队成员共同开会讨论决定，是合适的时间、合适的人
2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有，小组成员提出了想法，但是陈述不明确，或者其他成员也提出类似的想法， 但是最终并没有明确采纳哪一项，解决方法是再次进行讨论，确定出明确的意见。
3.团队是否运用单元测试（Unit Test）、测试驱动的开发（TDO）、UML或其他工具来辅助设计和实现？这些工具有效吗？
有使用一定的工具，但是很少，有一定的效果。
4.什么功能产生的bug最多，为什么？在发布之后发现了什么重要的Bug？为什么我们在设计/开发时没有想到这些情况？
在活动列表活动刷新功能产生的bug最多，因为监听总是不准确，发布之后发现点发布按钮没有反应，日期选择结果不一致。
因为我们在开发的时候忽略了一些细节的检查，导致出现了问题。
5.代码复审（Code Review）是如何进行的，是否严格执行了代码的规范？
我们共同将整个项目过一遍，然后每个人提出代码编写的意见，基本执行了代码的规范。
10.我们学到了什么？如果历史重来一遍我们会做什么改进？
我们将重点开发界面，尽量开发出一款界面美观的软件
11.测试/发布
1.团队有没有测试计划？为什么没有？
有测试计划，在软件基本开发完成之后进行测试
2.有没有做过正式的验收测试？
有
3.团队是否有测试工具来帮助测试？
有，发布到360应用商店，会给我们的APP进行测试
4.团队是如何商量并跟踪软件的效能的？从软件实际运行结果来看，这些测试工作有用吗？应该有哪些改进？
我们在基本功能开发完成之后都会进行大量的测试，来发现软件的问题，测试软件的效能。测试工作非常有用，能够发现软件在编码时发现不了的问题，应该增加测试的时间。
5.在发布过程中发现了哪些意外的问题？
发布完成后又发现了很多bug，需要重新提交
12.我们学到了什么？如果历史在来一遍我们会做什么改进？
我们在发布之前要尽量做好大量的测试，要找到其中的bug，并解决。然后再进行发布，以免需要重新发布，会浪费掉很多时间。
