9组Alpha冲刺总结

一、基本情况

1.1基本情况（10分）：

• 组长博客链接：https://www.cnblogs.com/Microsoft-hc/p/15585517.html

1.2现场答辩总结

• PPT上缺少了组内成员的分工以及完成的各项工作，也算是ppt准备时间太短加上都有课的部分原因，内容不是很完整，也不是很精美。
• 老师所说的与其大而杂，不如小而精的问题确实值得思考，我们接下来就准备去完善做好的游戏，尽量让它精美耐玩。
• 对于同学每次都要捎带的版权问题，也不知道该怎么表述，毕竟这些桌游的知识产权，保护的只是产品的本身，而非产品创意，只要经过一定的创新就不算侵权；再者对于这个不盈利更不推广的产品，我们的初心就是希望这是个让我们能提高自己能力，锻炼自己的机会，把他当做一个作业，而非盈利工具或手段，一直都没跟同学们交代清楚是我们一个很严重的问题。

1.3全组讨论的照片

1.4评估团队中每个人对本次作业的贡献比例，描述为本次作业的工作流程、组员分工、组员工作量比例（禁止一锅端平的情况，如果没有评估，组长得分减 50%）

姓名	成员分工	得分占比
胡驰	登录界面，设置界面，原型设计，博客	12%
张伟鹏	选择游戏相关界面、博客	12%
李霆政	游戏界面的实现、进行博客编写、原型设计	13%
缪恒铭	“璀璨宝石”游戏的界面及逻辑、博客	16%
段新源	“现代艺术”游戏界面、博客	12%
卢浩玮	“现代艺术”原型实现、博客	13%
洪磊	成果展示演讲答辩、现代艺术游戏逻辑、博客	10%
谢小龙	服务器搭建以及后端数据库实现	12%

二、总结思考

2.1 设想和目标（4分）

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

• 随着生活水平的提高，人们现在越来越关注休闲生活中的娱乐方式，桌游于是快速发展，成为了人们空闲时光排解无趣的时代产物，且桌游中涉及的一些博弈也可以锻炼人们的脑力，然而桌游所需要花费的场地，资金等，常常是难以得到满足，在游戏过程中难免也会遇到一些其他不可避免的因素。而且如今市面上所存在的一些线上游戏往往是那些过于常常听说的游戏，例如狼人杀，斗地主，剧本杀等，然而一些经典却好玩的游戏却罕有听闻。
• 针对此问题，我们的产品为人们提供了游戏的新方式，其一是为了解决桌游”不方便携带”，”找场地难”，“买桌游贵”等问题，其二是对一些好玩且高级的小众桌游进行一定的推广，让大家都能对桌游有个更多的了解而不是局限于曾经自己熟知的几款桌游。
• 我们的产品 易科游 致力于让对那些桌游感兴趣，想要玩桌游的人们不再会有空间（如因为人流量过大场地难以找到），时间（时间太晚不愿意出门），价格（性价比稍低不愿意尝试）等因素的束缚，而是可以随时随地的玩上一局紧张刺激的桌游，享受与朋友们酣畅博弈的时光，借此也对桌游进行一定的推广。

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

• 我们暂时还未达到目标
• 原计划是做一个桌游的游戏平台，有好友系统，排行榜功能等，可以承载多款桌游，也给那些热爱桌游的人们提供一个可以进行上传自己做游戏的接口，或者提供联系我们的方式
• 由于前期对整个计划的估算不足，暂时离目标的完成还有一定的距离，也才完成了部分游戏的界面设计和游戏逻辑，但是还是会继续努力的。对于用户数量而言，由于是一次学习性质的我们还暂时未对产品进行推广。

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

• 暂时用户还是团队成员及其他们的同学，朋友等，也还未完整体验我们所开发的产品，不过在已经体验过的功能上，用户还是相对较为满意的。由于前期的错误想法，让我们花费了大量时间，于是出现了离目标越来越远的罕见现象，但是在我们确定了方向，并进行彻夜赶工后完成了基本想法也离目标更近了。

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

• 由于事先对软件的估计不足，野心比较大，想做多款的游戏，团队成员前期将大量时间投入到各款游戏的开发中和平台的构建中，然而认知不足将原来的计划打乱了，由此大量时间被浪费，于是团队成员在最后的期限内赶工，连夜加班，如果历史能重来一，我会跟大家首先花很多时间进行对产品进行一个较为详细且可行的规划，这样才不会浪费太多时间在无用功上，终究是吃了没经验的亏，不过这也是一次非常宝贵的经历。

2.2 计划（5分）

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

• 未用充足的时间来进行计划的制定，这也是将我们团队逼入困境的原因，有了一个血的教训。

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

• 沟通是人与人之间解决问题的重要桥梁，因此我们都是在开会时提出主要问题，然后大家进行一个商讨，直到不同意见的被说服，然而队员们比较佛系，未有过多的不同意见。

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

• 工作目前没有做完。
• 原因：主要是因为时间的不足，其一是大家最近都比较忙有很多考试和作业，无法全身心投入到产品的开发中来，其二则是前期没有进行一个周全的考虑，导致后面项目的完成有了许多无用功，浪费了大量的时间。

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

• 前期计划做得不够完善，组内做微信小程序的工作太久了，导致后面换方案的时候没有太多的时间。（但是从学习方面来讲还是锻炼了自己的能力）

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

• 我们能对项目任务做到尽量具体的分配，尽量交付都每一个小组成员手中，但是对每一项没有清楚的衡量的交付件

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

• 坦白来讲和计划偏差比较大的，中途方案的改变让我们元气大伤，我们当时想象的太过美好了。微信小程序对个人开发者有许多限制，而且小程序代码包限制为 2MB，我们打算在软工课结束后也继续完善自己的产品，也准备适量添加大型桌游，而这个限制就很不友好了，当时也没考虑这么多，就有了一个很大的麻烦。还有就是团队成员们也没有什么开发经验，对于项目的开发需要一步一步地摸索，然而再加上组里的大佬经常有事情，于是组内进度也不是很美好。

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

• 计划中留下了缓冲区，原计划是准备进行组内的讨论，准备对统一的代码规范进行进一步的考察以及前后端的对接，然而没想到最近的考试颇多，无法抽出时间去对这些进行解决，显得作用不是那么大。

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

• 给缓冲区时间留长一点，以防其他没有预料到的麻烦或者突如其来的意外，以前后端对接为缓冲区的主要任务，尽量能更早的完成任务，给自己多一些时间去应对意外。

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

• 最最重要的是学到了要在项目实施前要不惜花大量时间去对项目做一个评估，考虑各个方面的可行性，不至于走弯路，走错路。也学到了想让组内成员能够高效更自觉的完成自己的任务，工作场地是必不可少的，这样可以增加团队的凝聚力和积极性（怎么也是一起因为工作通过宵的好队友），如果历史能重来，一定会在刚开始的时候对各个成员的工作进行个更加具体的安排，这样也能加强责任感，提高效率。

2.3 资源（3分）

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

• 没有，

  经历这次作业，我更加明白了人力和时间资源是多么宝贵，我们组没有相关开发产品的人才，经验的缺失让我们走了不少弯路，也得自己一步一步摸索，效率不是很高，也没有对服务器，数据库搭建有经验或是联网功能实现有经验的人，我们这条路走的异常艰难；然后就是时间的缺失让我们身心俱疲，软工项目成了每天梦境的主导者。

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

• 各项任务的时间和资源是负责相应任务的人员由任务难度，复杂度，任务量进行粗略估计的，准确度不是很高，精确到天，但是也大体能接受。

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

• 主要是人力资源的不够，团队人员做一个这样的项目还是人员太少了，有点后悔没有多找一点人，对于美工方面的设计确实有点低估难度了，对于一个桌游而言，虽说它的主要功能还是游戏的策略，但是美术方面也是同样重要的，有一个游戏给人第一印象就是它的精美程度，这点只能后续不断地进行改进和打磨。

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

• 没有，虽说可能让别人来做确实会提高某个part的效率，为局部最优解。但是作为一个团队而言，本是一个整体，由于木桶效应反而会让整个团队的进度降低。每个人都到了他的相对合适的位置上，才是整体最优解。

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

• 干任何事之前都得做一个预算，不能一顿乱冲，在人员配备方面应该尽量争取到各方面的人才，与整个团队取长补短，相互帮助。
• 得留更多时间来进行缓冲，不然遇到一些突发的情况时间真的严重不足，学习这方面还是得主动，而不是被动，与其说机会留给有准备的人，不如说是机会留给主动的人。

2.4变更管理（4分）

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

• 变更消息会第一时间发布到QQ群里，小组的组员能及时收到变更消息。

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

• 根据功能的重要程度和实现难度，在小组进行沟通后决定功能当前实现还是稍作推迟。

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

• 项目的各个功能能够基本实现并且能够正常运行。

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

• 对于小规模的变更能在群内通过小组内的讨论并制定应急计划，对于大规模的变更我们小组会紧急找到合适的场所进行会议并着手应对变更。

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

• 组员能够尽量有效处理意料之外的工作请求，应为微信小程序的实现难度太大，我们小组讨论后决定将项目做成APP的形式，小组成员能够马上投入工作。

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

• 要做好制定完备的计划，做好充足的准备，尽量按照计划推进项目，避免突然出现大规模的变更。
• 如果历史重来一遍，我们在做项目的计划时，一定会充分考虑项目的难度与实现的可行性。

2.5设计/实现（4分）

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

• 设计工作在α冲刺周时由小组成员讨论共同完成，吸取大家的意见进行，比较合适，但是时间上应该提早。

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

• 设计工作中有碰到模棱两可的情况，比如在一些功能的可行性问题上，团队成员讨论后进行解决。

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

• 团队使用UML来帮助设计和实现。
• 能为团队项目提供清晰的思路，有效提高工作效率。

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

• 项目开始的UML与现在的状态有一定的区别，由于有些实现功能发生了改变，产生了区别，有需要更新UML文档。

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

• 璀璨宝石卡牌预选功能产生的Bug最多，在对战过程中还未亮出的卡牌点击预选后未能响应。

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

• 小组成员互相进行查看，没有严格执行代码规范，如有些命名，注释没有严格执行规范。

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

• 设计工作是整个团队项目前期最为重要的步骤之一，能为项目实现提供清晰的思路，对后续的实现具有重要作用，而严格遵循代码的规范也有助于团队项目的改进工作。
• 如果历史重来一遍，我们会更早开始设计工作，有更多的时间进行项目的实现，在编码过程中制定统一的规范。

2.6测试/发布（3分）

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

• 我们团队暂时还没有测试计划，因为团队任务进度还未到达测试的阶段，所以也没有进行正式的验收测试。

2.6.2团队是否有测试工具来帮助测试？

• 暂时没有测试工具。

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

• 暂未进行达到测试阶段，无法进行测量跟踪软件效能。

2.6.4在发布的过程中发现了哪些意外问题？

• 暂未未发布。

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

• 暂未进行测试和发布，没有从中学到什么，但后续会重视测试工作。
• 如果重来一遍，会尽量加快进度。

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

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

• 在分配工作前让每一位成员表达自己擅长的技术及自己想做的工作，然后小组根据每个人的具体情况进行综合讨论，最后小组进行具体的角色分配，尽量确保每个人都能分配到自己所期望的并且合适的角色。
• 小组分配角色时尽量根据每个人所擅长的方面进行，比如我们组擅长算法的ACM大佬就分配到了后端组，对前端感兴趣的组员也能分配到相应的位置，总体上的分配是较为合适的。

2.7.2团队成员之间有互相帮助么？

• 小组成员经常互相帮助，由于大家都没什么开发经验，尤其是前端方面，需要不断学习，在学习过程中遇到不会的问题，我们小组的成员能够相互交流讨论，互相之间提供帮助。

2.7.3当出现项目管理、合作方面的问题时，团队成员如何解决问题？ 每个成员明确公开地表示对成员帮助的感谢 （汇总至组长博客）：

• 缪恒铭：我感谢<胡驰>对我的帮助，因为之前没怎么接触过这些桌游，对规则有很多不懂的地方，都很耐心的为我讲解；另外在我与队员的认识、沟通上，组长都充当了一个媒介人物，对我熟悉 队伍其他成员提供了很大的帮助。

• 卢浩玮：我感谢<缪恒铭>对我的帮助， 因为某个具体的事情: 在编写需求分析报告博客时间紧张时，帮我分摊了uml图的绘制，也提供了思路。

• 洪磊：我感谢<胡驰>对我的帮助，作为组长他为组员分配任务，安排各项工作和事情，为大家操劳，帮大家找学习资源。

  我感谢<缪恒铭>对我的帮助，我不熟悉unity的某些语法和操作方式时，他教了我很多，也从他的代码里学习到了很多脚本的设计。

• 张伟鹏：我感谢<缪恒铭>对我的帮助，在学习unity前端知识的时候，我没有好的资源进行学习，他给我分享了很好的视频资源进行学习，提高了我学习的效率。

• 李霆政：我感谢<兄弟们>对我的帮助，因为我是第一次进行这种开发，很多不会的，我和胡驰、伟鹏、新源，一起探索前端的开发，在后面转unity写游戏之后，因为刚开始学习，使用不是很熟练，对于脚本的使用也是一脸懵逼，然后浩玮、恒铭会很好的帮助我去熟悉unity的使用，脚本的操作。磊哥会指导我的算法设计，小龙一起研究网络接口的操作。

• 段新源：我感谢<缪恒铭>对我的帮助， 因为某个具体的事情: 给我unity界面开发相关的视频，指导使用unity。

• 谢小龙：我感谢<李霆政>对我的帮助，再从新学习unity制作项目的学习中，李霆政同学告诉我了学习的流程，让我知道了学习的重点，并少走了许多弯路。

• 胡驰：我很感谢<缪恒铭>对我的帮助，在我们准备转用app方案时，刚学unity的我还有很多地方不会用，缪恒铭给我们找了b站上价值很高的视频教程，让我短时间内学会了unity和c#一些基本使用方法，在具体的编写代码中也帮助我解决了很多困难。

2.8总结

• 缪恒铭：因为一开始的决策失误，团队走了很多歪路，导致我们最近几天比较肝；由此我感受到，团队规划是很重要的，不能走一步想一步；在开发过程中，有自己的想法不要藏着，要养成与队友分享的好习惯；乐于帮助队友，这样当你需要时队友也会帮助你。

• 卢浩玮：在alpha冲刺中，学到了很多有用的知识，同时也让我意识到，目前掌握的知识还是太少，要多学习。本次alpha冲刺中最大的感触就是沟通，小组的沟通是最大保障。沟通得好，任务进展顺利；沟通不及时，可能会导致各种各样的问题，对于项目的运转有着极大的影响。

• 洪磊：在这个冲刺周期，学了很多也做了很多，中途调整之后，为了赶进度，大家选择线下集中一起写代码。在一起熬夜奋战的过程中感受到了，软工开发的氛围（也稍事担心一下大家的身体）。各种突如其来的问题干扰了本身的时间安排和计划，或许也学到了以后要做好进一步的规划和规避风险的准备。

• 张伟鹏：这次alpha冲刺周时间真的很紧张，总体下来我的感受就是累，因为每天都在不断学习新的知识，同时还要面对考试的压力，不过每天都能有收获，还是很充实的。通过这次冲刺我深刻体会到了“笨鸟先飞”的重要，学习从未接触的知识一定要开始的早，这样在接下来的使用时才不会捉襟见肘。学习是一个不断进步的过程，一定要有好的规划。

• 李霆政：因为这个冲刺我学习很多，学习前端的知识，网络接口的知识，unity的开发，也进行软工的熬夜活动，可以说是收货满满，兄弟们的也是一起开发更加的熟悉了。

• 段新源：学到了使用unity制作前端UI，如果历史重来，我会尽早把前端的js语言学会，制作更好的前端客户界面。

• 谢小龙：通过本次Alpha周的冲刺，我们了解到了微信小程序制作小游戏的困难之处，就是在于教程对于新手并不友好，学习成本非常巨大，需要有部分基础的人才可以慢慢上手，而我们现在的程度显然有些乏力，决定转战app，让我们了解到，对于我们开始计划工作时应该预估难度和成本等，不然到时发现问题就没时间去解决了。

• 胡驰：在做项目之前还是得反复确认项目的可行性，要从各方面思考，不然浪费时间是很伤精神的事情；平时还是得多学习一些编程语言多使用一些主流的工具，这也对自己的未来有很大帮助，还有就是要加强团队之间的交流合作，沟通时解决一切问题和分歧的基础，在负责自己项目的方面大家也得坦诚相见，不要觉得自己没做什么事情很丢人，应该如实汇报自己的学习进度，这样才更加实际，也方便安排团队的分工，对后续任务的实施和分配更有效。