团队作业10——事后诸葛亮分析

事后诸葛亮分析

---

总结的提纲内容，请参照课本15章内容或邹欣老师的博客：

a. 项目管理之事后诸葛亮会议

http://www.cnblogs.com/xinz/archive/2011/11/20/2256310.html

设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
    我们要解决的问题是一个能够导入课程表的个人学习计划提醒系统。在之前的需求规格说明书有队典型用户和典型场景有清晰的描述。
2. 我们达到目标了么（原计划的功能做到了几个？  按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
    目标大体上是达到了，原计划的功能少了用户自我评价的那一块。
3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么?我们离目标更近了么?
    用户包括班级成员以及周围宿舍的同学，接受程度和预期差不多，虽然有些功能在实现上不够好，但是经过努力一步步做出来的产品，让我们离目标更加接近。

- 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
    觉得主要的问题就是时间的问题，大三的课程本身就比较多，一定要将可利用的时间充分利用起来。

计划
1. 是否有充足的时间来做计划?  
    时间不是非常充足，且大家都不太知道如何更好地利用时间来做计划。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
    主要通过会议解决，毕竟隔壁宿舍，有问题面对面交流，加上队长大人发言一般不同的声音很快就会变成统一意见的。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
    是有没做完的，一是时间问题，二是考虑欠缺。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
    有！！大部分的团队成员对于这一点答案还是相当统一的。但是做了也没什么坏处，把纠结做这件事有没有意义的时间还不如就做了呢。
5. 是否每一项任务都有清楚定义和衡量的交付件?
    只能说是模糊的。说清楚好像有点太自信的感觉。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
    几乎是按照计划进行的，在队长的有效领导下，进行的也蛮顺利的。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
    有，因为团队成员的能力还是有差距的，进度就不太一样，所以还是需要缓冲区的。
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
    更加明确缓冲区的长度。
 
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
    计划还是得根据个人能力定制，缓冲区还是要有的，要适当考虑可能的风险因素，要做好风险应对策略。
 
资源
1. 我们有足够的资源来完成各项任务么?
    我们做的是web开发，所以资源不是什么大问题。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
    估计的时间和实际的时间相差还是比较大的，进度差比较大，精度小。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度? 
    还是处于简单的测试阶段，各方面的资源还是足够的。不算低估难度。况且对美工方面，每个成员都会提一点小小的建议。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
    如果都给会的人做肯定会更有效率，但是分工合作一起查资料，可以帮助基础不好的人提升项目代码编写的能力，也不失为另一种意义上的有效率。

- 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
    对于资源方面，主要还是人员的分配方面，适当的人做适当的事。

变更管理
1. 每个相关的员工都及时知道了变更的消息?
    那是肯定的，除了qq群之外，隔壁宿舍这个优秀的条件，有啥消息在适当的时间敲敲门面对面聊一聊就都知道了。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
    一是看用户的需求哪些是必须的，哪些是用户没有考虑而我们自己想做的；二是看项目要求的基础功能，基础功能要是没了还说什么进阶功能呢；三就是看自身的能力啦，如果有余力，功能越完善越好，主要是看时间的长短。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
    我们的出口条件是能够对每日任务进行操作，能够导入课程表，能够对每日任务进行评价，且可以进行用户邮箱提醒。没有明显的bug，能够正常运行基本的功能。
4. 对于可能的变更是否能制定应急计划?
    并没有，所以遇到紧急事件只能熬夜补救。
5. 员工是否能够有效地处理意料之外的工作请求？
    我们工作外的请求就是别的学业啦，由于其他课的作业也比较多，有时候真的会面临时间不够的情况。但是大家还是两边抓紧，都没有落下。
 
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
    变更管理的消息要及时散发给各个成员，务必让大家及时接收到消息，对于可能的变更，要有预备的紧急应对策略。

设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
    原型设计是项目的开头，由翁珊和谢晓萍完成，合适的时间，由于她们也是前端代码编写的人员，也是合适的人员。（在beta阶段，前端人员变更成黄建英和谢晓萍）
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
    有。比如说有考虑过做网页的字体格式，后来在实现的时候，也没时间，也觉得不是非常的必要，大家综合考虑就决定放弃了。
3. 团队是否运用单元测试（unittest），测试驱动的开发（TDD）、UML,或者其他工具来帮助设计和实现？这些工具有效么？
    尚未运用。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug?为什么我们在设计/开发的时候没有想到这些情况?
    数据库交互功能产生的bug最多，数据库的数据无法在HTML页面中展示并困惑了许久，花费了大量时间进行了修整。因为低估了Python语言和MySQL的相适应性。（换句话说，用Python和MySQL搭配有点坑，应该转用SQLite）
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
    不算严格执行。
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
    提前把MySQL的程序模块写好。

测试/发布
1. 团队是否有一个测试计划？为什么没有？
    有。
2. 是否进行了正式的验收测试？
    暂时还没有，只是各成员自己对自己负责的模块进行很初步的测试。
3. 团队是否有测试工具来帮助测试？
    coverage插件进行测试。
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
    使用了多种浏览器进行测试，并无太多问题，同时在邮箱验证过程中采用了多种SMTP供应商的服务来进行测试，比如，Sina，Gmail，Tencent，Yahoo等，来确保邮件服务的稳定性。
5. 在发布的过程中发现了哪些意外问题？
    服务器部署出现意外。 

- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
    提前学习服务器部署知识。Apache+Mysql+PHP的部署比Python Flask+MYSQL要容易的多。

团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
    结合自身的能力，再通过自荐，权衡进行确定的。算是人尽其才了。
2. 团队成员之间有互相帮助么？ 
    当然有，帮助是相当相当的大。如果没有成员之间互相的帮助，肯定是没有现在的成果的。
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
    通过会议，大家提出意见看法，一起讨论最后的解决方案。

成员博客：
    详见下方团队成员的角色表格。
    
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
    每个角色要用适合的人选担任，成员之间要互相帮助，大家互相帮助，共同进步。
 

总结:

你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
    二级，管理级。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
    目前我们的团队已经完成了beta阶段的冲刺，冲刺阶段中的分工合作进行的有条理，可以算是正在磨合走向规范的阶段。（因为过程中也遇到大大小小的问题，所以还是达不到规范）
你觉得团队在这个里程碑相比前一个里程碑有什么改进? 
    1.成员都有了一定的或多或少的经验；
    2.成员的感情一步步变得更加紧密，合作起来更加的顺利。
你觉得目前最需要改进的一个方面是什么?
    加强访问页面的稳定性，做好一些小bug的完善。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。  
    1.业务人员和开发人员在项目开发过程中应该每天共同工作。--虽然没有共同工作，但是做到群内讨论。
    2.以有进取心的人为项目核心，充分支持信任他们。--组员相互信任，尤其信任组长。
    3.时时总结如何提高团队效率，并付诸行动。

b. 全组讨论的照片

团队成员在Alpha阶段的角色和具体贡献：

名字	角色	团队贡献分	可验证的贡献
黄建英	前端	19	前端页面代码编写
谢晓萍	前端	20.5	前端页面代码编写
黄月梅	后端	19.5	后端功能代码编写
徐晓珊	数据库	20	数据库设计
庞伊凡	后端	21.5	后端功能代码编写
赵娅汀	测试	19.5	最后的测试功能