项目：随堂小测
开发人员：李井明，李静，李琼，李泽宇
目录：
一、 设想和目标
二、 计划
三、 资源
四、 变更管理
五、 设计/实现
六、 测试/发布
七、 最终总结
---------------------------------------------------------------------------------------------------------------------------------
一、 设想和目标
1、 我们的软件要解决老师上课难以随时进行测试的问题
典型用户：老师与学生
典型场景：课堂
总结：定义方面还是蛮清楚地
2、 是否有充足的时间来做计划?
我们是从第6周周四-第8周周四一共2个礼拜的时间，用来做计划，当时安排了界面、功能以及分工
a现在回顾一下，对于当时的计划只能说是很粗糙，只涉及到了有哪些基本功能，并没有进一步思考如何实现以及如何进行对接，还有更细节的功能实现，比如服务器如何如何，哪个更好用哪个，该怎么连上去，如何更好地满足用户的体验。
b做计划阶段并不积极，所以当时写的计划考虑的因素太少了
3、 团队在计划阶段是如何解决同事们对于计划的不同意见的？
这个做的还不错，讨论积极讨论，欣然接受。
4、 用户量，用户对重要功能的接受和我们事先的预想一致吗？我们离目标更近了吗?
并不一致，且大大的不一致，之前想的还是很美好的。但是到了最后我们界面的设计，以及更重要的功能做的很少。别说是用户了自己体验感都极差。虽然对于这个APP能做出来我们还是感觉蛮有成就感的，但是理想与现实往往差距很大。
如果历史重来，我们会把最终目标放小一些，起码是一个只是先让自己用起来很舒服的境地，然后再把最终目标拆成一个个阶段性的小目标，大概4-5个的样子，比如从最终目标满意度分为20%，40%，60%，80%，100%五个程度，然后我们再考虑每个阶段的任务，计划，要实现的功能，以及实现方法，用什么去实现。
我觉得这样的话，在设想和目标阶段能让我们对要做的东西有一个基本的大局观，就想打篮球要有节奏，玩红警晓得多少分钟要把建筑建到什么程度。
二、 计划
1、 你原计划的工作是否最后都做完了？ 如果有没做完的，为什么？
并没有，且很多。例如原本计划了一个点名的功能，运用蓝牙，但是后来负责这个模块的人在具体执行的时候，因为这个功能想要实现太复杂了，所以最终我们放弃了，而换了一个仅仅是输入数字的点名功能。例如原本有一个讨论的专属界面，但是后来简化到在问题下进行评论，且画面巨丑，仿佛是上个世纪的产物。虽然这个功能实现了，但是用户体验感极差…..等等。
最后的成品和我们计划是设想的成品差距太大了。一方面是能力的问题，我们确实火候欠佳，对一个全新的东西设想的太美好。另一方面也是没有对这个项目投入很大的精力，各位都有事情且都在做，然而头疼的是，maybe没有一件做的很好吧。
2、 有没有发现你做了一些事后看来没必要或没多大价值的事？
有，很多，比如说之前计划了一个收发文件的功能，最后虽说是能做了，但是在文件的查询方面简直是要了老命了，所以干脆就没有去做查询方法，而这个功能在最终成品的功能里就是个鸡肋。
3、 是否每一项任务都有清楚定义和衡量的交付件？
没有，并没有硬性要求，只是力所能及就好
4、 是否项目的整个过程都按照计划进行？
并没有，平时不练，临周四加班加点的时候常有，而且因为很急所以做的很粗糙
5、 在计划中有没有留下缓冲区，缓冲区有作用么？
没有，一开始的定位就是能实现功能就好
6、将来的计划会做什么修改？（例如：缓冲区的定义，加班）
将来的计划我觉得不一定要非常非常详细，但是一定要面面俱到。包括有哪些功能模块，如何实现，用什么接口，功能对接如何进行，日常代码的练习如何进行（毕竟Android Studio对我们来说是一个全新的东西），功能的实现会出现哪些问题，用户的体验，如果自己来用，我会用的很舒服吗，界面怎么样，查询是不是很方便很快捷…
计划不应该草草了事，应该是一个面面俱到但同时又短小精悍的计划书。
三、 资源
- 我们有足够的资源来完成各项任务么？
没有，白手起家。像是无头苍蝇一样，遇见不会的就从网上查，而且要找很久
人的话，4个，勉勉强强
- 各项任务所需的时间和其他资源是如何估计的，精度如何？
没估计过，做到哪儿算哪儿
- 测试的时间，人力和软件/硬件资源是否足够？ 对于那些不需要编程的资源 (美工设计/文案)是否低估难度？
测试的时间还是很够的，毕竟所涉及的功能很少
真的是低估，我们做的巨丑…
4. 你有没有感到你做的事情可以让别人来做（更有效率）？
对于Android都是新手，没有谁擅长什么，所以可以相互替代。效率的话，只要做就有
如果再来一次的话，资源方面真的还不是最大的让人头痛的问题，问题是玩的不溜啊啊（哭唧唧）美工的话，应该分出来一个人专门去做美工的设计。
四、 变更管理
- 每个相关的员工都及时知道了变更的消息？
是的，当有任务没有来的及完成的时候，我们会相互帮忙，一起完成
- 我们采用了什么办法决定“推迟”和“必须实现”的功能？
从计划的最基本的功能向上数，离的越远越可以推迟
- 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么？
功能模块：功能可以实现且对接好了，就叫这个功能做好了
项目完成测试就可以了说做好了
- 对于可能的变更是否能制定应急计划？
并没有
5. 员工是否能够有效地处理意料之外的工作请求？
相互帮忙嘛
这个变更对于我们来说并不在必须考虑的范围之内，但是它不得不去考虑，所以如果能充来，我们会提前做好准备，以及应急的方案
五、 设计/实现
1、设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
在一开始的两周，一起完成
2、设计工作有没有碰到模棱两可的情况，团队是如何解决的？
没有，因为是奔着实现功能去的，选择时选最方便的，例如服务器的选择，当时是免费的了
3、团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML，或者其他工具来
帮助设计和实现？这些工具有效么？
有用UML，做了流程图和功能图
4、什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug？ 为什么我们在设计/开发的时候没有想到这些情况？
界面跳转时最多，如果连续点击的话就会闪退
设计/开发是并没有想这么多，只想着能实现功能就好
5、代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
代码复审是在自己测试之后，找到不合理的地方回去修改代码的
我们的设计/实现阶段是以实现功能为目的的，当然这并不好。
如果重来一次的话一定要去好好地执行任务
六、 测试/发布
1、 团队是否有一个测试计划？为什么没有？
并没有，都是实现了功能之后直接进行测试的也就是模块测试，然后把模块综合起来之后，就进行了次总测试。因为功能不多啊（捂脸/）
2、 是否进行了正式的验收测试？
否，非正式的倒不少
3、 团队是否有测试工具来帮助测试？
各自的手机就可以测试了，测试界面，功能，以及用户体验
4、 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
收集用户的评价和意见，做好总结。
还未改进，就到这里吧，吸收这个项目过程中的不足，在以后的项目中进步
5、在发布的过程中发现了哪些意外问题？
安装包无法打开，重新下载一次就好了
我们的测试阶段基本上都是做完之后自己做的测试，当然也有让同学，学弟们使用后进行反馈，在听取意见之后，总结到失误里面去。
总结：我觉得对于做软件，应该摆正心态，把自己当成一个正儿八经的开发者&企业家，从用户的角度出发，去思考设计的方向，以用户的体验为导向，踏踏实实做好一款“产品”。
注意是把它当做一个“产品”去做而不是作业。所以路还很长，这只是第一次尝试做东西，以后还会更多，加油吧！
