5组-Alpha冲刺-总结
https://www.cnblogs.com/pat-chou-li/p/15585872.html
一、基本情况
-
组长博客链接（请在博客开头给出）
-
现场答辩总结
-
部署没部署上就在展示了算是比较大的失误吧，不过经过精心思考之后的展示相信让所有人都明白了我们大概做了什么，前端的页面和数据大屏看起来效果也不错。
-
问的问题主要还是在是否能在β阶段彻底收尾上，最近几天爬虫和后端都燃起来了，我相信他们是能完成的。
-
-
全组讨论的照片
-
评估团队中每个人对本次作业的贡献比例，描述为本次作业的工作流程、组员分工、组员工作量比例（禁止一锅端平的情况，如果没有评估，组长得分减 50%）
| 团队成员 | 分工情况 | 任务比例% |
|---|---|---|
| 吴振溢 | 部分博客、PPT和前端数据大屏 | 14% |
| 林蒋辉 | 词频统计接口和服务器部署 | 5% |
| 黄朝威 | 爬虫 | 16% |
| 周浩东 | 知识图谱和检索接口 | 15% |
| 周伟杰 | 政策数量接口 | 13% |
| 张乐芃 | 前端首页、检索页 | 13% |
| 潘春佳 | PPT | 5% |
| 陈宇扬 | 爬虫 | 11% |
| 蔡树峰 | 博客 | 8% |
二、总结思考
2.2.1 设想和目标（4分）
-
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述 ？
-
对各大政府网站的政策文件进行大数据收集、基于知识图谱进行分类，提供政策检索，数据大屏，政策地图等功能，方便普通民众了解所需政策或攥写文章查询文件的需要。定位清晰，面向普通民众，检索方便快捷。
-
典型用户：拥有政策检索需求的普通民众：如高校应届毕业生、私营企业家等。
-
典型场景：大学生需查询购房、人才政策时；企业家想了解政府补贴、退税等政策时
-
-
我们达到目标了么?（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
-
计划做出政策地图、数据大屏、政策检索三个模块。
-
三个模块，基本按照原计划交付时间交付。
-
暂时未对期望用户量做出明确定义，并且由于核心功能还没有完善，需要在Beta版本完成之后考虑进行推广获取用户量。
-
-
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
- 由于前后端对接善未完成，暂时还未进行推广，因此用户量为零，用户对重要功能的接收程度，需要在Beta版本完成之后进行调查。
- 是的，随着前端界面以及大部分后端功能的完成，我们离目标更进一步了。
-
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
经验教训：
-
团队合作需要在任务开始前有明确的目标
-
需要合适的分工以及分工方式
-
开发过程要保持充分的沟通
如果历史重来一遍, 我们会做什么改进：
- 更早的开始开发
- 分配任务更加精细化
- 打造更准确的计划表
-
2.2.2 计划（5分）
-
是否有充足的时间来做计划?
- 是的，有充足的时间。在Alpha版本阶段之前，我们就已经开过多次组会，确定好Alpha版本需要做的事情，并把每个任务细化，分配各个成员的工作。
-
团队在计划阶段是如何解决组员对于计划的不同意见的？
- 通过开会并一起讨论，分析利弊，最后做出合适的选择。
-
原计划的工作是否最后都做完了? 如果有没做完的，为什么?
- 基本完成，到总结时除了负责部署及词频的后端生病以外，其他都已达成自己在Alpha阶段的目标。
-
有没有发现做了一些之后看来没必要或没多大价值的事?
- 有。比如前端一开始打算踩vue3的坑，一方面想练手，一方面也听说有许多方便和优秀的地方。但是后来发现在短期开发试图采用没有试过的新技术还是太过冒进，最后又退化回vue2。
-
是否每一项任务都有清楚定义和衡量的交付件?
- 有，相对比较宽泛。按任务模块分，前端为政策大屏和政策地图两个模块，后端分为知识图谱建立、政策数据量统计和政策词频统计三个模块，数据获取则是全国34个省级行政区的政策爬取进度。
-
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
- 并没有，首先是后端负责部署的成员生病，导致阿尔法版本页面和已经完成的接口都没有部署到公网上，只能进行本地展示。其次是低估了知识图谱处理的难度，仅仅一个省的两万数据就能抽取出上千万条数据，再做推理要耗费极大的时间，可能β阶段也只能完成一个省作为示例了。
- 成员突然生病是没有办法的事情，特别是对于我们这样的小团体，每一个人都有无可替代的工作，目前看来更好的办法是尽早完成任务，预留足够的时间。
-
在计划中有没有留下缓冲区，缓冲区有作用么?
- 大家首先自行进行自己负责部分的相关学习并初步完成相应的任务，接着会有组员负责找出已经完成的任务中的问题和不足，发布出来，并且选择大家都有空的时候，在活动室一起讨论和解决问题，并根据问题接着完成自己负责的任务。因此可以说是有留下缓冲区的，在每个任务的完成之后都会进行第二步操作，进行相应部分的完善和调整。以及组长衡量项目进度后决定是否需要集体加班。
- 缓冲区的作用就是可以帮助我们更好地发现问题和更高效地解决问题，进行交流弥补沟通不足和不明确各部分任务完成情况的缺陷。必要情况下进行“冲刺”。
-
将来的计划会做什么修改？（例如：缓冲区的定义，加班）
- 在一个长的时间范围内进行任务细分，避免拖延症导致最后冲刺完成工作。
-
学到了什么? 如果历史重来一遍, 会做什么改进？
- 尽早开始计划，为突发状况留足余量。
- 在项目早期尽量多的进行学习，避免后期过多的成员无法在开发上起到作用。
- 增加爬虫和AI的成员数量，他们的工作量由一个人承担太大了。
2.2.3 资源（3分）
- 我们有足够的资源来完成各项任务么?
- 可能没有，项目目标可能过于庞大了，导致AI和爬虫的工作负重过高。还好的是前端和后端结构相对合理。
- 各项任务所需的时间和其他资源是如何估计的，精度如何?
- 一对于各项任务难以估计出精确时间，一般只精确到天。随着开发的进行，对于每个任务的耗时大概有了概念，能够精确到小时。
- 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
- 测试方面，时间不足，主要精力集中于主要功能的实现。低估了美工设计/文案的难度（如果按柯老师的要求）
- 你有没有感到你做的事情可以让别人来做（更有效率）?
- 一开始的分工已经考虑到每个人的特性，相对比较合理。
- 每个人都无可替代，反而一定程度上起到了反效果，一旦发生意外就出现断节。
- 有什么经验教训? 如果历史重来一遍, 会做什么改进?
- 应该多组织模块对接交流，协调好各个部分的进度，避免过多任务串行而导致时间浪费的情况。
2.2.4 变更管理（4分）
-
每个相关的员工都及时知道了变更的消息?
- 我们有站立会议，更有积极的线上交流，变更消息都能及时传达。
-
我们采用了什么办法决定“推迟”和“必须实现”的功能?
- 通过商量讨论，将那些核心功能作为必须实现；将那些实现起来难度较大，耗费时间长的功能，交付beta冲刺实现。
-
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
- 能实现理想情况下的功能
- 通过自己设计的一些样例测试
-
对于可能的变更是否能制定应急计划?
- 产品的业务逻辑在初期就已经敲定，对于小范围变更也可以根据当时的人手和情况进行应急处理
-
组员是否能够有效地处理意料之外的工作请求？
- 部分员工的效率较高，可以处理额外的工作请求
-
学到了什么? 如果历史重来一遍, 会做什么改进?
-
对于产品细节要求应该一开始尽可能的确定，且充分考虑其可行性，预估可能遇到的困难，尽量减小变更发生的可能性。
实现过程中尝试了一些未曾接触过的技术，由此带来的变更却又无法避免，需要提前预留足够的资源余量。
-
2.2.5 设计/实现（4分）
-
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
- 设计工作在选题报告的时候就开始了，由周伟杰和陈宇扬实现最初的原型设计。是合适的时间，也是合适的人。
-
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
- 存在。各个模块内部的不一致，小范围讨论即可；遇上模块间对接的分歧，用过组会讨论达成一致，以可行性为第一目标。
-
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
- 进行了各个功能的分别的单元测试，由各个功能的开发者完成。有效，在整合前和整合后都能实时地对各个模块的正确性进行验证。
- 在开发前也完成了各个部分的UML，虽然在实际开发时有所更改，但大致思路都没有问题，增加了开发效率。
-
比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
- 区别不大，一方面是开发人员经验较为丰富，对于需求所需要的代码构成很熟悉。只进行了少量的更改和扩展，并不需要过多更新。
-
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
- 主要是爬虫，来源于各种政府网站的接口和html都各不相同，从排版到加密方式等等，导致bug频出。
- 还没发布所以暂时没有发现重大bug……
- 设计开发经验不足，预见性不够。没有专门负责code review的成员。
-
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
- 由各小组组长统一制定，但实际上最后由开发者自己进行代码复审，开发者在开发中有意执行代码规范，没有太多风格各异的代码。
-
学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 掌握了不断学习新技能的能力和学到了新的技术，运用了新的知识。
- 如果历史重来一遍，我们还是要不断犯错才能获取相应的经验，应该更早进行模块对接讨论。
2.2.6 测试/发布（3分）
- 团队是否有一个测试计划？为什么没有？ 是否进行了正式的验收测试？
- 有的，前端方面也完成了测试计划，在各种比例的电脑屏幕上（除了正方形？）进行了适配和动画流畅度观察。但是没有进行正式的验收测试。
- 团队是否有测试工具来帮助测试？
- 没有太专业的测试工具，主要靠谷歌浏览器提供的各类控制台。
- 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
- 看谷歌控制台判断哪些资源或者接口占用了过多的时间，适度的更改代码、更换组件或者删除。
- 还算有用吧，启动时间在多次测试下大致从7s减少到4s。
- 在发布的过程中发现了哪些意外问题？
- 还没发布所以不知道，但是只要测试做的够完成，发布的问题应该是最大幅度的减少。
- 学到了什么? 如果历史重来一遍, 会做什么改进?
- 学到了没事尽量不要重复请求接口，各种组件应该按需引入。
- 写代码的时候考虑防抖和节流。
2.2.7 团队的角色，管理，合作（3分）
- 团队的每个角色是如何确定的，是不是人尽其才？
- 在充分考虑个人意愿的情况下，根据个人的技术栈进行角色分配。使团队成员各司其职，创造巨大的生产力。
- 团队成员之间有互相帮助么？
- 有，几乎每天都在沟通交流解决成员遇到的困难。由于我们小组成员宿舍相隔不远，线下交流也十分方便。
- 当出现项目管理、合作方面的问题时，团队成员如何解决问题？ 每个成员明确公开地表示对成员帮助的感谢 （汇总至组长博客）：
- 出现项目管理、合作方面的问题时，大家都能够心平气和的协商来解决这些。
- <吴振溢>：我感谢<张乐芃>对我的帮助， 因为某个具体的事情:前端互相扶持嘛，感谢他分担了一些前端的工作，让我在组长负责的事情上有更多的时间进行处理。
- <张乐芃>：我感谢 <吴振溢>对我的帮助， 因为某个具体的事情: 振溢ggdebug的神，精益求精，非常的nice。
- <潘春佳>：我感谢<吴振溢>对我的帮助，因为我的基础较差，且考试临近，所以在α冲刺中，组长振溢让我继续学习，减少了我的工作量，万分感谢🙏
- <周伟杰>：我感谢 <黄朝威>对我的帮助， 因为某个具体的事情: 这个项目的数据量比预计的要大，本来不应该只让一个人来负责爬取数据。但朝威还是承担了大部分的数据爬取工作，从开题开始到项目结束每天都在高强度爬取，我看着都累。基本上是团队成员中花费时间最多的，因为数据的爬取是整个项目可行性的基础，也承担了很多的压力，感恩了。
- <蔡树峰>：我感谢 <陈宇扬>对我的帮助， 因为某个具体的事情: 为了拍视频提供场地并且友情出演男主角。
- <周浩东>：我感谢 <黄朝威>对我的帮助， 因为某个具体的事情: 为知识图谱功能爬取了大量的数据并导入了我建立的数据库。
- <林蒋辉>：我感谢 <吴振溢>对我的帮助， 因为某个具体的事情:之前因为感冒拖了一段时间，又一直没有注意保养，导致发烧了两天，几天都没有碰电脑的欲望，进度一直没跟上，但是组长并没有苛责我，而是让我好好休息，耐心的和我一起商量解决方案，帮助我赶上进度。
- <陈宇扬>：我感谢<黄朝威>对我的帮助，因为某个具体的事情:爬取数据时总会遇到一些奇奇怪怪的问题，黄朝威总是可以耐心解答我的问题，或是和我一起找出bug共同解决。将爬取到的政策文件签入数据库的任务也主要是黄朝威完成的，可以说没有他我们这个项目的数据就已经寄了。
- <黄朝威>：我感谢 <周浩东>对我的帮助， 因为某个具体的事情: 能够为我详细讲解整个数据库的属性，并在我签入数据时发生错误能够认真聆听我的问题，并耐心地回复我。我感谢 <周伟杰>对我的帮助，因为某个具体的事情: 我在签入数据过程中时常担心没有真正地签入数据，总是拜托他帮我查询对应省份的数据是否正常签入。
学到了什么? 如果历史重来一遍, 会做什么改进?
- 对于不同的人要采取不同的沟通方式，调动大家的积极性，避免成为ddl战士。
2.2.8 总结（4分）
列出组内所有人的心得。
- 吴振溢：下次还是不要做开发做管理又做产品了，人麻了，幸好开发上承担的工作也算比较少，但我也逐渐发现我确实不太适合作为一个管理，不爱去管别人，也不爱去责备别人，把任务发配下去之后除了偶尔问一问什么都不做，效果不算太好。作为产品和开发来说还算合格，但是果然还是更原意做开发，数据大屏做的很开心，效果出来成就感很足，裱起来当传家宝。
- 张乐芃：一开始准备采用最新的前端技术来实现该项目，配环境改源码折腾了不少时间，最后在不断碰壁的情况选择了较为熟悉的技术方案。这次冲刺也算一次小小的复健，太长时间没有碰过vue，感觉在代码编写上熟悉的陌生人，eslint也搞的我痛苦面具。在UI组件库的选择上，跳出了element的舒适圈，采用ant design vue，相比于element，它更为好看，使用上也更服从习惯，蛮不错的。这次也真正的大量使用svg进行矢量绘图，不得不说，svg相比与canvas不依赖于分辨率，还能使用dom，解决了不少绘图上的困难。最后再次感谢一起前端的wzygg，合作顺利且愉快。wzyyyds!
- 潘春佳：本次冲刺中一直处于划水阶段，连ppt都做的不尽人意，希望下一阶段能够多参与，多做点事。
- 蔡树峰：学习要趁早，躺平不能太早。本应该按照某东给的文档学习的，结果却没能完成，感觉拖累了大家。所以在变更角色后，一定要将自己的工作做好，在新的岗位上发光发热。
- 周浩东：知识图谱涉及的知识太多了，不仅仅需要使用众多的工具还要自己定义规则，导入数据以及抽取数据，同时使用不同工具支持的JAVA版本还不一样给我带来了很多麻烦，一一解决后希望能达到让我满意的效果。
- 黄朝威：数据爬取过程异常艰难，数据就摆放在那边在勾引着你，问题是需要仔细考虑好爬取的策略到底采取何种方式能够自动化又便捷爬下来更多的数据，数据爬取下来后尽量过滤处理无用的数据也是个令人头疼的问题，好在爬取文件并非加密，尽管期间遇到过在爬取过程中返回数据提示“政治敏感”，对于部分省份事关国家利益上采取爬取的方式也不尽相同，尽量绕开敏感部分内容，对于部分需要通过加密密钥才能获取的数据采取绕开的方式，尽管数据量会存在一定误差但对于个人人身安全还是非常重要的，其实个人在爬取过程中学习到了非常多的方式，甚至能处理一些比较棘手的问题但对于加密的数据还是选择狗命要紧。
- 林蒋辉：不管是热点词汇还是词频统计，都绕不开全文检索这个东西，算法方面本身就是我的薄弱点，后来找到了solr和elastic search框架的支持，但是他们在网上我没找到傻瓜式的教程，所以只能靠自己安装配置好后，一点点的去摸索测试使用，全部实现下来对自己代码能力会有很大的成长。
- 陈宇扬：这次alpha冲刺中我协助完成数据爬取工作，起初是想用scrapy框架进行数据爬取，但是在爬取广东的数据中发现xpath都正确但爬不出东西，后来发现浏览器规范化会额外加上一些标签，实际的网页源码是没有这些标签的。后来在爬取上海的文件时发现爬取代码需要修改很多地方，普适性不够好。然后决定采用黄朝威的爬取策略，请求网页，爬取政策文件。主要还是摸索爬取过程比较艰辛，中间可能出现很多意料之外的状况。（不想熬夜了.jpg)
- 周伟杰：由于我是零基础，整个开发过程中大部分的时间都花在学习上，虽然花费了大量的时间，直到最后却也只能完成一些基础的代码工作。并且这学期选的课有点多，alpha还碰上俩门考试，属于是地狱难度了。但我也很感谢这次的经历，强迫自己跳出舒适区，让我积累了不少的经验，相必之后都能不断受用吧。
