事后诸葛亮分析

一、全组讨论照片

二、设想和目标

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

答：我们的选题是一个时间规划小程序，主要为用户智能统筹安排每天的任务，解决茫无规划的问题；

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

答：基本上原计划的功能都得以实现，同时也按照原计划交付；由于小程序正式版上线限制，导致目前只能使用体验版，所以用户量上被较大限制；

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

答：和上个阶段比，软件工程质量有所提高，主要是在项目的安全健壮性上提高了；

4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么?

答：和我们的预想几乎一致；

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

答：经验教训的话主要是一开始对一些项目功能没有给出很清晰的实现目标，导致在开始阶段UI设计界面改版次数较多；若历史重来，我们会进一步加强彼此之间的沟通，给出清晰的实现目标；

三、计划

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

答：时间上其实比较紧张，因为大多数同学有加入工作室，本身有其他项目在身，所以能够在一起做计划的时间并不充裕，不过我们沟通的效率比较高，从而弥补了时间上不足；

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

答：通过大家积极的讨论，主要是以多人表决的方式来决定；

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

答：原计划的工作都完成了；

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

答：项目进程基本上按照计划执行，没有出现什么较大的意外，在冲刺阶段一开始进度稍微慢些，主要是和其他科目考试有所冲突；

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

答：没有留下缓冲区，每个功能模块在写完代码后便进行自我测试，因此整个流程下来基本上没有缓冲的时间；

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

答：对于项目的进度需要提前加快，这样能够后面留有缓冲时间，能让我们对各个功能模块进一步完善；

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

答：

加快项目的进度，留有缓冲时间，使得对各个功能模块进一步完善；
做计划时需要尽可能多地注意可能发生的一些情况，比如考试时间的冲突等；

四、资源

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

答：

人力资源：充足；因为在组建团队的时候，每个成员都有属于自己的专长，主要分三个方向：后台3人、前端2人以及UI设计1人，因此从完成项目的过程来看，较合理的成员配置对项目的开发很有帮助；
文案资源：稍微缺乏；因为在项目博客中涉及到的一些文案是之前没有学到过的，所以大家的经验并不足；

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

答：各项任务所需时间是根据实现的难度以及模块数量来估计的，基本上和实际开发的时间类似；

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

答：

测试时间：我们留有3天的时间进行测试，所以是足够的；
人力资源：正如上面所说，我们的成员配置较为合理，因此人力资源也是足够的；
软件/硬件资源：充足，每人都有对应一台设备进行编码设计，同时有一台云服务器为项目进行线上部署；
美工设计/文案都有做比较充分的准备，没有低估难度；

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

答：在整个项目过程中，我督促大家完成任务不是很多，所以可能大家在完成任务的效率上不那么高效，如果换成更加善于积极沟通的人做队长，可能效率会更高些；

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

答：主要经验教训是整个团队工作效率上吧，要更加善于和成员进行沟通，提高工作效率；

五、变更管理

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

答：是的，一旦有模块功能设计的变更，便会在群里进行通知，做相关模块的同学便可立即根据要求更改；

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

答：对于项目正常核心的功能模块，我们将其设定为”必须实现“，并优先实现它们，对于在原有基础上添加的一些附加功能，若对正常功能没有影响且时间比较紧急，就将其设定为”推迟“功能；

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

答：

确保没有业务逻辑的bug；
保证页面能够正常使用，不会出现长时间的延迟；
保证项目所有功能都经过多次严密测试；
能够承载较高的并发量，比如2000这里；

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

答：能，对于可能的变更我们会先商讨好，并事先做好处理，以便在出现需要正式变更时，可以直接更换使用；

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

答：对于意料之外的工作请求，如果是内部人员的安排规划，那么团队成员定是很乐意去接受并修改的；对于外界成员的要求，如果确实符合正常逻辑要求以及功能设计，那团队成员也是会欣然接受的；

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

答：对于任务变更可能性需要做更多的预估，同时对于任务需要尽可能地确定下来，尽量少出现变更的情况；

六、设计/实现

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

答：

设计工作在项目确定主题后便开始展开执行，是由简蕙兰同学一个人完成的UI界面设计，其他同学根据功能需求给予设计师设计思路；
设计时间合适，因为需要现有设计稿，前端后台才能明确自己的需求，是整个项目一开始最核心的部分；
设计人员合适，简蕙兰同学有比较丰富的设计经验，本次设计总体效果也很好；

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

答：有碰到摸棱两可的情况，主要是在日程表模块与个人、团队模块衔接这方面的设计；

　　解决：通过开线上会议的形式，每个人谈论自己的观点，最后投票选出最合适的衔接方案

3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

答：我们团队从一开始就采用了junit进行单元测试，以及processon来绘制uml图数据流图等，Chrome插件postman进行接口测试，这些工具是有效的，能显著提高我们的工作效率。项目开始时的UML文档和现在有一定的区别，这些区别主要产生于开发的不可预知性，在设计过程中会有对开发所需要的资源有所遗漏。

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

答：Bug最多的功能主要是日程表显示部分，因为这部分处理的逻辑稍微复杂一些，对于呈现出来的数据一开始用postman测试时并没有特别在意返回的数据内容；

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

答：代码复审后期主要由小组各个成员遵照阿里巴巴开发代码规范手册，相互看对方的代码来审核代码规范性，总体来说严格的执行了代码规范。

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

答：对于每个模块都要先给出清晰明确的实现目标，尽量能够通过较少的会议形式高效讨论出设计结果，同时也尽量避免UI设计大改版；开发时严格遵守代码规范，这样在代码复审时才不会出现太多的需要修改的地方。

七、测试/发布

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

答：有，在团队作业3——需求改进&系统设计有详细的测试计划；

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

答：有的，对于每个模块都进行了验收测试；

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

答：后端接口测试：PostMan；单元测试:junit；性能测试：Jprofiler、Jmeter

4. 很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。

改进计划主要是要多利用目前已有的测试工具功能，这样测试起来方便快捷，能够进一步提高代码的覆盖率；

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

答：团队通过使用Jprofiler、Jmeter来跟踪查看软件的效能，从软件的实际运行结果看，这些测试工作很有效，对于哪一块消耗了大量性能，能够准确捕捉。改进的话也许是需要对于测试工具功能的进一步开发，并进行覆盖面更广的测试

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

答：意外问题主要是小程序正式上线没能通过审核，原因是小程序设计的部分功能超过了个人账号可以申请的范围，需要企业号注册才可通过审核，因此导致目前只能使用小程序的体验版；

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

答：测试计划需要布置得更加有调序一些，每个人分配的测试任务要尽量均匀合理；

八、团队的角色，管理，合作

1. 团队的每个角色是如何确定的，是不是人尽其才？

答：团队每个成员在建立这个团队之前都有自己学习的方向，主要是前端、后台以及UI设计；在整个项目开发过程中，大家都是用到了自己平时学到的技术来开发，算是人尽其才；

2. 团队成员之间有互相帮助么？

答：有，在部分模块功能出现问题或者遇到困难时，我们会相互讨论，给予对方建议或者直接通过修改代码来帮助；

3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？

答：通知完成相应模块的负责人，通过开一个小型的会议或微信群来进行沟通，收集各方的意见，然后选择较好地方案。

九、总结

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

答：在CMMI二级，管理级。

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

答：规范阶段

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

答：主要是成员开发效率比之前更高，同时积极主动性也更强；

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

答：最需要改进的地方主要是队长要进一步加强与成员之间的沟通，实时了解项目进度，保证整个开发流程正常有序进行；

对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。

答：

原则1：业务人员与开发人员必须在一起

在整个项目开发阶段，我们团队成员始终保持着联系，每天实时报告项目进度，以线上会议的形式了解大家开发遇到的困难，及时解决问题；
原则2：可用的软件是衡量进度的主要指标

在冲刺阶段，我们几乎每天发布一个版本，且都是可运行测试的
原则3：对技术的精益求精以及对设计的不断完善将提升敏捷性

在整个开发过程中，设计通过不断地讨论，改版次数比较多，对于技术，则是在现学知识的基础上，根据遇到的实际问题，寻找最佳地解决方案；
原则4：要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务

每次团队成员完成一些模块功能，大家都会在群里给予加油鼓励，给予充分的信任和信心；
原则5：无论是团队内还是团队间，最有效的沟通方法是面对面的交谈

　　　由于疫情原因，大家只能在家通过线上会议地形式保持交流，不过整体的效率还是挺高的；

原则6：最佳的架构、设计和需求出自于自组织的团队

　　整个项目的架构、设计和需求均出自于自组织的团队，都是团队成员自主思考的结果；

正如我们前面提到的，软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？

1. 代码管理的质量具体应该如何提高？代码复审和代码规范的质量应该如何提高？

提高质量：进一步学习使用github，多利用那些功能来提高代码管理，质量则可以通过编译器安装代码规范插件等来提高代码质量；
代码复审：开发时，每周/每次冲刺随机匹配成2人小组，由2人互审代码
代码规范：主要依靠IDEA中的阿里巴巴代码规范插件进行检测

2. 整个程序的架构如何具体提高？如何通过重构等方法提高质量，如何衡量质量的提高？

在架构上，我们通过nginx轻量级服务器实现负载均衡以及请求转发，使项目能够提供高并发服务；
重构方面，一是对数据库设计需要更加合理些，比如的查询分成了多次，可以考虑改成多表查询或者创建视图，减少数据库的连接；
衡量质量：服务器性能（90%用户请求响应时间、吞吐量等）以及代码规范性；

3. 其它软件工具的应用，应该如何提高？

　　应该进一步学习编译器IDEA、代码管理仓库Github以及测试工具postman、jmeter等的使用方法

4. 项目管理有哪些具体的提高？

　　项目文档以及会议记录等需要通过一个共享的工具让成员都可以看到，具体如leangoo看板这些；

5. 项目文档的质量如何提高？

应该在开始撰写项目文档前统一文档的规范，最好可以给出一个模板和样例，让文档的撰写更加高效且阅读时也可以快速获取信息。模板的设计主要还是要多去参考其他项目的样式，结合文档需要传递的信息来设计。
可以使用共享文档让成员填写属于自己模块的部分，提高项目文档效率以及质量；

6. 对于人的领导和管理，有什么具体可以改进的地方？

　　在管理方面，由于需要参考所有成员的意见，所以在决定一些事情上面耗时较长，我觉得应该通过成员讨论后，由队长综合各方建议来做出决策，不能把每个方面都有成员投票决定，这样时间开销比较大；

7. 对于软件工程的理论，规律有什么心得体会或不同意见？

软件工程教会了我用工程化方法构建和维护有效的、实用的和高质量的软件，它涉及到程序设计语言，数据库，软件开发工具，系统平台，标准，设计模式等方面，综合运用这些内容，将其使用到开发中，工作质量以及效率上有显著提高。

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

姓名	角色	团队贡献分	可验证的贡献
郭沛	后端	21	后端团队模块开发、项目部署以及博客撰写
柴政	后端	20.5	后端核心算法实现、博客协助撰写以及协助团队管理
洪梓豪	后端	19	个人模块后台开发、博客协助撰写
王树干	前端	19.5	个人模块、登录模块前端开发、小程序部署
黎其钻	前端	19	团队模块开发、个人设置模块开发
简蕙兰	UI	21	UI界面设计、博客协助撰写