商品效率预测及分析系统
设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
• 我们软件主要解决对于商品效率的一个总结分析以及预测出该种商品在一段时间内可能的销售量，这两个大的模块本身所传递的信息就很清楚，但未对典型用户和典型场景进行清晰描述。
2. 是否有充足的时间来做计划?
• 有时间，但是项目所涉及的内容对于我们来说都是新内容，所以不能保证计划的合理性。
3. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
• 通过每周的会议进行讨论，最终在各个方面进行取舍得出最后结果。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
• 需求的分析决定了项目的实现走向，如果再来一遍会将功能方面的分析做得更加详细，主要是从拓展角度来看，因为我们项目本身的需求比较明显。
计划
1. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
• 原计划的功能点基本做完，但是在实现效果上没有完全达到原来的预想。
2. 有没有发现你做了一些事后看来没必要或没多大价值的事?
• 有，在web实现方面，之前都是自己设计的，但是由于缺少设计细胞，做不出好看的界面，在搞了一个多星期之后用来模板。
3. 是否每一项任务都有清楚定义和衡量的交付件?
• 没有，很多时候都是实现了一个功能之后觉得不好，换个方式，尤其是之前做web时未定下模板，没有说好每个地方该怎么做，基本就是有个想法就和另一个人说一下，无形中增加了很多没必要的工作量。
4. 是否项目的整个过程都按照计划进行?
• 基本上，但是app实现中出现了一点小问题，导致后面进程比较赶。
5. 在计划中有没有留下缓冲区，缓冲区有作用么?
• 有缓冲区，本来计划是功能与界面实现之后对接查看bug，但是由于功能测试的需要，提前对接所以就混在一起了。
6. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
• 优化是一个很重要的点，加班也是很必要的。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
• 按照计划进行会使整个实现过程更加轻松。如果再来一次，会督促大家按计划来实现功能，并且需要制定切实可行的计划。
资源
1. 我们有足够的资源来完成各项任务么?
• 有后台数据，但是每个人都没技术。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
• 开始精度很粗略，后来发现原来的实现方法不好或者是被否决了，需要重新开始，就没管时间精度了，加班就对了。
3. 用户测试的时间，人力和软件/硬件资源是否足够?
• 便进行功能实现时就进行测试了
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
• 每个人在项目中用到的知识基本都是现学的，所以感觉替换过来没什么显著区别。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
• 主要还是没技术，一切都是从零开始。如果以现在学到的知识再重新做一遍，可能对整个项目实现的过程会比现在更清楚。
变更管理
1. 每个相关的员工都及时知道了变更的消息?
• 每周的会议，qq消息，或者直接宿舍通知（都住在一栋的）。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
• 之前定义的功能都需要实现，至于推迟就是当实现当前在做的功能之后再实现推迟功能。
3. 项目的出口条件（Exit Criteria）是否得到清晰的定义?
• 大家都不太懂“出口条件”是什么，好像也没用到。
4. 对于可能的变更是否能制定应急计划?
• 基本没有，哪个部分差不多要做完就顶上。
5. 员工是否能够有效地处理意料之外的工作请求？
• 没出现什么意料之外的工作，解决几个大的变动就是增加加班时间。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
• 所有精力都放到如何实现功能上面，再来一次会考虑得更加全面
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
• app界面设计是在需求分析阶段全组讨论得出的，web'界面是后面实现过程中矛盾较多才决定由负责人讨论决定，时间较晚，应该在开始实现web之前就决定。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
• 主要由负责部分人商量决定，因为我们项目需要实现app与web，两者联系不大。对于web部分就由我与另一个组员讨论决定。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
• 运用了单元测试的员工，没有用单元测试的员工。
4. 什么功能产生的Bug最多，为什么？
• 在web中最大的bug就是功能与界面的衔接，每次调用一个功能就会出现页面跳转，后续会解决。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
• 注释方面还是比较好的，因为我每次都会整理web文件，但是其他的如命名规范，函数换行等方面就比较粗糙。
测试/发布
1. 团队是否有一个测试计划？为什么没有？
• 我们无测试计划，首先是人员分配时未考虑到该部分，另外没有多余人手来做单独的测试人员，所以直接由实现功能的人员来进行测试
2. 是否进行了正式的验收测试？
• 都是在实现功能的同时进行测试。
3. 团队是否有测试工具来帮助测试？
• 无。
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
• 无。
5. 在发布的过程中发现了哪些意外问题？
• 未发布
团队的角色，管理，合作
1、团队的每个角色是如何确定的，是不是人尽其才？
• 首先是先听取每个人的想法，再进行分配，最后如果两个人同意互换位置，可以自行进行调整，最后决定之后不可随意更换。
2、团队成员之间有互相帮助么？
• 有，比如前台与后台之间紧密相连，互相帮助也必不可少
3、当出现项目管理、合作方面的问题时，团队成员如何解决问题？
• 首先是负责部分的人员商量解决，然后就是组间开会协商
每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：
我感谢 ____梁沛______对我的帮助， 因为某个具体的事情: ___在web界面设计上的付出（虽然最后被老师否决了）_________。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
• 如果再来一次，我会直接用模板而不是自己设计，早日做完再去帮助其他部分。
总结:
1、你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
• CMMI初期
2、你觉得团队目前处于 阶段的哪一个阶段?• 磨合后期，主要是有些功能还未融入过来
3、你觉得团队在这个里程碑相比前一个里程碑有什么改进?• 首先是每个人所学的的东西变多了，在各自部分的进展会加快很多，当需要修改一个功能或是添加一个功能时效率变快了。
4、你觉得目前最需要改进的一个方面是什么?• 前期有些散懒，后期加班到底，对身体不好