团队作业6(B)-事后诸葛亮分析

白给团队e-shop项目Postmortem结果

（整理：政B）

设想和目标

1.我们的软件要解决什么问题？是否定义得很清楚？

　　答：主要是为商户和消费者提供一个网上交易商品的平台，定义明确。

2.我们达到目标了么？

　　答：成功按期完成目标，原计划的功能基本实验，交付的时间与预期计划一致。

3.和上一个阶段相比，团队软件工程的质量提高了么？

　　答：与上一个阶段相比，团队软件工程的质量大大提高。特别是在团队合作方面，团队成员进行头脑风暴，讨论出解决问题的方法，然后每个团队成员分工合作，各自负责完成自己的任务，为团队软件工程作出贡献。

4.用户量,用户对重要功能的接受程度和我们事先的预想一致么?有什么经验教训?如果历史重来一遍,我们会做什么改进?

　　答：由于软件未进行线上发布，所以暂时未得到用户量。不过，通过个人与团队测试，从用户的角度出发，用户对重要功能的接受程度与我们事先预想的一致，基本上能满足大众用户对网上购物的需求。如果历史重演，我们会对网上购物这个需求进行详细调查，找出用户在现代网上购物的不便之处，避免在软件工程中出现。

计划

1.是否有充足的时间来做计划?

　　答：充足的时间是有的，就是在计划方面出现了一些纰漏，导致后期工作量过多。

2.团队在计划阶段是如何解决同事们对于计划的不同意见的？

　　答：当团队成员出现意见分歧的时候，我们会采用投票的方式来解决。

3.你原计划的工作是否最后都做完了?

　　答：原计划中的工作都已经完成，除了还没有出现的BUG。

4.有没有发现你做了一些事后看来没必要或没多大价值的事?

　　答：在确定工程项目的时候花费了相对多的时间，不过这也是挺有价值的，至少能够在思考过问题以后再选择题目。

5.是否每一项任务都有清楚定义和衡量的交付件?

　　答：任务定义都不是特别清楚，都是通过模块来进行分配任务，而不是通过实现某个具体功能来定义任务。

6.是否项目的整个过程都按照计划进行，项目出了什么意外？

　　答：项目的整个过程都是按计划进行的，没有出现意外。

7.在计划中有没有留下缓冲区，缓冲区有作用么?

　　答：计划中并没有留下缓冲区，所以导致后期工作量加大，缓冲区的作用是用来防止出现特殊情况需要加长工程时间所设立的。

8.将来的计划会做什么修改？

　　答：将来的计划会对软件进行优化改进，使工程更加完善。

资源

1.我们有足够的资源来完成各项任务么?

　　答：资源来说是足够的，因为这个工程的难度不大，网上的资源已经足够完成任务。

2.各项任务所需的时间和其他资源是如何估计的，精度如何?

　　答：各项任务的时间都是以最大时间来估计的，通过时间界限来约束并完成任务，任务的精度不够仔细，都是粗略地以模块来进行划分，这个是以后需要改进的。

3.测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度? 

　　答：硬件和软件资源是足够的，但是人力与时间受到学科作业的影响，可能时间不太够，这是以后我们需要进行调节的。对于美工设计方面，由于此次团队项目并没有大规模地应用美工，只是粗略地设计界面，所以还没有认识到美工方面的难度。

4.你有没有感到你做的事情可以让别人来做（更有效率）?有什么经验教训?如果历史重来一遍,我们会做什么改进?

　　答：A：个人认为如果复审阶段能多个人一起进行复审将会更好，因为不同的人有不同的看法，集思广益才是最好的评价。

变更管理

1.每个相关的员工都及时知道了变更的消息?

　　答：每个相关成员都能及时了解自身的任务和代码的变更

2.我们采用了什么办法决定“推迟”和“必须实现”的功能?

　　答：我们根据功能的重要性和实现难度来决定“推迟”和“必须实现”的功能，重要性越高的将会归入“必须实现”，如果功能实现难度并且重要性不高的情况下我们将会归入“推迟”。

3.项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

　　答：项目的出口条件：①实现该项目应有的必须的功能 ②没有明显的BUG ③用户体验感受较高

4.对于可能的变更是否能制定应急计划?

　　答：虽然项目进行时并没有需要制定应急计划的时候，但是我们相信，当出现变更时我们能够制定应急计划。

5.员工是否能够有效地处理意料之外的工作请求？

　　答：能够有效地处理，因为我们都愿意为这个项目付出自己的努力，做到“有求必应”。

设计/实现

1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

　　答：设计工作在决定项目主题时，由全队成员讨论决定完成的。这是一个合适的时间，也是合适的人，毕竟大家都要参与项目的开发。

2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？

　　答：在数据库表的设计上出现模棱两可的情况，对属性的定义不够明确，最后选择现实生活中已经存在的软件进行参照。

3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

　　答：团队多数使用都是开发工具，都是在开发的情况下进行测试，并没有使用专门的工具进行测试，所以上述工具将会在下一次开发时进行使用。

4.什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

　　答：暂时没有发现存在的BUG（发现的已经修复），在开发和设计时并没有发现BUG的存在，这是因为在这两个阶段还没有对软件进行运行测试。

5.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？ 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

　　答：代码复审，首先是检查代码规范化，其次检查代码是否能够化简（在不改变功能的情况）。如果重来一遍，将会更注重代码的规范化，让代码更加清晰，使后面的测试和寻找BUG工作更加简易。

测试/发布

1.团队是否有一个测试计划？为什么没有？

　　答：团队有测试计划，只是计划并不够正式和完善。

2.是否进行了正式的验收测试？

　　答：并没有进行正式的验收，只是简单地模拟了一下用户体验进行测试。

3.团队是否有测试工具来帮助测试？

　　答：没有使用测试工具来进行测试，这是以后应该学习的。 

4.在发布的过程中发现了哪些意外问题？我们学到了什么?如果重来一遍,我们会做什么改进?

　　答：由于考虑到软件的可用性与实际性，并没有将软件进行线上发布，目前和处于线下使用测试阶段。如果重来一次，我们会重新选一个题材进行开发，考虑其实用性，这样才能在现实生活中使用。

总结

1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

　　答：团队目前的状态处于CMMI二级档次。

2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

　　答：我觉得团队目前处于磨合阶段，磨合度还不高，需要更长的时间来进行合作。

3.你觉得团队在这个里程碑相比前一个里程碑有什么改进? 

　　答：里程碑就是从个人项目转变成团队项目，了解团队项目的流程与步骤。

4.你觉得目前最需要改进的一个方面是什么?

　　答：我们觉得最需要改进的一个方面就是任务的分配，我们应当将每个人的任务具体化，具体到每一个细致功能。

5.对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则?

　　答：至于敏捷开发的原则，我们小组做得最好的是能够做到尽早并持续的交付有价值的软件成品，以满足用户的需求。

全组讨论的照片：

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

名字	角色	团队贡献分	可验证的贡献
卢耀恒	Dev、Test	23	队长+负责多数以及关键代码编写+课堂演讲
莫政	Test、PM	22	队长+博客编写+计划任务安排+代码+课堂演讲
高嘉淳	Dev	18	代码编写
覃泽泰	Dev	17	代码编写
梁小燕	Dev	19	代码编写
许梓莹	Dev、Test	21	前端大多数代码编写和交互