事后诸葛亮分析

一.设想和目标

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

      我们的软件预期在实现最基本的打卡工具的基础上，新增番茄钟专注功能和社交圈子吸引用户，定位明确。但有些使用逻辑略显累赘，后期稍有修改，但还有地方可以做到更好。

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

      团队前期计划已经预料到团队时间精力不足，制订计划的时候，我们把“社交圈子”功能模块定为待定实现模块.至今我们实现了预期的90%的功能，基本达到目标，只是实现时间稍有延迟。因没有发布产品，故只有内部人员使用，没有达到预期用户量。

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

     与Alpha阶段相比，团队软工的质量大大提高，队员之间的交流明显比上一个阶段要多得多。另外，上一个阶段大家比较不擅长利用时间，很多时候工作会拖延接近截至日期才加班加点完成，很仓促，这一阶段明显改进。

 

二.计划

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

　　除考试时间外，大家都有充足的时间做计划。

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

　　中和大家的意见，少数服从多数。

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

　　最终阶段，后台有些接口还是没能及时提供。由于前端和后台商量接口文档不够及时，造成数据库设计不够恰当，后期开发的时候，造成浪费大量精力修改，但软件的主要功能模块的接口都基本实现完毕。

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

　　基本上符合，开发过程中会根据具体情况做出相应的修改。

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

　　项目意外：没有预估到小程序对接后台接口调试需要配置域名、域名要备案….备案要审核20+天….前期没能估计到这些情况是因为第一次开发微信小程序，对微信小程序的学习不够充分，如果能在前期预估到这些意外情况，我们会选择使用云开发，就可以省去了以上很多麻烦。

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

　　没有

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

　　对软件开发的流程有更多的了解，队员间的合作能力明显提高。改进方面，在时间安排，与任务分配，以及人员安排等方面仍需要调整。

 

三.资源

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

　　打卡工具在现实中已经有很多成熟的产品，我们有足够的资源参考；

　　开发人员略显不足；

　　开发时遇到需要备案域名的问题，但备案所需时间过长，没法提供。

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

　　 计划赶不上变化。

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

　　由于市面上的打卡工具较为成熟，且功能较为简单，为了交互体验、美观效果，拥有我们团队自己的特色，我们投入了相当可观的设计人力资源。

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

　　在队伍中，我的沟通组织能力不够优秀，更偏向于默默开发，有时候由别人来组织会更有效率，但这次的作业也很好地锻炼了我的相关能力。

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

　　沟通很重要，非常重要！！！

四.变更管理

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

　　能，通过微信告知。

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

　　根据我们制订的功能模块优先级，必须实现主要功能（打卡），次要功能可推迟实现。

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

　　实现预期功能，没有严重影响用户体验的bug，用户反馈良好。

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

　　没有特定去制定计划，遇到问题立刻着手解决。

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

　　 大部分能。有些意外情况自己实现不了，也会请教有经验的同学的方式帮忙解决。

 

五.设计/实现

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

　　设计工作在需求分析和alpha冲刺阶段都有设计，由大家共同讨论，组长和负责产品的组员决定。

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

　　没有出现，队员觉得模糊的地方会及时提出疑问，相关人员会对应解答。

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

　　运用了在线mock平台模拟数据、蓝湖等工具。这些工具大大提高了测试的效率。

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

 成员互相审核。

 

六.测试/发布

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

　　功能模块测试都是先经过开发成员开发过程中发现问题、及时解决，再经过未参与开发的成员使用体验，反馈情况给开发人员进行进一步地完善。

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

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

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

　　有。

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

　　各个模块的测试分配给各个相应的开发组员，这些组员进行用例测试。从软件实际运行的结果来看，这些测试工作还是挺有用的。

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

　　未发布。

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

如果历史重来一遍，我们会在前期计划阶段，更加认真地做计划，全员参与计划，充分理解产品需求。另外，作为组长，我应该更加积极与队员沟通，带动队员工作积极性，监督大家的进度，从而避免出现大家接近截止时间才加班加点赶工，让团队有一个更融洽的开发环境。

 

产品效果展示：

 

成员贡献

姓名	角色	团队贡献分	可验证的贡献
罗海屏（组长）	前端	23	前端页面开发
张妙馨	后台	22	后台开发
刘昱君	前端	21	前端页面开发
潘蓓文	UI设计	19	UI设计
钟小敏	产品	18	产品需求
郑晓婷	UI设计	17	UI设计