《作业派》的项目回顾
Big boss
2016年6月23日星期四
设想和目标
1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件要解决的就是老师不能随时随地发布作业，学生老忘记作业，不能随时随地查看作业的问题；定义的很清楚；并且对典型用户和典型场景有清晰的描述。
2．是否有充足的时间来做计划？
我们有充足时间来做计划
3.团队在计划阶段是如何解决团队成员对于计划的不同意见的？
我们大家坐在一起，通过开团队会议的方式，来处理对计划的不同意见。
用户量、用户对重要功能的实现的接受度和我们事先的预想一致吗？我们离目标更近了吗？有什么经验教训？如果历史重来一遍，我们会有什么改进？
应该说和事先预想的不一致，因为我们的功能还做得不够完善，但是我们相信我们确实是离目标更近了，因为用户的一些反馈让我们明白自己需要做那些改进；经验就是多考虑一下用户的感受，如果在重来一下，我们会将界面做的更加美观和实用。
计划
1.你原计划的工作最后是否都做完了？如果没有做完的，为什么？
没有全部做完，因为有一些功能运用的技术比较复杂，不能在短时间内熟练掌握。
2.有没有发现你做了一些后来看来没有必要或没有多大价值的事？
有，因为刚开始对Android编程的知识一点都不会，所以就漫无目的查了好多资料，结果好多编程的时候都没用到。
3.是否每一项任务都有清楚定义和衡量的交付件？
不是所有的任务都有，因为开始的时候对Android的知识不太熟悉，有的任务并不能有清楚地定义。
4.是否项目的整个过程都按计划进行？
不是，因为在编程的过程经常会出现一些意想不到的错误，还有一些不会的知识点，这些都打乱了我们计划的正常执行。
5.在计划中有没有留下缓冲区，缓冲区有什么作用？（例如：缓冲区的定义，加班）
有，缓冲区就是如果没有正常完成计划，就晚上多写会代码，保证计划的正常进行。
6.将来的计划会做什么修改？
将来的计划就是多留一些时间给缓冲区，用于改bug和查不会的知识点。
我们学到了什么？如果历史重来一遍，我们会做什么改进？
我们学会了要合适的制定计划，如果在重来一遍，我们会制定更合适的团队计划，留出更多的缓冲区来保证计划正常实施。
资源
1.我们有足够的资源来完成各项任务吗？
我认为我们的资源并不充足，因为老师没有给我们相关的例子来供我们学习和借鉴。
2.各项任务所需时间和其他资源是如何估计的，精度如何？
所需时间和其他资源是我们开团队会议根据个人的能力来估计的，结果精度和实际情况
有很大区别。
3.测试时间、人力和软件/硬件资源是否足够？对于那些不要编程的资源（设计/文案）是否低估难度
测试时间、人力等这些远超出我们预料，而且低估了那些不需要编程的资源。
4.你有没有感到你做的事情可以让别人来做（更有效率）？
我们是根据个人能力来分配任务的，所以不会有这种感觉。
有什么经验教训？如果历史重来一遍，我们会做什么改进？
我们的经验教训就是要找到充足的资源，并且那些测试时间，不需要编程的资源的难度要做更加充分的预估
变更管理
1.每个相关的组员及时知道变更的消息吗？
我们有自己的qq群，保证每个组员都能驾驶知道消息的变更。
2．我们采用了什么办法决定“推迟”和“必须实现”的功能？
我们通过开团队会议，讨论哪些功能必须实现，哪些功能可以推迟。
3.项目的出口条件（Exit Criteria——什么叫“做好了”）有清楚的定义吗？
有，就是基本功能都实现，界面比较美观，没有bug，即使出现bug也在我们掌控范围内。
4.对于可能的变更计划是否能制定应急计划？
可以
5.员工是否能够有效地处理意料之外的工作请求？
我们团队是一个和谐的团队，对于意料之外的工作请求，都有效的去处理。
我们学到了什么？如果历史重来一遍，我们会做什么改进？
我们学到了对于消息的变更要及时通知我们的团队成员，如果可以的话，我们要制定合适的应急计划，并且留出一部分时间来处理可能的计划变更。
设计/实现
1.设计工作在什么时候，由谁来完成？是合适的时间，合适的人吗？
设计工作是在我们项目开始之前，大家开会讨论的。
2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有，我们都是开团队会议，然后认证研究讨论，最后决定。
3.团队是否运用单元测试（Unit Test）、测试驱动的开发（TDO）、UML或其他工具来辅助设计和实现？这些工具有效吗？
我们团队运用了相关的工具来帮助设计和实现，这些工具有一定的效果。
4.什么功能产生的bug最多，为什么？在发布之后发现了什么重要的Bug？为什么我们在设计/开发时没有想到这些情况？
在连接数据库的部分Bug最多，在我们发布之后，发现打开网页之后不能返回，这个
是因为我们对webview的知识不熟悉造成的。
5.代码复审（Code Review）是如何进行的，是否严格执行了代码的规范？
代码复审是我们坐在一起对我们的源代码进行复审，严格执行代码规范。
我们学到了什么？如果历史重来一遍我们会做什么改进？
我们知道在软件发布之前要做充分的单元测试和代码复审，如果历史重来，我们会将这两项做的更好
测试/发布
1.团队有没有测试计划？为什么没有？
有测试计划
2.有没有做过正式的验收测试？
有
3.团队是否有测试工具来帮助测试？
有测试工具
4.团队是如何商量并跟踪软件的效能的？从软件实际运行结果来看，这些测试工作有用吗？应该有哪些改进？
对于软件的效能，我们会通过团队回忆来商量，至于软件的效能，每开发出一个新的功能，我们都会进行相应的测试。
5.在发布过程中发现了哪些意外的问题？
没有发生什么意外的问题
我们学到了什么？如果历史在来一遍我们会做什么改进？
我们学会了如何进行软件测试，如果可以重来，我们会制定更加合适的测试计划。