9组-Beta冲刺-总结
一、基本情况
组长博客链接：9组-Beta冲刺-总结
现场答辩总结：本次答辩，我们演示了我们到Beta冲刺周结束时的成果展示，离目标还有一些距离，不过本次答辩完成了任务，总体来说还不错，希望下次最终答辩的时候，可以真正做到我们想要的产品。
全组讨论照片：
得分占比：
| 姓名 | 成员分工 | 得分占比 |
|---|---|---|
| 胡驰 | 登录界面整合与用户交互优化，协助实现局域网联机功能，收集素材，对产品进行相关测试，视频制作 | 15% |
| 张伟鹏 | 博客、ppt部分文案内容及检查完善，对产品进行相关测试 | 11% |
| 李霆政 | 编写博客、部分游戏界面整合，对产品进行相关测试 | 11% |
| 缪恒铭 | 璀璨宝石UI及游戏逻辑的完善，对产品进行相关测试 | 18% |
| 段新源 | 博客，璀璨宝石界面优化，产品打包 | 11% |
| 卢浩玮 | 制作“现代艺术”游戏，为后续连接公网的工作提供了个云服务器 | 12% |
| 洪磊 | 实现局域网联机功能 | 11% |
| 谢小龙 | 两次博客，制作答辩ppt和答辩，收集相关桌游素材 | 11% |
二、总结思考
2.2.1 设想和目标
-
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述 ？
我们的初心是想做一款在移动端运行的桌游模拟器，它拥有着多人对战、人机对战、新手引导以及多种游戏的上线，可以为线下朋友聚会提供更多元化的娱乐项目，定义非常清楚，也对典型用户和典型场景有清晰描述。
-
我们达到目标了么?（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
截止到beta冲刺周，我们完成了一款游戏的上线，该款游戏的多人对战我们已经实现，人机对战尚未完成，进度较慢，离达到目标还有一定距离，原计划交付时间并未完成任务。
-
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
根据我们内部的测试，认为功能的程度可以接受，和我们预先想的一致，之后我们会交付测试组进行测试来试验我们重要功能的接受程度。
-
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
本次软工实践对于我们来说是第一次，会有诸多的错误，我们认为提前计划分工的失败，是导致我们这次做的不好的重要原因之一，由于开始我们对于开发的迷茫，让我们丢失了大量宝贵的时间，也打击了我们的积极性，如果有下次，我们会花更多的时间在计划分工上。
2.2.2 计划
-
是否有充足的时间来做计划?
我们本该有充足的时间做计划，但由于我们开始并未重视这块内容，所以并未做好充足的计划，这也让我们在这个点上吃了很多亏。
-
团队在计划阶段是如何解决组员对于计划的不同意见的？
当遇到团队在计划阶段不同意见时，我们会召开一次简短的会议，来投票决定我们的方向。
-
原计划的工作是否最后都做完了? 如果有没做完的，为什么?
原计划的工作并未全部完成，人机部分我们还未完成，因为我们在Alpha冲刺周改了方向，之前做的工作可能会无用了，所以导致我们并未按时完成。
-
有没有发现做了一些之后看来没必要或没多大价值的事?
就是在分工这块，当时大家都在学一件事，效率极其低下，这后来在我们看来是很没必要的。
-
是否每一项任务都有清楚定义和衡量的交付件?
只有一部分任务可以做到清楚定义和衡量的交付件。
-
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
项目的整个过程并未全部按照计划进行，中间在Alpha冲刺周的时候，我们由微信小游戏改为app，做vx小程序的时间和难度是当时没有估计到的。
-
在计划中有没有留下缓冲区，缓冲区有作用么?
在计划中我们并未留下缓冲区。
-
将来的计划会做什么修改？（例如：缓冲区的定义，加班）
将来的计划，我们是打算继续做人机对战，以及新手引导，来完成我们最初想要完成的功能。
-
学到了什么? 如果历史重来一遍, 会做什么改进?
本次软工实践让我们学到了做一个项目每一个环节都是非常重要的，从组织、计划、分工、时间管理、测试等，都需要经过慎重的考虑以及全力的付出，相信我们下次会做的更好。
2.2.3 资源
-
我们有足够的资源来完成各项任务么?
资源不是很够，但可以完成任务吧。
-
各项任务所需的时间和其他资源是如何估计的，精度如何?
各项任务所需的时间是由每个成员对应的进度和相应时间之间的匹配来估计，精度还不错
-
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试的时间和人力等资源是够的，美工设计和文案来说我们确实低估了难度，导致我们的UI并不是很优秀。
-
你有没有感到你做的事情可以让别人来做（更有效率）?
有，有些简单的工作让组内的其他技术方面不那么擅长的成员来完成且进行检查审核会更好。
-
有什么经验教训? 如果历史重来一遍, 会做什么改进?
对于学习的各种资源选择来说上是极其重要的，有些视频比较长也讲的比较难懂，而有些则比较浅显，所以选好学习资源是极其重要的。
2.2.4 变更管理
-
每个相关的员工都及时知道了变更的消息?
是的，我们每每有需要变更调整的消息，会第一时间通知所有成员
-
我们采用了什么办法决定“推迟”和“必须实现”的功能?
组内成员投票决定必须实现的功能是是哪个，以及通过现有的进度来确定哪些任务可推迟来做。
-
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
我们认为可以让客户有良好的体验，不会有大的bug以及其他一些客观问题来定义、
-
对于可能的变更是否能制定应急计划?
可以，像上次的转战app我们就是临时加班加点做出了应急计划，来赶进度。
-
组员是否能够有效地处理意料之外的工作请求？
可以，当突然给某个队员安排任务时，队员们都不会推脱，并在deadline之前做好。
-
学到了什么? 如果历史重来一遍, 会做什么改进?
学到了管理一个团队也是一门学问，如何提高大家的积极性，如何让大家的工作更有效率，以及组员之间的相处、沟通都是我们学到的东西，如果再有一次，我们相信我们可以做的更好，在团队协作方面。
2.2.5 设计/实现
-
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作是由胡驰在alpha冲刺前完成，alpha冲刺中期进行结构性修改。时间不算太合适，但应该是最合适的人。
-
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有遇到过这种情况，团队通过开会，集思广益提出意见进行修改。
-
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
使用了uml来帮助设计，Unity Profiler进行性能的分析对我们后续进行代码实现有很大帮助
-
比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
uml文档并未进行改变，暂时不需要改变
-
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
局域网，搭建后，不同玩家看到的内容可能会出现不同步的问题。设计/开发时因为局域网与游戏逻辑是不同人进行的代码实现，未整合时，没有发现也没有想到该问题。
-
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
代码复审还未开始，未来进行代码复审时会严格执行代码规范。
-
学到了什么? 如果历史重来一遍, 我们会做什么改进?
学到了使用unity制作游戏，以及团队合作。我们会更加早的认清自己的能力大小，及时做出符合我们的项目规划。
2.2.6 测试/发布
-
团队是否有一个测试计划？为什么没有？ 是否进行了正式的验收测试？
有测试计划，已经进行了一个桌游的测试。
-
团队是否有测试工具来帮助测试？
有Unity Profiler进行性能测试，在实现公网对战后将会用 Lua性能检测工具进行对软件的分析。
-
团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
通过组内成员用户实际体验和Unity Profiler工具综合评测软件的运行，分析CPU、GPU以及内存消耗。有很大用处，能让我们更有效更直观的找到问题所在，从而去对产品实施优化。
-
在发布的过程中发现了哪些意外问题？
打包出的apk出现蓝屏问题，以及横屏游戏，会变竖屏影响观感。
-
学到了什么? 如果历史重来一遍, 会做什么改进?
学到了打包、发布apk，如何使用测试工具。改进：更早的使用测试工具进行测试。
2.2.7 团队的角色，管理，合作（3分）
-
团队的每个角色是如何确定的，是不是人尽其才？
通过每位成员自我介绍自己所会的内容以及希望参与的模块，算是人尽其才。
-
团队成员之间有互相帮助么？
有，当一位成员任务进展困难时，其他成员会帮助他解决相关问题。
-
当出现项目管理、合作方面的问题时，团队成员如何解决问题？ 每个成员明确公开地表示对成员帮助的感谢 （汇总至组长博客）：
团队成员遇到问题时，通常会由组长进行协调。
-
段新源
- 我感谢<胡驰>对我的帮助， 因为某个具体的事情:在项目进展困难时鼓励大家，为大家提供帮助。
- 学到了使用unity及其附带的局域网技术。如果历史重来，我想我会尽早的学习我们组项目相关的知识。
-
谢小龙
- 我感谢<李霆政>对我的帮助，每次当我有懒惰心理的时候，他总是会来我宿舍督促我学习。
- 学习了unity搭建局域网游戏，以及搭载服务器的相关知识。还有局域网实现过程中可能出现的bug是由于什么原因。
-
张伟鹏
- 我感谢<所有组员>对我的帮助， 因为某个具体的事情:Beta冲刺的第二天晚上在活动室的时候我因为感冒身体感到不适，大家让我先回去好好休息。
- 学到了使用unity及其附带的局域网技术。如果历史重来，我想我会尽早的学习我们组项目相关的知识。
-
胡驰
- 我很感谢<以谢小龙同学为代表的>对我的帮助，因为某个具体的事情：在beta冲刺过程中，由于时间非常紧，要完成的内容很多，然而组内效率很低，心态有时候会是很崩的状态，在一个夜晚我也是将这种负面情绪撒在了组员身上，谢小龙同学成为了我当时的攻击对象，然而事实上确实不应该怪他，而是我自己没有将团队的分工安排妥当，也没有足够能力去调动团队的积极性，以至于有一部分人可能会长时间处于没有什么工作的状态。在被我责怪后，他也没有和我起争执，而是非常理性的说大家都是成年人了，应该去处理问题而非抱怨问题，这也点醒了我，也让我感受到了自己的小孩子气，与其说这是一个让我学习的过程，不如说是让我成长的过程，也感谢组员们对我们组的不离不弃，换组是规则内的事，然而没有人因为我们组实力差等因素而离开，非常感谢这段时间所有组员的包容和理解，但还请希望大家能够自发的去学习，找事情做而非等着分配任务（因为你们的组长也是一个小菜鸡）。
-
缪恒铭：
-
我感谢<段新源>对我的帮助，他总是能及时的将我写的成果打包为app并进行测试，
也经常与我进行沟通及游戏的反馈，为我的游戏开发进程省去了许多不必要的时间浪费 -
学到了许多unity开发的小技巧，也巩固了我c#的基础；
如果重来一遍，会多花点时间在网络编程的知识上。
-
-
李霆政
-
我感谢 <胡驰>对我的帮助，因为某个具体的事情unity的使用：
-
在我整合界面的时候，还有在我打包游戏的时候，胡驰很好的帮助了unity的使用
-
-
卢浩玮
- 我感谢<胡驰>的帮助，他作为组长，尽心尽力协调我们组的工作，推进整个组的项目的进行
-
洪磊
- 我感谢<缪恒铭>对我的帮助，在对接代码，实现局域网联机功能的时候，在他的帮助获得了很多的思路，帮助我加快进度完成了任务
- 我感谢<胡驰>对我的帮助，在我在工作过程中，懈怠的时候，不断督促我完成工作，确认各项工作，使得进度有保证，也让整个团队更像一个整体。
2.2.8 总结
段新源：
通过这次软工实践活动我提升了自己的代码编写能力，学到了html、css、js以及c#这些语言。体会到了团队合作对于一些问题解决的重要性。谢小龙：
本次软工实践到了Beta冲刺周，这么长时间下来，我学到了很多，例如软件开发的详细流程，团队的分工，以及使用Java部署后端服务器，还有Unity开发局域网游戏的相应知识，这其中看了无数的视频，一度焦虑的不行，直到现在，虽然我们的成果还未完成，不过我相信我们在后面的时间可以完成它，希望在后面的时间可以继续进步。最后，还是要严于律己，本次软工实践中，我有不少的懈怠，中间好多工做都是在deadline之前完成，效率比较低下，希望下次小组工作中可以更加的积极、勤奋。
张伟鹏：
这次Beta冲刺周时间很短，但依旧繁忙。几乎每天晚上都要去活动室完成项目，到凌晨才能回去，真的挺累的，但是每天都有学习到新的东西，每天都在进步。整个Beta冲刺周下来，大家都在一起奋斗，一起进步，一起为团队贡献自己的力量，和所有组员一起完成这次软工实践的项目，我感到很开心。胡驰：
1、感觉在整个项目进行工作前还是得将相关工作人员的性格，能力，特点等因素了解清楚，这样子才更方便于管理，也能让团队协作更加高效。
2、感觉组长在整个项目中与其将心思投入到design，codeing之类的事情，不如专注于怎样让一个团队成为一个有机的整体，调动各成员的积极性，甚至起一个督促作用，以防止大家的努力成为“假努力”。
3、对于自己也应该严于律己，在工作过程中理性作为主导，在平时的过程中也要呼吁大家将某个事情用心完成，不要草草了事，不然后期进行检查是很花时间的，每次做完的工作都得反复确认，也会影响团队中的信任感。
4、在网上查找资料进行学习的过程中，应该以相关性优先，其次是时间，再则是质量为顺序进行学习，我在这次beta冲刺中就是看到了非常优质的博文（比如之前学习的介绍network组件）然后一头扎进里面，后来才发现已经被淘汰了于是就很花时间。最后再次感谢团队成员们的相互帮助和支持。缪恒铭：
心得：这次Beta冲刺周时间很紧张，由于团队之前的问题，进度远远落后，也促使我们疯狂学习、疯狂赶进度，总体下来大家都很辛苦，不过每天都能有收获，还是很充实的。通过这次冲刺我深刻体会到了写游戏带来的快乐与痛苦，虽然有之前猪尾巴的经验，但写一个规则如此多的卡牌游戏还是经常要熬夜改代码，不过当自己做出的游戏能玩起来时，那种成就感令我非常开心。
李霆政：
学习到了很多开发的知识，基本掌握unity使用，经过这次软工实践，也发现很多问题，尤其是自己的编程能力缺陷，增加了我在开发的过程的困难。
卢浩玮：
一个人可以走更快，一群人可以更远；线下的coding对于进度的推进起了很大的作用，也让我了解了代码规范的重要性，可以有效降低前后端交流沟通的时间成本 。
洪磊：
由于alpha冲刺需求更改导致进度拖沓，加上beta冲刺本身很局促的时间，使得这一周格外忙碌，在修改代码，添加功能的时候也体会到了和团队成员沟通协调的感觉。单调繁忙的工作时间中，有不少痛苦、产生懈怠的时间，但在队长的督促和带领下还是跌跌撞撞过去了。
-
