过后诸葛亮

做业格式

• 课程名称：软件工程1916|W（福州大学）
• 做业要求：过后诸葛亮（团队）
• 团队名称： 那周余嘉熊掌将得队
• 做业目标：过后诸葛亮
• 团队信息：

队员学号	队员姓名	博客地址	备注
221600131	Jamin	https://www.cnblogs.com/JaminWu/	队长
221600308	我超可爱的	http://www.cnblogs.com/XNC-SoCute/
221600305	haziza	http://www.cnblogs.com/haziza/
221600340	你看见个人小熊了吗	https://www.cnblogs.com/stereohearts/
221600426	Hunterj Lin	https://www.cnblogs.com/HunterJ/
021600823	玫葵	https://www.cnblogs.com/offeroques/

目录

1. 设想和目标
2. 计划
3. 资源
4. 变动管理
5. 设计/实现
6. 测试/发布
7. 团队的角色，管理，合做
8. 总结

做业正文

• 设想和目标

1. 咱们的软件要解决什么问题？是否认义得很清楚？是否对典型用户和典型场景有清晰的描述？
   • 咱们的软件要解决的是福州大学服务外包实验室的对外展现和赛事管理交流方面的问题。
   • 定义的挺清楚的。
   • 对典型用户和典型场景有相对清晰的描述。根据老师和实验室管理者进行需求分析，从而创建文档。
2. 咱们达到目标了么
   • alpha计划的接口和组件都作到了。

• 有什么经验教训? 若是历史重来一遍, 咱们会作什么改进?
  • alpha阶段咱们的策略就是铺好底层代码，尤为是前端咱们不急于拼接页面整合路由，而都是再封装以后须要的组件。这样以后不管是要实现后端的功能扩展仍是前端组件的多样化，都能很快地继承原有的接口或组件进行实现，因此alpha阶段主要是介绍咱们的开发流程、过滤算法和底层组件，没有演示页面点击跳转的功能。而从你们答辩提出的问题中所有都是围绕没有直接演示这一点展开。因此若是历史重来我可能会先为了保证团队分数，先单首创建一个展现分支，将已完成的页面路由进行整合，方便演示。

• 计划

1. 是否有充足的时间来作计划?
   • 有的。课程前的选题报告分析和需求分析报告等让咱们有足够的时间制定相应的计划。在数据库设计等以前就完成了计划制定和任务分工。
2. 团队在计划阶段是如何解决同事们对于计划的不一样意见的？
   • 目前并无出现有较大分歧的状况发生，极少数有不一样意见的状况下，咱们会分别进行阐述，而后进行投票，选择更合适的方案
3. 你原计划的工做是否最后都作完了? 若是有没作完的，为何?
   • 任务基本按原计划完成。
4. 有没有发现你作了一些过后看来不必或没多大价值的事?
   • 因为前期规范不够清楚，你们在建立文件夹和文件时可能只是遵循本身的开发习惯，这样后期merge就会出现功能相同但名字不一样的文件夹，就会有一部分人须要妥协修改本身的目录及代码中的引用路径，这些若是前期强调清楚，并在master创建文件时先建好目录框架，实际上是能够避免的。
5. 是否每一项任务都有清楚定义和衡量的交付件?
   • 有明确的交付件和代码定义规范。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为何没有估计到?
   • 咱们的计划和分工都较为合理和明确，项目目前并无出什么意外。
   • alpha阶段前端进度较慢，但这是以前预估到的，因此一开始计划的进度也是较慢的。主要是为了以后的编码打好基础。
7. 在计划中有没有留下缓冲区，缓冲区有做用么?
   • 有留下缓冲区，咱们认为缓冲区是十分有必要的，咱们能够在缓冲区的时间段内进行修整，并对其余科目的考试进行准备。
8. 未来的计划会作什么修改？
   • 对新加入成员的培训。由于新加入成员是Java技术栈，而咱们后台用的是 .net，因此须要让新成员熟悉咱们底层大量封装的代码是当务之急。同时为了预防新成员没法较快上手的状况，咱们也提供了让新成员参与测试任务的方案。
   • 因为项目规模与组员时间的矛盾，咱们会先将交流中心功能放在最后实现，保证其它功能先上线。若有时间再开发交流中心模块。

• 咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?
  • 主要学到了对项目进度的总体把控能力。
  • 我会更精准地预估项目花费时间以及可能会面临的困难，列出时间点更详尽的计划。

• 资源

1. 咱们有足够的资源来完成各项任务么?
   • 硬件资源上，服务器选择的是实验室的服务器，其余的电脑等配置也都足够。
   • 人力资源上，小组人员分工合理，但前端工做量较大，略有压力。
2. 各项任务所需的时间和其余资源是如何估计的，精度如何?
   • 按照学习上手的时间和实际编码的时间来估计，对于小组中有人已经掌握的技术估计精度较高，由于能够根据本身的经验判断；但若是小组没人了解过，那估计精度就会存在误差，这应该也是难以免的。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不须要编程的资源 (美工设计/文案)是否低估难度?
   • alpha阶段主要只进行了单元测试，因此是足够的
   • 并无低估难度。由于小组成员已有完整的开发经验。
4. 你有没有感到你作的事情可让别人来作（更有效率）?
   • 先后端的编码若是给有较丰富项目经验和有框架经验的人来作确定效率会更高。

• 有什么经验教训? 若是历史重来一遍, 咱们会作什么改进?

  • 可能不会选择规模这么大，仍是最后要交付甲方的项目，须要考虑代码可维护性、软件寿命、拓展性、性能优化等现实问题，挖坑给本身跳。设计和编码阶段时间紧张，确定没办法全面分析该项目的每一个功能模块，最后得分还不如时间花的少的队伍。而选择小项目，花费时间少，分析和编码都能完成度更高，最后分数也更高。

• 变动管理

1. 每一个相关的员工都及时知道了变动的消息?
   • 是的
2. 咱们采用了什么办法决定“推迟”和“必须实现”的功能?
   • 根据甲方需求。
   • 没有就不能上线的项目即为必须实现，没有也能够先上线使用的能够推迟。
3. 项目的出口条件（Exit Criteria – 什么叫“作好了”）有清晰的定义么?
   • 代码风格统一，目录清晰易懂，可快速定位须要维护的组件
   • 前端最低适配900px宽度，最高适配1400px
   • 每一个接口经过mock.js搭配swagger进行的测试
   • 经过自动化测试，测试日志无异常
4. 对于可能的变动是否能制定应急计划?
   • 能。好比此次队伍忽然换人。
5. 员工是否可以有效地处理意料以外的工做请求？
   • 是。如这次队伍忽然换人，咱们就作好了两手准备，不管组员最终结果是否能融入，都将减小对团队形成的影响。

• 咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?
  • 学到了应对队友变对手的可能性。
  • 若是历史重来，咱们会编写规范的代码文档，且作好备份，防止删库跑路。

• 设计/实现

1. 设计工做在何时，由谁来完成的？是合适的时间，合适的人么？
   • 前期有为期数周的设计阶段，由全组协做完成。
   • 前期时间较宽裕，很合适。
   • 团队人数有限，没有更合适的选择了。
2. 设计工做有没有碰到模棱两可的状况，团队是如何解决的？
   • 有。
   • 请教项目经验更丰富的学长。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其余工具来帮助设计和实现？这些工具备效么？ 比较项目开始的 UML 文档和如今的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
   • 运用单元测试、UML、easy-mock、SwaggerUI等。
   • 有效。
   • 无区别，前期设计花了很长的时间已较严密地考虑了可拓展性的问题并想出了解决方案。
4. 什么功能产生的Bug最多，为何？为何咱们在设计/开发的时候没有想到这些状况?
   • 赛事模块，由于须要有较强的拓展性，且有不少细节须要考虑。
   • 项目开发主要靠经验，显然咱们的代码经验都不够丰富。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
   • 使用ESlint，可设置代码规范和风格，由插件进行检查和错误提示，定位未符合规范的代码。

• 咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?
  • 开发过程当中遇到一个很大的问题是因为前期规范不够清楚，你们在建立文件夹和文件时可能只是遵循本身的开发习惯，这样后期merge就会出现功能相同但名字不一样的文件夹。若是历史重来我会先在目录里将后期全部会遇到的文件夹按功能模块先都创建起来，以后根据功能模块创建feature分支，分支之间基本不存在耦合，这样后期合并分支就会省去不少选择保留的时间。若是后期须要前期没有预估到的目录，那应该汇报给项目负责人，由项目负责人在dev分支创建后其余人及时更新。
  • 学到了业界规范的开发流程。前端使用webpack+Vue全家桶开发，后端使用 .net core跨平台开发SPA。由于单网页的特性还增长了许多性能优化的措施，如keep-alive、路由懒加载、异步组件等。后端作了不少提升安全性的措施，如防sql注入、一句话木马、RSA加密等。代码规范方面使用ESlint自动审查每一个人的代码并定位不规范的代码片断，提升效率。

• 测试/发布

1. 团队是否有一个测试计划？为何没有？
   • 有，见团队测试博客。
2. 是否进行了正式的验收测试？
   • 否
3. 团队是否有测试工具来帮助测试？
   • 有。easy-mock、SwaggerUI、RIDE
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工做有用么？应该有哪些改进？
   • 一开始是本身编写mock脚本，目前使用的是可视化插件和工具更加便捷，且搭配使用效果更佳。
   • 测试工做确定是有用的，减小上线后出现的问题。
   • 测试这个环节是咱们学生开发经常忽视其重要性的，以前面试阿里天猫时一位测试工程师谈到他们现在的工做不只是在开发后期测bug让开发人员修复，还要从设计的时候就要进行风险评估，预防开发人员写bug，其实对项目的把控要求很是高，但后者咱们显然还未作到，也是我目前想了解但没机会没时间深刻学习的。

• 咱们学到了什么? 若是重来一遍, 咱们会作什么改进?
  • 学习了一些测试工具，提升了项目的规范性，更好地预知了项目的bug并修复，减小了上线后的风险。
  • 虽然在选择测试工具上咱们没有直接了解到如今的测试工具，是进行到一半才在查阅资料中学习到的。可是我认为这样的过渡是在所不免的，说不定过几天又学习到了更适合的开发工具也未可知。

• 团队的角色，管理，合做

1. 团队的每一个角色是如何肯定的，是否是人尽其才？
   • 因为你们接触编程的时间都不长，因此有明显的技术偏向和喜爱，因此这一点仍是很容易把控的。
2. 团队成员之间有互相帮助么？
   • 团队两级分化较大，必需要花不少时间来帮助一些组员上手框架，不然任务将集中在少数人身上。
3. 当出现项目管理、合做方面的问题时，团队成员如何解决问题？
   • 哈孜娜：我感谢熊宁畅对个人帮助，由于有任何不会的问题都会认真帮我分析并解决。
   • 吴嘉民：我感谢林将航对个人帮助，由于我能够很放心地把后台和网络安全交给他负责，让我集中精力在前端上不用两头兼顾。
   • 熊宁畅：我感谢吴嘉民对个人帮助，由于前端的知识和框架都是他告诉我要怎么学的。
   • 周杨富：我感谢熊宁畅对个人帮助，由于在写不动代码的时候她能鼓励我。
   • 余秉鸿：我感谢吴嘉民对个人帮助，由于关于测试的方向和技术都是他给个人指导。
   • 林将航：我感谢吴嘉民对个人帮助，由于与我对接后端接口、以及指出后端接口设计的不合理之处。

• 总结

  • 你以为团队目前的状态属于 CMM/CMMI 中的哪一个档次?
    • 可复用级
  • 你以为团队目前处于 萌芽/磨合/规范/创造 阶段的哪个阶段?
    • 规范
  • 你以为团队在这个里程碑相比前一个里程碑有什么改进?
    • 团队逐步熟悉开发框架，开发效率提升。
  • 你以为目前最须要改进的一个方面是什么?
    • 两极分化较大，组员还须要提升编码能力，提升代码质量。

• 新进组员工做交接

  • 因为新进组员擅长Java后台开发，而咱们项目是 .net框架，因此须要新进组员较漫长的学习，大体方案以下：
    • 掌握C#基本语法与 .net core框架的基本结构和用法。
    • 讲解后端底层代码
    • 因为alpha阶段后端对底层进行了大量封装，现在controller层的对外接口只是水到渠成。因此可将一些对外接口交予实现
    • 若不肯意另外学习 .net技术栈，也可参与测试工做，编写更规范完善的测试脚本，为项目扫雷。

• 照片