事后诸葛亮分析

一.设想和目标

1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

      我们的软件主要是提供一个零售销售平台，方便商家，顾客双方对买卖进行管理。在某些模块功能方面定义缺乏实践性。同时猜想与现实所存在的各种情况差异较大，在某些方面缺乏一定程度的清楚。

2. 我们达到目标了么（原计划的功能做到了几个？  按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)

      我们的目标大体达成了，对于功能较为复杂的实际交易场景因难以实现，所以在一些交易方面的功能模块无法实现。同样，由于用户数量没有达到预期效果。

3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？

     工程质量提高了，首先是从代码规范上越趋于有序易懂，从每个开发人员都有各自编码特色从而导致其他队员无法很好地理解代码 ，到现在可以阅读起来障碍不大。再者，在完成工程效率上也越来越高了。提高的具体数值没有进行认真地测试，但经历整个流程，可确实认为效率提高了。

 

二.计划

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

  这个分阶段，工程的前半时期，我们拥有着充足的时间来计划，后半时期，因学习任务的加重，导致缺乏时间来讨论计划。

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

根据少数服从多少，实际完成难易程度来作为评判标准。

3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

没有全部完成，考试等因素干扰，进项目预估进度误差等、

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

  基本上都符合，首先是任务不多，同时任务也不难，还有，对于事先所设定的文件定义，会根据开发过程进行修改。

5. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

    没有，现实生活中的事情过多，学院所分配的学习任务是最主要的干扰项。

同时，队员各自也有事情需要忙和发展各方面。当初在时间计划方面太理想化了，导致后面的一系列事情。

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

没有

7，我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

 首先是对软件开发的流程有更多的了解，队员间的合作与配合，在代码方面的功力，如代码规范，算法设计，接口配合等以及很多方面，我们每个人都有着不同程度的收获。关于改进，在时间安排，与任务分配，以及人员安排等方面需要很多的调整。

 

三.资源

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

没有，这个项目本是基于交易的，但缺乏一定的实物以及相关的资源，导致没有具体实现，只能模拟。

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

 与队员进行讨论估计取平均值。精度很差，失真较大。现实的事情太多了。计划赶不上变化。

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

我们在测试方面缺乏相应的技术水平，首先从人员方面，人员缺少，未能很好地测试出潜在的错误bug。

4. 你有没有感到你做的事情可以让别人来做（更有效率）?

有，若有人员来帮忙，或是有经验的人来指导，效率更大。

5，有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

在这个阶段我们学到很多东西，在团队方面学会合作互相帮助，在项目上面，学会如何测试，如何美工，如何编程。如果历史重来一遍，分配时，应该更加明确些，具体到某一点的哪些内容，否则会出现队员做了相同的事，而产生了无用功浪费了人力物力。同时沟通真的很重要，队员间要多多加强沟通，防止因为误解队员的意里而产生误会。

 

四.变更管理

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

能，通过微信告知，或者通过github看。

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

在前期就完成了需求分析，并且讨论了各个功能实现的难易。“推迟”和“必须实现”是这样界定的：1、核心功能中容易实现的必须在 alpha 版本实现；2、核心功能中有技术难点的推迟到 beta 版本实现。后来也是按照这个方法完成了项目。

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

小组对项目的出口条件主义定义：能正常使用所有功能，多次测试不出现bug。

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

对于重大的变更，我们暂时没有应对计划,但是，我们有应对数据库变更的计划。我们对数据库进行了备份（备份在eolinker上），能够在需要的时候使用恢复备份以及扩展数据库。

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

可以。每个成员都会按时完成自己负责部分，如果又意料之外的请求，那么就需要按照个人能力进行讨论分配。

 

五.设计/实现

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

设计工作在需求分析和alpha冲刺阶段都有涉及，主要组长领导完成，是在合适的时间，合适的人。

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

没有出现。要是出现摸棱两可的情况，会和所有开发人员一起进行讨论决定

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

有运用单元测试，UML测试，等测试工具。这些工具很有效，大大的提高了测试的效率，降低了手工测试的工作量。同时有的测试工具还有提供一些小问题的解决办法。为我们减轻了很多负担。

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

开发阶段出现bug都是很正常的现象，出现最多的bug是和界面结合的功能，都有比较容易出现bug，主要是通过界面获取输入输出有些问题。发布之后的bug，暂时没有。

5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

在前期项目还没开始的时候就有编码规范了，开发过程也要求开发人员按照编码规范编码，代码复审是各自审核自己所写的代码，然后再团队中找另外一个人再次确认。

 

六.测试/发布

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

测试计划没有安排，测试首先由开发人员自己完成所编写的功能，最后集成之后由测试人员（一个）完成所有功能的测试。时间安排不够用，所以没有测试计划

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

有对每一部分功能进行正式的验收测试

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

有

4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

各个模块的测试分配给各个相应的开发组员，这些组员进行用例测试。从软件实际运行的结果来看，这些测试工作还是挺有用的。改进的方面就是大家应该在如何运用测试软件上多做些学习，这样可以保证正确的执行测试任务同时节约时间提高效率。

5. 在发布的过程中发现了哪些意外问题？

要在新机器上运行需要要求该机器也有对应的开发环境才能运行，这是因为项目除了用java，还使用了python的第三方库，第三方库需要有环境才能使用

 

 

 

成员贡献

姓名	角色	团队贡献分	可验证的贡献
卓家鸿	开发，PM	22	商家端
郭家豪	开发	21	界面
陈庆生	开发	20	客户端
蒋权	测试	20	测试，数据收集
何炎尧	开发	18	商家端
颜树钦	开发	19	界面