5组-Beta冲刺-总结

https://www.cnblogs.com/pat-chou-li/p/15616365.html

一、基本情况

• 组长博客链接：https://www.cnblogs.com/pat-chou-li/p/15616365.html

• 现场答辩总结：

  ​ 适配在正方形屏幕上翻了车，不过评测组用自己的电脑看了应该问题不大——

  ​ 问的问题主要都和政策文件的齐全性有关，首先部分省份的省文件库中就包括了地级市，而有些没有，导致了与人们印象中政策文件数量的差异。比如内蒙古的省文件库里就包括了地级市，导致其政策活跃度看起来很高。再加上部分省份难以爬取，获得的文件数较少，造成了公平性上的问题，也就导致了最后这个政策活跃度排名看起来非常的不靠谱。

  ​ 第二是搜索接口过慢的问题，一是数量过多，二是优化做的比较差。

  ​ 总的来说还是爬取工作量太大了，即使全组上阵也无法很好的完成任务，也导致了接口慢、数据不全。但是无论如何，预期完成的工作还是交付了，并且也有比较好看的前端界面和规范的文档和代码，还是较为令人满意的。

• 全组讨论的照片：

  

• 评估团队中每个人对本次作业的贡献比例，描述为本次作业的工作流程、组员分工、组员工作量比例：

  团队成员	分工情况	任务比例%
  吴振溢	前端、爬虫	11%
  林蒋辉	服务器部署	11%
  黄朝威	爬虫主要负责人	15%
  周浩东	部分后端接口	14%
  周伟杰	部分后端接口、爬虫	11%
  张乐芃	前端和前端服务器部署	11%
  潘春佳	文案	8%
  陈宇扬	爬虫	11%
  蔡树峰	文案	8%

二、总结思考

2.2.1 设想和目标

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

   • 对各大政府网站的政策文件进行大数据收集、基于知识图谱进行分类，提供政策检索，数据大屏，政策地图等功能，方便普通民众了解所需政策或攥写文章查询文件的需要。定位清晰，面向普通民众，检索方便快捷。

   • 典型用户：拥有政策检索需求的普通民众：如高校应届毕业生、私营企业家等。

   • 典型场景：大学生需查询购房、人才政策时；企业家想了解政府补贴、退税等政策时

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

   • 计划做出政策地图、数据大屏、政策检索三个模块。

   • 三个模块，基本按照原计划交付时间交付。

   • 暂时未对期望用户量做出明确定义，并且由于核心功能还没有完善，需要在Beta版本完成之后考虑进行推广获取用户量。

3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

   • 由于β冲刺短暂，暂时还未进行推广，因此用户量为零，用户对重要功能的接收程度，需要在之后进行调查。
   • 是的，随着前后端对接，软件功能实现，我们离目标更进一步了。

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

   • 团队合作需要在任务开始前有明确的目标

   • 需要合适的分工以及分工方式

   • 开发过程要保持充分的沟通

   如果历史重来一遍, 我们会做什么改进：

   • 更早的开始开发
   • 分配任务更加精细化
   • 打造更准确的计划表

2.2.2 计划

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

   • 是的，对于前后端来说有充足的时间。在Beta版本阶段，我们开过多次组会，确定好每天需要做的事情，并把每个任务细化，分配各个成员的工作。

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

   • 通过开会并一起讨论，分析利弊，最后做出合适的选择。

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

   • 基本完成，到总结时都已达成在Beta阶段的目标。
   • 政策文件仍然不全，要爬取的省份太多，单单多就能带来巨大的问题。

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

   • 有。比如一开始试图爬取到地级市的具体范围内，并且也爬了几个地级市，后来发现省都要完不成了。

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

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

   • 是，三个模块，数据获取则是全国34个省级行政区的政策爬取进度。

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

   • 有，主要就是低估了爬取政策的难度。除了甘肃以外的省份确实没有对政策进行加密，但是它们的标签极不规范，并且各不相同，要耗费很多无谓的人力进行爬取，到β阶段为了爬取完全部省份基本整个开发组都在爬。

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

   • 大家首先自行进行自己负责部分的相关学习并初步完成相应的任务，接着会有组员负责找出已经完成的任务中的问题和不足，发布出来，并且选择大家都有空的时候，在活动室一起讨论和解决问题，并根据问题接着完成自己负责的任务。因此可以说是有留下缓冲区的，在每个任务的完成之后都会进行第二步操作，进行相应部分的完善和调整。以及组长衡量项目进度后决定是否需要集体加班。
   • 缓冲区的作用就是可以帮助我们更好地发现问题和更高效地解决问题，进行交流弥补沟通不足和不明确各部分任务完成情况的缺陷。必要情况下进行“冲刺”。

8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）

   • 在一个长的时间范围内进行任务细分，避免拖延症导致最后冲刺完成工作。

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

   • 尽早开始计划，为突发状况留足余量。
   • 在项目早期尽量多的进行学习，避免后期过多的成员无法在开发上起到作用。
   • 增加爬虫和AI的成员数量，他们的工作量由一个人承担太大了。

2.2.3 资源

1. 我们有足够的资源来完成各项任务么?
   • 可能没有，项目目标可能过于庞大了，导致AI和爬虫的工作负重过高。还好的是前端和后端结构相对合理。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
   • 一对于各项任务难以估计出精确时间，一般只精确到天。随着开发的进行，对于每个任务的耗时大概有了概念，能够精确到小时。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
   • 测试方面，时间不足，主要精力集中于主要功能的实现。低估了美工设计/文案的难度（如果按柯老师的要求）
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
   • 一开始的分工已经考虑到每个人的特性，相对比较合理。
   • 每个人都无可替代，反而一定程度上起到了反效果，一旦发生意外就出现断节。
5. 有什么经验教训? 如果历史重来一遍, 会做什么改进?
   • 应该多组织模块对接交流，协调好各个部分的进度，避免过多任务串行而导致时间浪费的情况。

2.2.4 变更管理

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

   • 我们有站立会议，更有积极的线上交流，变更消息都能及时传达。

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

   • 通过商量讨论，将那些核心功能作为必须实现；将那些实现起来难度较大，耗费时间长的功能，交付之后实现。

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

   • 能实现理想情况下的功能
   • 通过自己设计的一些样例测试

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

   • 产品的业务逻辑在初期就已经敲定，对于小范围变更也可以根据当时的人手和情况进行应急处理

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

   • 部分员工的效率较高，可以处理额外的工作请求

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

   • 对于产品细节要求应该一开始尽可能的确定，且充分考虑其可行性，预估可能遇到的困难，尽量减小变更发生的可能性。

     实现过程中尝试了一些未曾接触过的技术，由此带来的变更却又无法避免，需要提前预留足够的资源余量。

2.2.5 设计/实现

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

   • 页面设计工作在选题报告的时候就开始了，由周伟杰和陈宇扬实现最初的原型设计。作为项目的起始自然是合适的时间合适的人。
   • 当然，前后端的代码风格、类结构设计等等是由各开发组组长在项目前期负责的，效果也相当不错。在Beta阶段中，负责爬虫的黄朝威也将兼容度极高的代码分享给全部开发组，以便于大家都快速进行爬取。

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

   • 存在。各个模块内部的不一致，小范围讨论即可；遇上模块间对接的分歧，用过组会讨论达成一致，以可行性为第一目标。

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

   • 进行了各个功能的分别的单元测试，由各个功能的开发者完成。有效，在整合前和整合后都能实时地对各个模块的正确性进行验证。
   • 在开发前也完成了各个部分的UML，虽然在实际开发时有所更改，但大致思路都没有问题，增加了开发效率。

4. 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

   • 区别不大，一方面是开发人员经验较为丰富，对于需求所需要的代码构成很熟悉。只进行了少量的更改和扩展，并不需要过多更新。

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

   • 主要是爬虫，来源于各种政府网站的接口和html都各不相同，从排版到加密方式等等，导致bug频出。
   • 暂无
   • 设计开发经验不足，预见性不够。没有专门负责code review的成员。

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

   • 由各小组组长统一制定，但实际上最后由开发者自己进行代码复审，开发者在开发中有意执行代码规范，没有太多风格各异的代码。

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

   • 掌握了不断学习新技能的能力和学到了新的技术，运用了新的知识。
   • 如果历史重来一遍，我们还是要不断犯错才能获取相应的经验，应该更早进行模块对接讨论。

2.2.6 测试/发布

1. 团队是否有一个测试计划？为什么没有？ 是否进行了正式的验收测试？
   • 有的，前端方面也完成了测试计划，在各种比例的电脑屏幕上（除了正方形？）进行了适配和动画流畅度观察。但是没有进行正式的验收测试。
2. 团队是否有测试工具来帮助测试？
   • 没有太专业的测试工具，主要靠谷歌浏览器提供的各类控制台。
3. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
   • 看谷歌控制台判断哪些资源或者接口占用了过多的时间，适度的更改代码、更换组件或者删除。
   • 还算有用吧，启动时间在多次测试下大致从7s减少到4s。
4. 在发布的过程中发现了哪些意外问题？
   • 已经发布于外网，可能在适配方面仍有问题，并且随着数据量的增加，接口的请求速度越来越慢了。
5. 学到了什么? 如果历史重来一遍, 会做什么改进?
   • 学到了没事尽量不要重复请求接口，各种组件应该按需引入。
   • 写代码的时候考虑防抖和节流。

2.2.7 团队的角色，管理，合作

1. 团队的每个角色是如何确定的，是不是人尽其才？
   • 在充分考虑个人意愿的情况下，根据个人的技术栈进行角色分配。使团队成员各司其职，创造巨大的生产力。
2. 团队成员之间有互相帮助么？
   • 有，几乎每天都在沟通交流解决成员遇到的困难。由于我们小组成员宿舍相隔不远，线下交流也十分方便。
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？ 每个成员明确公开地表示对成员帮助的感谢 （汇总至组长博客）：

• 吴振溢：我感谢**<张乐芃> **对我的帮助， 因为某个具体的事情: 帮我部署前端服务器。

• 张乐芃：我感谢 __<吴振溢>__对我的帮助， 因为某个具体的事情: 接口和部分逻辑遇到些问题，非常感谢zygg的帮助。

• 蔡树峰：我感谢 __<黄朝威>__对我的帮助， 因为某个具体的事情: 他太能爬数据了，任务量max。

• 陈宇扬：我感谢 __<黄朝威 >__对我的帮助， 因为在beta冲刺期间，最紧张并且最需要的就是爬虫工作。黄朝威对我爬虫上遇到的难题都一一解答或是一起解决，并且对于部分无效数据也负责任的去除并重新注入数据库。

• 潘春佳：我感谢__ <周浩东>__对我的帮助， 因为某个具体的事情: 在写博客和做ppt时，为我提供了丰富的成果图，并且很细心的告诉我每个图的展示内容。

• 周伟杰：我感谢 __<林蒋辉>__对我的帮助， 因为某个具体的事情: 帮我部署了服务器，也教了我很多后端开发的基础。

• 林蒋辉：我感谢__<周浩东>__对我的帮助，因为在开发期间对我的问题耐心回答，知无不言，给我带来很大的进步和帮助

• 周浩东：我感谢__<黄朝威>__对我的帮助， 因为某个具体的事情: 爬取大量数据。

• 黄朝威：我感谢 __<陈宇扬>__对我的帮助， 因为某个具体的事情: 我们一起完成了剩下的爬取工作，没有他，我单个人恐怕比较吃力。我感谢 __<吴振溢>对我的帮助，因为某个具体的事情: 总是在我遇到抓接口无法成功的时候，帮我整合生成对应的代码，加速了爬取进程。我感谢<周伟杰>__对我的帮助，因为某个具体的事情：感谢他也能在最后阶段能用模板代码一起完成任务。

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

• 对于不同的人要采取不同的沟通方式，调动大家的积极性，避免成为ddl战士。

2.2.8 总结

列出组内所有人的心得。

• 吴振溢：beta冲刺加入了爬虫的行列，以致于养成了看见爬虫负责人员进入宿舍就打开pycharm的PTSD，直至项目完成后的没有消除。并且还把后端给的接口接上了，还是挺累的，不过前端部署工作全面交给了张乐芃，感激。

• 张乐芃：beta冲刺主要任务是在接接口和部署，好久没有用过服务器，真是又熟悉又陌生，学习的话，更多是去学习了很久之前一直想学的nginx，部署的过程和学习还是蛮愉快和顺利的（不错，以后可以更多的部署好玩的东东了，芜湖）。最后还是感谢各位队员的辛勤付出，比较顺利的完成了这次的大作业。

• 蔡树峰：β冲刺主要都是队友在冲，感谢队友带飞！我还剩下制作视频的任务，接下来的时间，其他科目的任务也很繁重，得构思好视频的制作方案，提前开始准备。

• 陈宇扬：这次beta冲刺阶段，爬虫工作还是比较繁重的，以至于后面全组人都在爬数据，最后我们的政策数也从20w+涨到了50w+。最后感谢全组人的辛苦付出。（爬数据真的好难！）

• 潘春佳：做仅有的任务时我还时不时犯错，还好有队友们及时发现改正，而且还没有责怪我，让我倍感惭愧，希望有机会的话能做更多。

• 周伟杰：从什么都不会到会简单的开发，这学期在软工这门课上付出了大量的时间。有时觉得实在不值，但一切都结束时又觉得过去的努力都有是意义的。也遗憾前两年没有进行学习，导致现在如此狼狈，不过过去的事再想也没用，一切从现在开始。

• 林蒋辉：学会了elastic search框架实现框架，也知道了部署也不用无脑用docker，也有一些更简单的方法，代码能力也得到了提升。

• 周浩东：时间飞逝，不知不觉间《软件工程》的学习已经过了大半了。在这将近半学期的学习中，虽然我不能说我将《软件工程》学习的有多么的好，但是通过学习，我还是受益良多。

• 黄朝威：在Beta冲刺中度过了非常难忘的几个夜晚，总的来说异常艰难，充满着收获和遗憾，遗憾的是爬取的数量有限未能所有省均将地级市包含在内，部分省有涉及地级市爬取部分省未能够爬取地级市，收获是发现自己写的代码越来越好用了，发现自己初期辛苦专研摸索出来的模板异常强大仅需改改部分内容即可推广，具有一定的普适性，在这个阶段内我和宇扬都在完成爬取剩下的内容，甚至后面写出了模板代码让组内前端和后端动员一起加速进程，遗憾的是部分省份由于请求采用的参数为Token尽管模拟浏览器后仍然无法攻克，采用先进工具甚至无法刷出网页，我和前端的组长都调试过那令人绝望的Ajax，本以为可以获得生成Token的js代码进而直接攻关，但没想到请求参数还是来自政府网页后端生成。