10组-Alpha冲刺-总结

第10组-阿尔法冲刺-总结

【组长博客链接】(https://www.cnblogs.com/jimase/p/15585897.html)

#一、基本信息

# #现场答辩总结

1.项目总体进度充足。

2.我们应该更深入地挖掘大量爬下来的数据的潜在意义。

3.在柯先生的建议下，减少数据清理的次数，提高清理质量，进一步挖掘抓取数据的内在含义。数据分析结果的呈现要更加谨慎。

4.如同学建议，可采用更先进的数据分析方法，具体列举如下：

！[](https://img 2020 . cn blogs.com/blog/2529387/202111/2529387-20211121210812529-1424156443 . png)

# #整个小组讨论的照片

！[](https://img 2020 . cn blogs.com/blog/1925087/202111/1925087-2021112193623683-1379897524 . png)

# #本次作业贡献率评估

|成员姓名|本次分配的具体工作|贡献度|

| - | - | - |

|苏|团队选题报告PPT审核及博客撰写|25%|

|林则西|修改报告完善需求分析|7%|

|黄船歌|报表排版处理|7%|

|陈|成果展示与整理(答辩)|12%|

|陈硕|成果展示和整理(用于国防)|7%|

|翁敏|PPT制作|9%|

|史志斌|统计团队成员的经历和感受|7%|

|林|统计团队成员感受|9%|

|王一平|原型设计，类图排列|10%|

|唐金婷|修改报告完善需求分析|7%|

# #工作流程

-此操作的工作流程

——受疫情和大家差异的限制，我们选择github是为了认同大家的工作进度。带有开发分支的Git功能分支工作流是开发团队中最流行的工作流之一。它类似于Git功能分支工作流，但它的开发分支与主分支并行存在。在此工作流中，主分支始终代表生产环境的状态。

！[](https://img 2020 . cn blogs.com/blog/2529387/202111/2529387-20211121210501267-1627322245 . png)

-特定于数据分析阶段

！[](https://img 2020 . cn blogs.com/blog/2529387/202111/2529387-20211121210658923-1065060691 . png)

# 2.总结思考

### 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.对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则 请列出具体的事例。
- 团队合作，每日互动：业务人员与开发者在项目进行中，必须每天一起工作。
- 事例：我们组内几乎每天都会在群里讨论学习，进行一定的进度报告和互动。
- 持续交付，小步快跑：经常交付可用的软件（系统），频率可以从数周到数月，以较短的时间间隔为佳。
- 事例：在组内的每个小队中，都会把工作分成一部分一部分去进行。例如前端小队中：实现页面，实现与后端对接，实现搜索功能。等等，交付的页面每次都有功能的新添加。
- 精简产品，杜绝浪费：精简——精髓是要尽最大的可能，排除不需要做的工作
- 事例：之前一直讨论的闹钟提醒定时吃药功能被摒弃了，原因是手机都会自带闹钟功能，若硬加功能，有点画蛇添足。