个人总结
一、 总结自己的alpha 过程
1.团队的整体情况
整体团队工作完成度较好，但是有一些工作因为会个人的粗心而导致团队分数不能拿到这是比较可惜的一点。在前期的产品需求分析模块做得不错，团队成员都有用心去做事，都能把自己该做的，分配到的任务都尽力完成。这点十分不错，但是到了后期团队开发阶段，由于分配任务可能有点不科学导致一些队员心态比较轻松，没有尽心尽力的做好博客这一块。APP开发存在最后一道障碍没有完成所以并不能算完成得很好，团队协作能力还有待加强。
2.我做了哪些工作
我完成了前期产品需求说明书，以及后期APP的开发，部分团队博客。
3.我是否完成了pm分配的任务
完成PM分配的全部任务
4.不足的地方
在后期开发中，有一段时间是在学习java的安卓开发，所以不能连续开发，拖延了团队的时间，最后有某些功能因为个人能力问题没能写出来。
5.对团队的建议
希望大家能对自己要完成的部分更加用心点。能把团队交给自己的事情做好。
二、提出问题（软件工程）
问题1：
例子：在编辑产品功能说明书时遇到了无法流畅的编写用户的典型场景，并且觉得这个条目对游戏APP来说并不是很友好。
我看了10.3.2功能说明书的模板，其中在写关于产品功能说明书中有要求是写用户的典型场景。就我们的APP而言，我们写的是关于手机游戏APP，这个APP很难说有“需求”这种东西，所以在写产品功能说明书时只能强行带入，感觉并不能体现出真正的用户需求。作为一款小游戏更应该是有哪些功能，能给用户提供哪些功能，而不是说用户需要哪些功能。我的困惑是，是否能够对某些软件产品可以不做软件功能书的用户和典型场景。
问题2：
例子：在团队其他成员测试时，要么是有参与开发编程的成员的白箱测试，要么就是没有参与开发的同学进行黑箱测试，不存在灰箱测试。
13.1.1按测试设计的方法分类，可分为黑箱和白箱，其中，黑箱指的是在设计测试的过程中，把软件系统当做一个“黑箱”，无法了解或使用系统的内部结构及知识。一个更准确的说法是行为测试设计，即从软件的行为，而不是内部结构出发来设计测试。白箱指的是测试过程中可以看到软件系统的内部结构，并使用软件的内部结构和知识点来选择测试数据和具体测试方法。在开发过程中，更多时候开发者使用的还是白箱，其他组员采用的更多是黑箱。我的困惑是所谓的灰箱是不是也是基于黑箱。
问题3：
例子：在团队进行测试时，是否真正需要其他成员的测试。
在13.2.4 验收测试中，测试团队拿到一个“可测”的构建后，就会按照测试计划，测试各自负责的模块和功能，着个过程可能会产生10来个甚至100个以上的bug，那么如何才能有效地测试软件，同时在这一阶段怎样衡量构建的质量？在开发阶段，我们团队的开发人员就会进行功能的开发测试，比如每个按键是否能够达到预期功能，并且会进一步跟进，把不能做好的功能进一步的做好。我在思考的是，是否需要另外的测试人员来进行测试。
问题4：
例子：在产品测试结束后有没有能力完成的功能
修复BUG需要修改程序，而每一行程序的修改都会更改程序逻辑，那么就一定存在修复了新的BUG，而旧的已经修复的BUG又重新出现的可能。所以，每次新版本的产品发布之前，进行回归测试是不可避免的程序。我们要思考的方向应该转换为如何提高修复的效率，为了达到这一目的，应该使软件的构建符合一定的代码规范，同时，必要的文档是必不可少的。只有尽可能做到每个模块的功能单一化，才能做到BUG的局部化，这样才能提高查错、修改的效率。对于团队该完成的我们都有尽力去做，但是真的做不出来的功能要如何处理呢？
问题5：
例子：软件开发的质量如何
软件开发的工作量和质量怎么衡量?PSP认为有下列四个因素：a.项目/任务有多大？b.花了多少时间？c.质量如何？d.是否按时交付？如果到最后因为某些功能未能实现是不是就算做这个软件开发的质量极差？
自我评价表
|
1-8 |
D |
D |
B |
B |
C |
C |
C |
C |
|
9-16 |
A |
A |
B |
B |
B |
C |
C |
B |
|
17-24 |
B |
B |
C |
D |
D |
C |
B |
B |
|
25-32 |
B |
C |
C |
B |
B |
D |
B |
C |
|
33-40 |
B |
D |
B |
D |
C |
|
|
|