组长博客链接

一、基本情况

现场答辩总结

1. 项目总体进展充分
2. 应该更深度地去挖掘爬取下来的大量数据潜在的含义
3. 在柯老师的建议下、降低数据清洗的数量的同时提高清洗质量并且更进一步挖掘爬取到的数据的内在含义。对待数据分析结果的呈现应该更加谨慎。
4. 经同学建议、可能会采取更前沿的数据分析方法、具体枚举如下：
   

全组讨论的照片

本次作业贡献比例评估

成员名	本次作业具体工作	贡献度
苏伟煌	团队选题报告PPT审核、博客撰写	25%
林泽熙	修改报告、完善需求分析	7%
黄艇淞	报告排版处理	7%
陈本源	成果展示整理（答辩用）	12%
陈硕	成果展示整理（答辩用）	7%
翁敏	PPT制作	9%
石致彬	统计组员心得感受	7%
林志煌	统计组员心得感受	9%
王毅萍	原型设计制作、类图整理	10%
唐劲霆	修改报告、完善需求分析	7%

工作流程

• 本次作业的工作流程
• 受限制于疫情和大家各自不同、我们选用github来同意大家的工作进展带有 Develop 分支的 Git 功能分支工作流此工作流是开发团队中比较流行的工作流之一。它与 Git 功能分支工作流相似，但它的 develop 分支与 master 分支并行存在。在此工作流中，master 分支始终代表生产环境的状态。
  
• 具体到数据分析阶段
  

二、总结思考

2.2.1 设想和目标

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

   我们的软件需要收集药品的数据，对药品的价格进行分析可视化，尽量让药品的价格信息变得透明。目前来看，我们的定义主体上还是比较清楚地，边界比较明显。对于典型用户和典型场景也有比较清晰的描述。

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

   我们的目标大部分完成了，还剩下一些部分需要进行完善，原计划的功能基本都完成了，比如要求的数据的爬取，前端的可视化图展示等。目前还没有进行部署，用户数量为0，暂时没达到原计划用户数量

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

   用户量目前为0因为还没部署到服务器，和我们预先设想的暂时不一致，用户对重要功能的接受程度因为还没上线暂时无用户所以还无法调查，但是我们小组成员在进行运行时大部分功能实现的效果还行，我们认为我们正逐渐在靠近目标

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

   会将分工进行细分，具体职责分配到位，以提高开发的效率，推进项目进程。并且要适当提高开会的频率，跟进项目的进度。

2.2.2 计划

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

   是。虽然有许多组员课程很多考试也很多并且都挤在一块了没什么时间，但是也有几个组员时间较为充裕且愿意为小组花时间来做一些规划。

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

   团队成员意见不统一时，我们会多征求意见，集中思考解决方案，尽可能得到一个总体上大家都能接受的结果。团队成员大家都可以相互理解相互体谅，因此也没有出现不可解决的矛盾，大家都能和气地商量解决

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

   没有全部都做完，因为大部分人都需要从头开始学习，学习成本很高，再加上其他课程的学习和考试，导致最后在项目开发的时间较少，暂时没有全部完成所有功能的具体实现

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

   有。主要是爬取时候的技术方面。

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

   是，每一个任务都有最少完成的指标。

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

   不是都按照计划进行，出的意外就是服务器配置太过垃圾，而且没有估计到的一个风险是流量消耗太快，因为以前没有过服务器的使用经验所以没预估到

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

   有。缓冲区可以让项目更有容错率，虽然不能搞定所有但是至少能在ddl前解决一些问题

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

   将来的计划就是组内大家再冲一波，加个班，在ddl前尽最大努力完成

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

   学到了在项目过程中分工明细很重要，如果再来一遍会更加细致地进行分工，设置好各个部分的负责人，共同推进项目的进展

2.2.3 资源

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

   有，人力物力都有基本保障。

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

   所需时间和其他资源是根据分配的任务量以及与对应的任务负责人所商量的结果来估计的，精度到以天为时间单位

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

   测试的时间和人力和软件/硬件资源较为足够，大家都会尽量挤出时间来进行测试，我们小组人数也够，开发所需的软件硬件资源也是有的。对于那些不需要编程的资源没有低估难度，都会指定一个人来负责

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

   没有，我们的给每个人分配的任务都是尊重个人意愿且衡量过个人能力来进行分配和调整的

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

   我们应该加强时间观念，还有对项目进展的跟进。再来一遍的话要改进管理方式，多多注意项目的进展，不浪费一分一秒

2.2.4 变更管理

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

   是的，我们一旦有了变更都会通过腾讯会议来进行通知每一个人

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

   根据我们项目需要实现的最基本功能来决定，必要的先做好，锦上添花性质的功能就是在先做完基本要求的前提下再谈

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

   有，就是在前端能够展示出我们想要的数据图表

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

   能，小组会积极地进行会议，集思广益指定应急计划。

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

   是的，组员都很尽力，即使熬夜也会尽量完成

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

   一开始指定计划的时候应该尽可能的考虑充分，让计划尽可能的周全，最大限度地避免在项目的进行过程当中做变更，也应该做应急方案，以防万一。

2.2.5 设计/实现

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

• 设计工作从Alpha之前的一两星期就开始准备了，设计人主要是由苏伟煌组长为核心，其他组员提出自己的建议。
• 是合适的时间，和合适的人。

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

• 有过。
• 在设计的过程中，例如前端的页面设计中，和原型图略有出入。解决方法：有问题的人在内部沟通，尽量求同存异。如果还有疑问的话，则找其他组员，少数服从多数。

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

• 有利用过单元测试（unit test）来测试后端的接口是否能够使用。

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

• 有一定的区别。
• 原因在于，在项目开始时，可能因为考虑不周全，现在会增添一些细节。还有就是因为之后开发时候，因为发现技术能力有限，放弃了一些功能。
• 是应该更新 UML 文档。

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

• 在跳转页面的时候产生的bug最多。
• 主要是因为代码之间函数的运行顺序出了一点问题。所以一直再改。
• 发布之后并没有发现什么重要的bug。
• 在设计的时候，由于时间问题和对设计相对于不太重视的原因。

6. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
   • 由组内大佬审查，严格执行了代码规范。并建议其他组员如何修改自己的代码。
7. 学到了什么? 如果历史重来一遍, 我们会做什么改进?
   • 设计对于后续的开发工作时有很大的帮助的，会减少走弯路的时间。不是题目一拿来就开始敲代码的。
   • 改进：对开发会更加注重设计，尽量做到兼顾一些细节问题。

2.2.6 测试/发布（3分）

1. 团队是否有一个测试计划？为什么没有？ 是否进行了正式的验收测试？
   • 有一个测试计划，由前后端共同测试。进行了非正式的验收测试。
2. 团队是否有测试工具来帮助测试？
   • 有，我们利用postman来测试接口
3. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
   • 测试软件是否能够正常运行，是否能够搜索出正确的结果。运行速度如何，正确性如何。
   • 有用
   • 运行出来的结果应该更加优化一下界面，提高用户的体验感。
4. 在发布的过程中发现了哪些意外问题？
   • 在发布的过程中，我们只在web端部署了一下，因为考虑到相关政策、只允许查询基本的功能。在后续我们会根据发布体验进行优化。除了这个，暂时没有其他问题。
5. 学到了什么? 如果历史重来一遍, 会做什么改进?
   • 在软件的开发的过程中，软件测试是极为重要的。即使是测试过很多次后，仍可能会出现很多问题。这需要我们不厌其烦的测试。
   • 改进：更加花时间地去测试。

2.2.7 团队的角色，管理，合作（3分）

1. 团队的每个角色是如何确定的，是不是人尽其才？
   • 每个人先表明自己已经基本掌握的技术特长。再根据团队项目的根本需求来决定每个人该做什么，该学什么。最后确定团队的每个角色。
   • 是人尽其才。
2. 团队成员之间有互相帮助么？
   • 自然是有的，无论是前端还是后端，还是其他小组。在开发过程中，遇到自己实在解决不了的问题，都会进行讨论研究。
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？ 每个成员明确公开地表示对成员帮助的感谢

• 苏伟煌：我感谢陈本源对我的帮助,在他的提示下想到了用抓包工具在手机端尝试爬取药监局的药品名称数据。也完善了一些小细节
  • 学到了什么?
    学到了fiddler的简单使用
  • 如果历史重来一遍, 会做什么改进?
    如果alpha冲刺阶段重来、应该会在爬取的时候讲爬取药品数缩减到十分之一、讲具体药品的信息条爬取数量略增、减少大家工作量的同时也能缩减繁琐的数据清洗。
• 林志煌：我感谢苏伟煌组长对我的帮助,在他的帮助下，我学会了echarts的基本使用方法。能做出一些简单的数据可视化界面。
  • 学到了什么?
    学会了echarts的基本使用方法
  • 如果历史重来一遍, 会做什么改进?
    如果alpha冲刺阶段重来，我一定会好好学习，不至于每种东西都是只涉及一点点，只会一点点，这样就不用麻烦其他人帮助我一些简单的问题了。
• 翁敏：我感谢苏伟煌组长和王毅萍同学对我的帮助,在她的帮助下，我学会了vue的使用及搭建一些基本的网站框架。
  • 学到了什么?
    vue的入门及搭建页面
  • 如果历史重来一遍, 会做什么改进?
    如果可以重新来遍，我会在九月初课程还未很忙的时候好好学习技术为后面做铺垫，还是没有好好珍惜时间，没有抓紧时间学习新的技术，比如vue框架别人都可以熟练运用构建界面了，自己还只是个入门小白状态，重来一遍，一定珍惜时间学习。
• 陈本源：我感谢黄艇淞对我的帮助,在他的提示下想到了用fake_useragent解决反爬问题。也完善了一些小细节，感谢苏伟煌组长合理的任务分配，与任务进展节奏，以及很多good ideas,跟着组长的脚步不慌不燥。
  • 学到了什么?
    加强了爬虫能力，突破了防爬取能力
  • 如果历史重来一遍, 会做什么改进?
    重新选择性价比较高的数据进行爬取和处理
• 陈硕：我感谢苏伟煌组长对我的帮助,在他的帮助下，我学会了如何将数据可视化美观，能做出一些相对还行的可视化结果，也感谢林泽熙的帮助，能和他一起做出可视化结果及爬虫。
  • 学到了什么?
    学会了python数据可视化
  • 如果历史重来一遍, 会做什么改进?
    如果alpha冲刺阶段重来、应该会更加努力学习爬虫相关知识来帮助团队。
• 黄艇淞：感谢陈本源对我的帮助,在他的提示下想到了用downloaddelay解决淘宝和京东的反爬机制。也完善了一些小细节，感谢组长合理的任务分配以及很多灵感。
  • 学到了什么?
    熟练了对于各个爬虫框架的使用
  • 如果历史重来一遍, 会做什么改进?
    对于各个网站用不同的爬虫进行爬取
• 石致彬：我感谢苏伟煌同学对我的帮助,在他的帮助下入门了后端开发，学会了使用Java操作数据库以及用springboot框架进行简单的接口编写
  • 学到了什么?
    学到了spring boot的简单使用
  • 如果历史重来一遍, 会做什么改进?
    如果可以重新来遍，我会在前面比较轻松的时候好好了解并且学习所需要用到的技术，好好珍惜时间，抓紧时间学习新的技术，比如spring boot框架。现在还只是一个入门阶段的小白
• 林泽熙：我感谢苏伟煌组长的勤勉工作,在他的帮助下，我学会了如何去做好一个团队的部分，学习了很多课外却有用的知识，也感谢陈硕同学的合作。
  • 学到了什么?
    学会了echarts的基本使用方法
    学会如何爬取大量的复杂数据
  • 如果历史重来一遍, 会做什么改进?
    如果alpha冲刺阶段重来，我会争取做更多的工作，学习更多的知识，认识更多实用的工具
• 唐劲霆：我感谢苏伟煌同学对我的帮助，在他的带领下团队工作有序进行，也感谢他带领我一起学习数据可视化等知识，同时感谢其他所有组员为团队做的贡献。
  • 学到了什么?
    学会了数据可视化。
  • 如果历史重来一遍, 会做什么改进?
    要是能重来，我要提前分配好时间，因为考试和alpha冲刺时间重了，所以复习考试花费了较多时间。
• 王毅萍：感谢组长在工作分配上花费的心思，让大家能专心做自己的工作。感谢各位组员们的积极配合，让工作得以有序推进。
  • 学到了什么?
    再一次被“没有大致的规划就很难高效率地完成工作”这一点所痛击。总之就是更深刻地认识到“工程”的重要性，对自己的能力和短处有了更清晰的了解。
  • 如果历史重来一遍, 会做什么改进?
    做好规划！！！时刻提醒自己当下哪些事一定要先用最快的办法解决。

2.2.8 总结（4分）

• 苏伟煌：
  1. 应该戒骄戒躁、莫诉无用之苦
  2. 应该多开会、合理分配工作量
  3. 不要急于开工
• 王毅萍：
  1. 规划是重中之重
  2. 要静下心做好工作设计
• 唐劲霆：
  1. 调整心态，多接受。
  2. 多学习，多交流，学习其他同学的优点。
  3. 合理分配时间。
• 林泽熙：
  1. 学习知识应该有深度，只是片面的学习会在遇到困难时寸步难行
  2. 自己有很多不如他人的地方，需要增强自己的个人能力
  3. 团队合作至关重要，好的团队能有1+1＞2的效果
• 石致彬：
  1. 努力学习，多花时间
  2. 应该多加强与其他成员的沟通，多多听取他人的建议和意见
  3. 调整好心态
• 黄艇淞：
  1. 做好完整的规划在进行爬虫，提高效率
  2. 早点开始学习数据分析方面的知识
• 陈硕：
  1. 要加强团队沟通能力。
  2. 认识到了自己的不足，知道了许多要学习的东西。
  3. 要多了解其他成员负责的工作，从中能学习到很多新东西 。
• 陈本源：
  1. 应该多和他人讨论，做好完整的规划在进行爬虫，以免造成资源浪费
  2. 应该早些时候开始了解pyechart,也就不会学的很匆忙
  3. 多听取他人意见
• 林志煌：
  1. 应该学习全面，不能只是涉及。
  2. 认识到了自己的不足，今后应该补缺补漏。
  3. 凡事要循循渐进，不能刚开始就想马上完成，最后什么也做不出来。
• 翁敏：
  1. 珍惜时间，充分学习。
  2. 学会交流沟通吧，自己性格原本就是偏安静喜欢盲干，但是接受新的思想新的见解就会有新的认识，别人真的很优秀，多沟通可以有新的收获。
  3. 相信自己，不要妄自菲薄，努力就完事了，剩下的时间好好学习吧，不要浪费时间，毕竟大学也快结束了。

全组总结(舍不得删实在是)

• 1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
  • 我们认为目前团队还处于CMMI一级，执行级的档次，因为只有少部分组员以前接触过项目开发，大多数组员都没接触过。还有很大的提升空间。
• 2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
  • 我们认为团队目前处于磨合阶段，但应该很快能达到规范阶段。
• 3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?
  • 最明显的是，团队中每个人的技术能力得到了进一步的提升。团队分工更加地合理明确。项目的基本部分已经实现。
• 4.你觉得目前最需要改进的一个方面是什么?
  • 我觉得现在最需要改进的方面是在规划方面做得更好，以及加上提高用户自身的体验，还有减缓组内浮躁的情绪。
• 5.对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
  • 团队合作，每日互动：业务人员与开发者在项目进行中，必须每天一起工作。
  • 事例：我们组内几乎每天都会在群里讨论学习，进行一定的进度报告和互动。
  • 持续交付，小步快跑：经常交付可用的软件（系统），频率可以从数周到数月，以较短的时间间隔为佳。
  • 事例：在组内的每个小队中，都会把工作分成一部分一部分去进行。例如前端小队中：实现页面，实现与后端对接，实现搜索功能。等等，交付的页面每次都有功能的新添加。
  • 精简产品，杜绝浪费：精简——精髓是要尽最大的可能，排除不需要做的工作
  • 事例：之前一直讨论的闹钟提醒定时吃药功能被摒弃了，原因是手机都会自带闹钟功能，若硬加功能，有点画蛇添足。

标签：学到,10,什么,冲刺,改进,组员,alpha,团队,感谢
来源： https://www.cnblogs.com/TJThunder/p/15586297.html