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

博客领袖链接：https://www.cnblogs.com/GuoHail/p/15586232.html

一、基本情况

组长博客链接：https://www.cnblogs.com/GuoHail/p/15586232.html

现场答辩总结：

现场辩护完全成功。在此之前，虽然我们做了很大的努力，但我们对结果不够自信。曾经，我们认为我们的成绩是所有队伍中最慢的。但是老师的肯定和大家提供的建议让我们很温暖，我们会继续做好“一研定”的工作，最后回馈大家，不辜负老师和同学的期望。经过这个阶段，我们深刻反思了自己的不足：

对于核心功能，用户的具体需求和痛点还没有通过调研等手段提前知晓；

在这个阶段冲刺之后，还是有一些功能没有很好的对接，无法显示。

完成项目所需的能力和知识无法提前了解和学习，具体项目启动时间大大延迟，导致项目进展缓慢；

在人员任务的分配上，虽然有具体的分组，但仍然存在任务分配不均的情况，每个人的时间都没有得到充分利用。

.

我们将完善计划，调整状态，加快步伐，实现剩余功能和界面，尽快交付完整的产品APP。

全组讨论的照片：

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

(全名)

对任务负责

贡献度

郭海龙

组：爬虫数据库

11.5%

李涵

小组：博客PPT

8.5%

湛山

组：前端设计

11.5%

刘玉环

组：前端设计

11.5%

吴朗

组：数据库

11%

王维俭

后端组

6%

谢

组：服务器数据库

12%

宁艺豪

后端组

6%

叶绍文

组：前端设计

11.5%

谢志月

组：前端设计

11.5%

二、总结思考

2.2.1 设想和目标

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

我们的软件主要是给研究生提供夏令营和及时传递高校信息。定义足够清晰。比如夏令营信息，我们主要推送一些985、211的院校，而调剂信息主要集中在一些一本书或者更少的院校。

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

基本达到了目的。实现了及时抓取和推送高校信息、用户关注喜欢的高校等核心功能。在原计划交付时间内交付，达到原计划用户数。

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

用户数量和我们预期的差不多(我们在alpha sprint中预期用户数量达到10个)，用户对重要功能的接受度一般。我们将继续改进我们的功能和界面。我们离目标更近了，但我们还需要继续努力，才能离目标更近。

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

对于核心功能，要提前通过调研等方法分析确认用户的具体需求和痛点。我们忽略了这一点，是因为前期没有重视。如果历史重演，我们将在项目开始前对用户需求进行更详细的调查。

2.2.2 计划

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

是的，在我们开始之前，我们制定了一个相对完整的计划，确定了职能，分配了人员。

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

首先，经过全体成员的集体讨论，我们对方案有了初步的定义(确认共识，搁置争议)，然后根据每个成员的

意向及能力以及项目需求进行了分组，对一些具体问题，各部分成员基于负责部分提出问题并集体讨论。最后由组长进行决议，全体成员遵循。

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

• 基本完成，有一小部分非核心功能未完成。如用户的一些非必要个人信息，理由是不影响核心功能，且时间较短，考虑后决定之后腾出时间继续完善核心功能，第二轮会继续完善。

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

• 有，在用户登入界面的制作上投入了大量人力和时间。到后来发现其实这个部分只需要一个人来完成即可，多人一起做的效率反而降低了，由于没有交流好，大家的工作做了许多重复之处。

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

• 没有，我们初次合作完成项目，没有清晰的考虑到这一点，因此在工作协调上确实存在一些问题。

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

• 整个项目进程是按计划进行的，出现的重大意外是在答辩的前一天晚上发现各小组的成果不能打包在一起，最后熬夜解决了这一问题。沟通问题是开始没有注意到的，也导致了各小组之间的对接问题，可能是因为大家都过于信任彼此，认为各部分都会做出理想的效果。

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

• 有留下缓冲区，缓冲区给我们提供了最后一刻完成app打包的时间，有很大的作用。

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

• 我们的线下编程活动会从两天一次缩减为一天一次，加班完成剩下的任务，争取把剩下的时间留给缓冲区，以应对意外的出现。同时在人员任务分配上，我们根据上一阶段的考虑，我们会做出一些调整。最后就是加强各小组之间的沟通，以免重蹈覆辙。

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

• 一定要在任务开始前做出周详的计划，并且要留出缓冲区应对意外。如果历史重来一次，我们在项目开始之前会特别召开一次会议，制定好计划，然后严格按计划执行，同时也要让每个小组做好沟通。

2.2.3 资源

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

• 有足够的资源完成各项任务，如前端需要的学习资源及做项目需要的资源，爬虫组需要的网上信息。针对各部分所需要的能力，各成员及时进行了学习。

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

• 每项任务所需的时间视具体难度来定，其他资源的分配由需要者自行获取，团队提供所有能提供的资源，精度不错，大都可以满足任务需求。

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

• 我们在这一阶段只进行了简单的测试，其他测试将在全部功能实现后再进行。对于不需要编程的资源，美工方面我们还没有开始具体的优化，文案和PPT的设计还是在能力之内，没有太多难度。

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

• 有的，因为我们队内有六边形大佬，所以许多事情由他来做会更有效率，但是这样就不能让全体成员一起进步，获得制作软件的经验。还是大家共同合作完成任务为宜。

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

• 对完成项目所需要的能力还要提前一些进行了解和学习，早一点开始具体项目，在完成过程中继续学习。虽然我们这次基本完成了计划，但时间确实有点赶，如果历史重来一遍，希望更早开始。

2.2.4 变更管理

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

• 我们有每周的两次例会，由组员轮流进行每次会议的记录和总结，再加上群内交流，所有人都能及时获取变更消息。

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

• 根据交付剩余时间、各部分完成及对接情况、是否影响核心功能等标准进行判定，并再例会进行讨论和决定。

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

• 项目完成的出口条件我们有比较明确的定义，即达到了预期功能，存在bug可以先通过，后面再debug。

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

• 可以。由于我们有借了一间会议室，距离大部分成员的宿舍都很近，可以立即召集大家举行临时会议进行商讨，制定应急计划。比如在答辩前一天，我们就举行了应急会议，保证了产品功能的准时实现。

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

• 可以。虽然大家都没有软件工程的经验，但是学习能力很强，可以在短时间内处理意外情况。

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

• 学到了要有应对意外的心理准备，在意外发生时要尽快交流，达成共识并做好解决措施。如果重来一遍，会对一些可能出现问题的部分做好备用计划并预留时间。继续保持组内的随机应变能力。

2.2.5 设计/实现

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

• 有合适的时间和人，设计工作在工作开始前，由大家商量后，经过用户需求的考量，由队长决定并设计。

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

• 有，在对我们推送的院校保研和调剂信息是采用直接爬取网址，还是处理分析数据后再展示给用户，我们比较纠结。经过切实的考虑后，我们决定先从简单的开始做，先以爬取网址的方式来制作，如果有时间我们再进行数据分析。

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

• 有使用过UML。这些工具有效，但是由于时间紧迫，我们没有太多使用。

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

• 一样。我们的项目目标和框架和开始一致，没有更新UML文档。

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

• 在爬取各高校网页时，会出现html返回正常，但解析出来的列表长度为0的bug，可能是因为浏览器对html文本进行规范化，导致解析失败。我们在设计阶段时并没有掌握有关爬虫的知识，所以上手后有一定的知识空白。

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

• 我们在这一阶段还没有进行代码复审。

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

• 在设计阶段要对项目有一个明确的方向，还有就是bug是无处不在的，我们不能完全消灭它们，但是应该尽力减少。写代码的时候应该有一个程序员的素养，执行不同语言的规范。如果历史重来一次，我们会严格执行代码规范，这样不仅会让我们的代码显得非常专业，也可以让其他队员阅读时减少压力。

2.2.6 测试/发布

1.团队是否有一个测试计划为什么没有 是否进行了正式的验收测试

• 有测试计划，我们从前端小组，后端小组和数据库小组中各挑选了一名队员组建测试小组，预计会在下一轮的冲刺结束后进行正式的验收测试。

2.团队是否有测试工具来帮助测试

• 暂时还没有，在最终验收测试时我们会商讨使用哪些测试工具来帮助我们测试。

3.团队是如何测量并跟踪软件的效能的从软件实际运行的结果来看，这些测试工作有用么应该有哪些改进

• 我们还没有进行测试工作，这一点我们会在下一轮的冲刺结束后来完成。

4.在发布的过程中发现了哪些意外问题

• 意外是我们由于各小组的对接问题，是在答辩前一天晚上才进行打包发布的，一位队员是极短的时间内现场学习的app打包方法。

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

• 测试是非常重要的，我们最终出现了对接上的重大问题，如果早先测试，也许就不会出现。如果历史重来一次，我们会把测试工作提前到这一阶段末尾，同时也要加强各部分的交流。

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

1.团队的每个角色是如何确定的，是不是人尽其才

• 根据项目各部分的功能需求、各成员的能力及喜好进行了分组，大致分为前端、后端、数据库、爬虫四个部分。基本做到了人尽其才。

2.团队成员之间有互相帮助么

• 有相互帮助、各部分组内大击会一起交流学习，资源共享。团队之间有谁需要帮助大家都会尽力去帮助，一起解决问题。

3.当出现项目管理、合作方面的问题时，团队成员如何解决问题 每个成员明确公开地表示对成员帮助的感谢 。

• 这个问题应该主要是出现在各部分的对接之中，如前后端的对接、爬虫与数据库的对接、数据库与后端的对接。出现问题时大家会一起在会议上讨论，在工作中大佬们对整体工作会对整体工作进行说明（即对接时所需要做什么），起到了很大的帮助。总之，互帮互助，有事讨论，解决问题。队员进行互相交流来解决问题，在开会时就共同讨论来商讨方案，在宿舍时就通过线上沟通来解决。

• 郭海龙：我感谢其他九位成员对我的帮助， 因为某个具体的事情:
  万事开头难，第一次担当小组长，带领这么一个团队相当没有经验，一种摸不着头头脑的体验感：你不知道该如何前景规划，你不知道该如何分配任务，你不知道该如何push组员。很感谢我的队友们，带着我一步一步不断学习，不断进步，我们的团队也不断成长，不断进步，慢慢去调整、去优化、去挑战！

• 伍浪：我感谢谢文灏对我的帮助， 因为某个具体的事情:
  在前期我对于我该如何进行具体工作产生迷茫时，他回答了我的疑问让我确切了自己所负责部分该如何去学习和实现。
  伍浪：我感谢李涵对我的帮助， 因为某个具体的事情:
  在我被软工折磨的死去活来时，是他在我闲暇之时陪在我身边，让我缓解压力，能够以更饱满的精神和跟良好的心态。

• 汪炜剑：我感谢伍浪对我的帮助， 因为某个具体的事情:
  他总是耐心地给我答疑解惑，并且也很好地督促了我学习新知识。

• 刘雨欢：我感谢谢文灏对我的帮助， 因为某个具体的事情:
  在完成基础的前端界面,因为知识的匮乏,与后端的接口不知道如何加进去,他主动将这方面的任务承担,代码是我们在网上找的修改,大部分的代码我们也看不懂,他需要额外花时间读懂代码,这些我们前端的同学感谢他的帮助。

• 叶绍文：我感谢宁乙浩对我的帮助， 因为某个具体的事情:
  在完成软工实践的过程中，每当我遇到困难停滞不前时，我的舍友宁乙浩都会给予我积极乐观向上的鼓励，让我可以用一种良好的心态面对困难，所以在此我感谢宁乙浩对我的帮助。

• 谢文灏：我感谢叶绍文对我的帮助， 因为某个具体的事情:
  在我没有思路的时候，更叶绍文进行沟通交流后，我获得了许多灵感。

• 宁乙浩：我感谢谢文灏对我的帮助， 因为某个具体的事情:
  他在我遇到困难的时候能够激励我，给与我鼓励，他积极向上学习的态度与精神给我很大的激励。

• 谢之越：我感谢詹珊，刘雨欢，叶绍文对我的帮助， 因为某个具体的事情:
  他们对任务态度端正并且在前端任务上完成出色，在前端学习为我分享了许多学习资料，让我学习到了许多前端相关知识。
  谢之越：我感谢郭海龙对我的帮助， 因为某个具体的事情:
  他是一个很负责的人，在我们小组每一次会议中组织规划好需要完成的任务，带着我们团队前行，对我的帮助很大。

• 詹珊：我感谢谢文灏，刘雨欢对我的帮助， 因为某个具体的事情:
  此次alpha冲刺我负责的是前端界面的实现。由于之前只在结对编程中接触过微信开发者工具来实现前端，但此次做的是一个app，加上团队讨论之后决定采用vue来做前端的框架，实在是从未接触过，只好从头学起。还好有大佬谢文灏同学在群里分享了vue的速成学习视频，后来刘雨欢同学又在群里分享了uniapp插件的使用方法，让我在学习的过程中少走了很多弯路。不仅仅是他们两个，在此次的alpha冲刺中，每一个队员都给了我很大帮助，十分感谢。

• 李涵：我感谢郭海龙对我的帮助， 因为某个具体的事情:
  在此次alpha冲刺中，我们亲爱的队长在百忙之中还是组织好了每一次会议，甚至有早上出门，到了第二天凌晨才能回到宿舍的情况，以及他用每次用温柔的声线和我们对话的声音，依然在我脑袋里余音袅袅，我非常感谢队长的负责，为这一个团队做出的所有贡献，他就像是我们团队的脊柱，支撑着我们前进，承载着我们的精神。
  李涵：我感谢谢文灏对我的帮助， 因为某个具体的事情:
  我很清楚文灏大佬是我们团队的核心，名义上他属于后端小组，但是对前端和数据库都做出来卓越贡献，在后端组更是一个人撑起了一片天，他就像是我们团队的大脑，没有他我们行将就木，有了他我们运筹帷幄决胜千里。
  李涵：我感谢伍浪对我的帮助， 因为某个具体的事情:
  伍浪是个开朗的哥们，在每一次会议中都积极发言，在答辩演讲中也表现的非常优秀，同时也能关心队员，对队员之间的沟通和工作对接也起到了一定作用，他就像是我们团队的口舌，能说会道，鼓舞我们的士气，述说我们的故事。
  李涵：我感谢詹珊，刘雨欢对我的帮助， 因为某个具体的事情:
  她们是学习能力最强的两人之二，在前端的学习中，她们总能最快的学习知识，做出预想的成果，她们勤劳又智慧，如同我们团队的双手，兢兢业业，战必胜攻必取。

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

• 人和大于天时与地利，团队的和谐是最重要的，大家齐心协力朝着一个目标努力，就能无往不胜。如果历史重来一遍，在这一点上我们做的很好，不需要回到过去。

2.2.8 总结

• 郭海龙：
  最大的感触就是沟通，小组的沟通是最大保障。沟通得好，任务进展顺利；沟通不及时，可能分工停滞不前甚至出bug。其次就是学习，及时的快速的学习能力，对于软工项目来说有质的提升。最后感谢我得队友们，大家相互进步相互成长，渐渐熟悉彼此，默契彼此！

• 李涵：
  在这一段时间内，我学习了很多知识，包括数据库，Java，js等，也和大家度过了劳累又愉悦的一天天。虽然我主要负责文书类的工作，但是陪着大家也了解到了软件开发各个分组的流程，收获满满。

• 伍浪：
  1，第一阶段主要负责的是数据库部分，将前端爬取的数据存入建立的数据库，中间用到了数据库课学习的一些知识，学习到了许多新知识。
  2，做事情不要拖拉，提前做好计划，然后抓紧时间执行，这次团队作业，前期学习阶段划水了比较久，影响了后续工作，以后要好好吸取教训。
  3，团队交流是非常重要的，在工作中出现过由于对接问题出现无用功。

• 汪炜剑：
  这次冲刺让我学到了很多知识，也意识到自己的很多不足。从理论到实际工作的完成并不容易，很感谢成员们的付出，我也要努力赶上他们的步伐。

• 刘雨欢：
  上一周的alpha冲刺一周的时间都很焦虑,从一开始确定自己加入前端,一开始我也花了大量的时间去学习Android开发的相关知识.我们组都是小白,没有一个指导我们从哪里开始,前端的框架使用哪个,在第二周的答辩时,听到很多组都使用vue框架.我就向大家建议先学vue吧,在看B站视频的时候发现HBuilderX和uniapp很搭,里面有插件市场可以用,我们的前端界面大部分是从插件市场中找到使用的,在使用的过程中，也遇到了很多不懂的,两个组件放在一起就不行,往往令我很崩溃,在这个过程中,又发现UView也是一个很好的框架,里面有很多可以直接用的,但我们已经用uniapp写了主界面.Uview的现成的界面更精美,但我现在是不太敢和队友说使用Uview如果我们后续加入Uview不知道前面做的能不能整合到一起,写后端接口的同学可能会崩溃。就到目前为止，我们前端小组的氛围都是互帮互助，上一周我们大家基本上都有考试，在我有数学建模考试的那两天，另外两位同学考完了。他们俩主动接过一部分任务继续完成。这一段时间最大的遗憾是，没有一个指导我们方向的，大家都是小白，在摸索中学习，一开始界面分配没有做好，我们页面的完成是串行的，所以导致进度很慢。

• 叶绍文：
  在软工实践的过程中，我碰到了很多的困难，绝大部分的知识都是现学现用，因此花费了挺多的时间。但付出与回报是成正比的，我也从中收获了很多，希望以后能够学到越来越多有用的知识吧。

• 谢文灏：
  大家一起努力就能取得意想不到的成果。

• 宁乙浩：
  经过这段时间，我认识到了开发一个app所需要的流程，知道了自己的不足。队友们都非常的给力，而且能够认真的做好各自的任务。这段时间我由于比较薄弱的编程能力，就在学习java，努力的提高自己的编程能力。

• 谢之越：
  在本次团队作业中我学习了很多关于前端的新知识，并且了解到了软工的各个过程的流程。其实软工理论中，并没有规定那么具体每个人要如何编程，这都需要我们去亲身实践，亲身尝试，这也再次印证了软件工程是一门需要实践的学科。最后，虽然开发过程中遇到不少困难，但我真的很高兴能与团队做出一个项目。

• 詹珊：
  在本次的alpha冲刺中，经历了视频学习vue、uniapp文档了解、上手实现界面的阶段。但也确实由于之前没有接触过vue以及uniapp，上手比较困难；同时，对于插件的使用也不够熟练，还经常碰到一修改就出现大量bug的情况；此外，就是界面的整合部分，和队友共同实现了一个界面的不同部分，但是整合在一起容易出现界面覆盖以及比例失调的问题。这些都是在此次alpha冲刺中碰到的困难。此次alpha冲刺前端界面确实实现得不够理想，还有很多地方有所欠缺，这也导致整个项目进展缓慢。我也会吸取此次alpha冲刺的教训，希望可以在β冲刺中做得更好！