Beta阶段项目展示
团队成员的简介
详细见团队简介
| 角色 | 姓名 | 照片 |
|---|---|---|
| 项目经理，策划 | 游心 |  |
| 策划 | 王子铭 |  |
| 策划 | 蔡帜 |  |
| 美工 | 赵晓宇 |  |
| 美工 | 王辰昱 |  |
| 开发、架构师 | 解小锐 |  |
| 开发 | 陈鑫 |  |
| 开发 | 李金奇 |  |
| 开发 | 杨森 |  |
团队成员个人博客地址
游心：http://www.cnblogs.com/jefhq/
王子铭：http://www.cnblogs.com/514DNA/
蔡帜： http://www.cnblogs.com/felixcaae/
赵晓宇： http://www.cnblogs.com/zhaobs/
王辰昱： http://www.cnblogs.com/wangchenyu1996/
解小锐： http://www.cnblogs.com/xxrxxr/
陈鑫：www.cnblogs.com/silentic
李金奇：http://www.cnblogs.com/crvz6182/
杨森：www.cnblogs.com/silentic
团队项目的目标，预期的典型用户，预期的功能描述，预期的用户数量在哪里？
我们团队的Beta阶段的目标为
- 明确游戏玩法并完成游戏策划书的撰写
- 确定独立开发游戏系统的总体策划设计
- 确立科研系统、人员性格心情、聊天系统等新玩法
- 其他策划细节的详细设计
- 完成独立开发游戏玩法的开发
- 完成科研系统玩法的开发
- 完成人员性格等新系统搭载
- 完成聊天系统新玩法的开发
- 完成游戏ui的重设计
- 游戏ui风格的重新设计
- 游戏ui界面的重新设计
- 游戏ui控件的重新设计
预期的典型用户为喜爱玩模拟经营类游戏的年轻人、学生等。
预期的功能描述可以在策划书：游戏玩法说明书中详细看到
预期的用户数量为200
团队的产品如何满足了用户的需求
满足了用户消磨时间、娱乐身心的需求。
事先定义的软件下载量达到了么？为什么没有达到？
没有达到，我们认为是因为游戏的延期发布导致没有足够的时间去累计足够的用户量。
团队的成员如何分工协作的？有什么经验教训？
我们的团队成员分工在进入beta阶段后有了比较大的改变。首先是PM，在alpha阶段的PM是蔡帜，在beta阶段经过了两周的缓冲后PM更换为游心。然后是团队分工组成做出了比较大的改变。要想做一个游戏，就必须要有明确的游戏设计和策划书，才能明确工作量和软件效果、目标，开发才能顺利进行。由于在alpha阶段没有给出明确的游戏玩法说明以及策划书，导致开发进度缓慢甚至停滞的状况，产生了策划给不出详细的玩法说明及需求，开发不知道怎么做就按照自己的想法做或者停滞等待策划。为了避免重蹈alpha阶段的错误，我们在beta阶段的分工上做出了很大的调整：将所有人员分为三组，策划组、美工组和开发组。
- 策划组：前期主要负责给出详细的游戏玩法说明书并完成详细的游戏策划书给开发组和美工组；明确需求并完成必要的数值策划等内容，并给美工提出基本的界面、控件需求。在后期主要负责给开发组开发出来的游戏进行功能测试，检查是否完成了策划组本身预想的功能并测试其他的bug反馈给开发组进行修复。
- 美工组：根据策划组和开发组给出来的美工需求设计相关的ui界面，给出界面原型图以及各种需要的控件。但不编写代码主要通过一些画图软件进行设计。
- 开发组：根据策划组提出的玩法需求，团队的架构师将需求转化为代码结构设计并统一接口。其他开发人员进行各自负责的功能的开发。
根据上文所述的分工，我们可以明确每个人的分工，并有了一个良好的工作流水线：
- 策划组提出详细的需求给美工和开发进行开发；
- 美工进行ui设计，开发进行需求-设计转换并完成后端代码的编写；
- 美工完成ui设计后给开发进行ui的编写；
- 开发完成功能并进行基本测试后给策划进行功能测试
其中上述的每一步是流水线的其中一步，可以看到在整个开发流程中每个人都基本处于有工作可以干的状态达到比较平均的工作负荷。并且每个组都有一个类似于组长的一个人进行组内的协调，PM主要跟组长进行交流，在必要时跟具体的成员进行交流，在人员比较多的情况下提高了交流的效率。分工示意图如下所示。
备注：具体分工为
- 策划组：游心、蔡帜、王子铭
- 美工组：王辰昱、赵晓宇
- 开发组：解小锐、陈鑫、李金奇、杨森
经验教训上，在实际运行这个分工的时候，刚开始的工作是开发组进行alpha阶段一些小的bug的修复等工作，策划组进行了大量的策划、玩法设计，但每个玩法策划都没有实际敲定都处于待定状态没有给美工和开发，而过了一周更换PM后才最终敲定了一部分并给了开发、美工进行开发设计，从时间上来看有些晚了，这也间接导致了项目进度后期的滞后现象。但策划后期不断给出新的功能策划并根据开发的反馈进行完善设计，开发也在后期处于满负荷运转，这也足够说明我们想到的分工是比较合理的。
第二个教训就是刚才说到中后期赶策划进度短时间内给出较多的玩法设计的同时PM也在策划组中所以没有及时督促美工进行ui设计，所以在后端代码开发完毕进入ui开发时缺少了很多美工素材导致了一小段时间的开发停滞，这也是我们后期项目发布延期的一个原因。
第三个教训就是老师上课也讲过的技术风险问题。我们在alpha阶段选择的cocos creator框架在做我们这个类型的游戏是不太合适的。他的一些物理引擎等要素由于是模拟经营类游戏所以没有用到，我们只是用到他比较方便的贴图ui的一些小功能。另外它还有很大的设计缺陷，导致ui设计时每次只能一个人进行开发不能多人同时进行开发，这也导致我们后期的集中开发效率很低，只能通过结对极限编程的方式进行集中开发。
第四个教训就是一次性开发的功能较多，应该一个功能一个功能进行开发进行快速的流水线式迭代达到最终的目标。这也是当初设想的分工的理应的形态但后期由于时间紧张导致统一开发导致迭代次数减少，并最终导致了项目延期发布。
团队是如何进行项目管理的？
主要通过github中的issue进行工作分配，组内的细节工作由各个组的组长或者个人提出相应的issue，占大部分具有大体方向性的issue由PM提出issue并分配到相应的组进行细化。在开发冲刺阶段每天进行scrum会议，以确保问题可以及时反馈并修正开发策略。在最后的关键时期召集所有人进行长时间的集中开发，以确保更低的交流成本提高开发效率。
团队如何平衡 时间/质量/资源 争取如期完成任务的？
我们在初期主要精力在于完善、完成整个游戏设计，完成游戏玩法策划书并明确工作量。为了在1个月的短时间内充分利用9个人的人数优势我们将人力资源划分为三个组，在上文所说那样进行流水线作业已达到较高的效率。但我们刚开始的1周多的时间在进行广度的游戏设计但没有将设计初稿深度细化转化为需求并交给开发、美工进行进一步开发。在时间要求下我们舍弃了更加广度的游戏玩法的设计将想到的游戏玩法进行筛选、简化或深入设计并一个一个按照流水的思想交给开发美工进行设计。
在开发后期，我们的开发处于严重的时间不足，但由于cocos creator工程的缺陷，我们最有优势的人力资源不能同时投入开发，所以我们使用集中式的结对极限编程一组一组轮流进行快速开发，以争取如期完成任务的同时结对编程也能保证一定的软件质量。于此同时策划组也转换为测试组将开发出来的apk包进行上机测试。
在产品之外，团队代码的软件工程质量如何？如何用数据来证明？
测试用例数目，代码覆盖率数目。
运行测试用例得到代码覆盖率的视频录像，(需要现场看到。 没有诸如 “我的电脑没有装测试环境”,“文件不全”等等借口)
代码规范
我们给出了简单的代码规范，在wiki中可以查到：
- 对于一个对象，其属性使用驼峰命名法，但是在最后加
_，其方法就使用驼峰命名法，这样方法和属性可以区分开 - 对于常量，以
k开头，单词首字母大写 - 其他的就参考google的C++命名规范
- 关于调试信息的输出：统一使用cc.log()吧
-
- 统一注释风格：鉴于VScode 会自动帮你生成/ ** * /风格的注释，规定无论是属性还是方法，单行就用//多行就用/ ** * /
齐全的文档
我们的文档都在github上的wiki上，链接
其中比较重要的文档为
- 游戏玩法说明书（即策划书、需求文档）：https://github.com/xxr5566833/Game/wiki/游戏玩法策划书
- 代码规范、编码约定：https://github.com/xxr5566833/Game/wiki/简单的编码约定
- UI设计文档：https://github.com/xxr5566833/Game/wiki/UI-设计文档
- 技术规格说明(原api-说明)：https://github.com/xxr5566833/Game/wiki/目录
- 界面框架说明文档：https://github.com/xxr5566833/Game/wiki/界面框架
- 功能描述文档：https://github.com/xxr5566833/Game/wiki/功能描述
其他小的细节文档就不一一在此列出，这些文档都可以在我们的github的wiki上查到。
如何从零运行本项目？
可以参考我们的readme中给出的教程。
有些项目是在原来的基础上改进的，那么我们团队的软件工程项目质量有什么样的提高？
重新设计了界面ui，使界面更加好看友善。
所有的项目都会收集到用户的数据，请问你们对这类数据做了什么样的分析，这些分析如何验证或推翻了原来的假设？这些数据如何帮助项目改进软件工程的质量？
目前还没有收集到有效的用户数据
团队项目的实际进展，说明在项目管理中，scrum的燃尽图是如何真实反映项目的状态的？或者燃尽图美化了状态？
备注：由于以前手动画燃尽图的方式效率太低，中间改变了方式所以从这里开始为从12月1号开始的燃尽图，但总体趋势并不受影响
可以看到从燃尽图上项目进度还是可以的，在刚开始有一点缓慢，这是因为刚进入beta阶段决定明确策划需求导致的一个小的停滞，然后中前段有一个比较快速的完成过程，这是由于在这里大量的策划工作相继完成，并在更换PM后策划书的敲定更加迅速，策划到开发的流水更加通畅，这也是实际上开发过程发生的情况，比较真实。但后期，尤其是最后的项目进度就不太真实，因为大量的集中式开发以及ui的不可并行开发的特点导致剩余的工作进展非常缓慢，在项目总进度上到了90%的地方但是实际工作量却还省得比较多，所以后期的燃尽图美化了项目的进展。
beta阶段发布说明
经过我们小组长期的奋斗下，终于将我们的游戏码帅的beta版开发完毕并发布了~让我们先瞧一瞧新版本中的新玩法新特性吧！
Beta版本新功能
我们思考的具体玩法策划可以在github上的玩法说明中查看~
新玩法：独立开发玩法搭载
现在我们游戏中的模拟软件公司不仅可以开发外包任务，还可以自己独立开发自己的软件了！
新玩法中，独立开发一共有五个阶段：计划阶段、开发阶段、测试阶段、发布阶段、运营阶段。
玩家可以在计划阶段选择独立开发软件的平台、类型、软件的功能，选择参加项目开发的员工并支付一定的预算开始开发。
-
选择开发软件的平台：
-
然后选择开发软件的类型：
-
再选择开发软件的功能：（=。=这么多功能我都给选了吧）
-
确认信息并决定软件售价和名称：（>.<）这么高级的软件一定要贵啊！
- 选择进行开发的员工就可以开始开发了~
在开发阶段玩家计划开发的软件就开始由项目组员工进行开发了~员工们相继贡献开发点数，想知道软件开发的怎么样了？看看底下的项目信息看看项目具体的进度和成果吧！
软件开发进度达到了100%，开发阶段结束了！现在项目进入了测试阶段，看看自己的项目有多少恼人的bug！在测试阶段你可以看到项目中不同级别的bug（三个级别：高级、中级、低级，级别越高bug表示越严重），你的员工们会尽力排查软件的bug，在debug途中也会发现以前没有发现的bug呦~
测试阶段终于结束了，软件中已知的bug已经排查干净了，进入了发布阶段！
以为发布就完事了吗，我们的软件还需要人员进行维护和销售！维护人员会继续排查软件中的bug，并在运营阶段你的软件可能会被爆出重大的漏洞并严重影响了软件的销量！这时候维护人员就会起到救火队员的作用迅速排查漏洞并恢复软件的销量。
新玩法：银行系统玩法搭载
在公司运营过程中有没有遇到想雇佣新人、开始新的项目的时候手头没有足够的资金进行投资？现在搭载了银行系统，银行可以融资给你的公司！根据你的声誉会银行会给出一定的融资上限，你就可以去找银行贷款了！
-
活期贷款
-
定期贷款：
贷款是有利息的要尽早还款~
如果贷款到期了还没有钱可以还怎么办……那你就可能会接触到社会的阴暗面了（奸笑）
如果玩家没有足够资金还贷或者支付员工工资，有唯一的一次机会银行会网开一面给你一笔“破产保护基金”让你度过此劫。但只有一次，没有下次保护机会。
新玩法：科技系统玩法搭载
一个搞软件的公司怎么可以少了自己的黑科技！现在玩家可以自己探索科技的深渊了~每个科技都有一定的解锁条件和加成奖励效果，还等着干什么，赶紧做项目积累科研点数去探索自己的黑科技吧！
暴击！产生了科研点数可以进行科研了~
有好多科技分支可以选择开发，不同的科技都有不同的加成。无法研究的科技是不知道具体的解锁条件以及加成效果的。
新玩法：聊天系统玩法搭载
员工们都在开发项目，也没有新的项目、科技要点，老板表示很无聊……现在有了聊天系统就可以潜水暗中观察项目组中员工们的日常聊天了~
新特点：员工分级招聘
随着你的公司的成长，前来应聘的新人越来越强大了！还等着干什么赶紧去做项目提升你公司的声望招聘更强大更有个性的员工吧！
游戏界面优化
除了诸多新玩法以外我们的美工们还重新设计了游戏的界面，现在游戏界面的风格要比原先更加modern更加好看了。
其他游戏系统优化
新版本中我们还优化了其他游戏系统中不太合理的地方：
- 游戏结束条件：以前的结束条件为资金-500W，现在修改为资金不能为负，如果被迫支付时资金不足且已经经过了破产保护，则游戏结束，你的公司倒闭了。
- 现在可以接手多个项目了。召集更多的员工接手更多的项目赚取更多的资金吧！
- 游戏目标修改：删去达到500W就胜利的游戏结束条件，改为利用成就系统的收集更多成就的游戏目标。
- 由于影响游戏体验，移除了随机事件机制
- 其他细节优化和bug修复
对运行环境的要求
目前经过测试在安卓5.0及以上的环境下可以正常安装并运行游戏。其他环境下不作保障。具体兼容性以及各机型的运行状况见测试报告。
安装方法
从我们的发布地点下载apk安装包后点击安装即可安装。
Beta版本的缺陷及修复
Alpha阶段中存留的bug修复
beta版本中的新功能的bug以及修复情况如下。详情见测试报告。
| 序号 | issue | bug简述 | 解决情况 |
|---|---|---|---|
| 1 | #164 | 聊天系统项目组不解散bug | 已修复 |
| 2 | #163 | 聊天系统中对话框不会消失的问题 | 已修复 |
| 3 | #162 | 聊天系统中对话瞬间回复问题 | 已修复 |
| 4 | #172 | 聊天系统中员工只会说同一句话 | 推迟 |
| 5 | #174 | 独立开发UI：无法正确开始项目 | 已修复 |
| 6 | #173 | 独立开发UI：无法更改项目名称 | 已修复 |
| 7 | #171 | 委托项目UI：按钮无法切换状态 | 已修复 |
| 8 | #170 | 从ui界面退回主界面后，主界面消失 | 已修复 |
| 9 | #169 | 多个任务开始选人时，出现人物undefined的现象 | 已修复 |
| 10 | #168 | 雇佣选人上限bug | 已修复 |
| 11 | #167 | 独立开发UI：图标和文本位置不正确 | 已修复 |
| 12 | #166 | 独立开发UI：按钮无法动态加载 | 已修复 |
| 13 | #165 | 独立开发UI：平台图标无法正确加载 | 已修复 |
| 14 | #176 | 聊天系统中对话回复时所有人都进行回复的bug | 设计如此 |
| 15 | #175 | 雇佣面板打开以后再关闭，不能再打开 | 已修复 |
| 16 | #178 | 打包成apk安装后委托开发选人无法选中 | 已修复 |
Beta版本中已知的问题和限制
在测试报告中的bug list中有详细说明。目前还未解决的bug(缺陷)简述如下
软件的发布方式以及发布地址
我们的游戏beta版发布平台如下表所示。
| 发布平台 | 状态 | 发布地址 |
|---|---|---|
| github | 已发布 | https://github.com/xxr5566833/Game/releases/tag/beta1.0 |
| 华为应用市场 | 审核中 | - |
| taptap | 审核中 | - |
| 应用宝 | 审核中 | - |
| 酷安 | 审核中 | - |
如何反馈
可以通过在相关发布平台下回复或者向我们的团队邮箱发送邮件(cxyscpjljt@163.com)进行反馈。
用户反馈截图
所做软件最有特色的功能是什么，请着重介绍一下。活的用户如何从你的软件中获益的，请现场展示。
我们所做的软件最有特色的功能就是beta阶段重点开发的新功能：独立开发软件玩法。玩家现在不仅可以接简单的委托开发任务，还可以自己组合平台、类型、功能，进行属于自己公司的商业软件进入市场获利！详情可以看上文发布说明中的独立开发部分。
活的用户可以通过我们的游戏，不仅可以消磨时间、发展自己的软件公司愉悦心情，还可以了解一些软件开发的基本流程，由设计、开发、测试、发布、维护组成的基本软件开发流程也普及到了众多玩家，在愉悦心情的同时还可以了解一些软件开发的过程，一石二鸟。
团队成员在Beta阶段的角色和具体贡献：
团队中每个人的角色以及具体贡献为
-
游心：PM，策划组组长；具体贡献为：
- 完善第11次、12次scrum会议记录：2 * 0.5'
- 组织并完成其余所有的scrum会议记录：9 * 1‘
- 完成beta阶段测试文档的撰写：2’
- 完成beta阶段发布文档的撰写：2‘
- 完成beta阶段项目展示文档的撰写：3’
- 完成readme中的项目发布说明部分：1‘
- 完成游戏玩法说明书部分的撰写：同策划书完成，不重复累计
- 完成公式的基本策划#116，Bug数量产生机制设计#126：同公式汇总，不重复累计
- 科技树策划设计#117,科技图鉴蓝图设计#118：3’
- 科技列表中的各科技加成设计#133，聊天模拟机制设计#129，员工性格以及特殊加成设计#128，软件开发难度相关详细策划设计#127，待机聊天系统设定策划详细#113：7‘
- 市场机制详细设计#136：2’
- 黑客攻击防御系统初步设计#125：2‘
- 竞争机制具体设计#123：3’
- 所有公式汇总#130：4‘
- 竞争公司背景设计#122：1’
- 完成策划书#114：4‘
- 软件开发各阶段设计#115：3’
- 启动开发所花费预算计算方法#121：1‘
- 参与会议报告进度：16*0.5 = 8‘
- 加班：1’
-
王子铭：策划，数值策划；具体贡献为：
- 完成公式的基本策划#116，Bug数量产生机制设计#126： 4‘
- 科技树策划设计#117,科技图鉴蓝图设计#118：3’
- 科技列表中的各科技加成设计#133，聊天模拟机制设计#129，员工性格以及特殊加成设计#128，软件开发难度相关详细策划设计#127，待机聊天系统设定策划详细#113：7‘
- 更新了bug产生以及维护的公式#130：4’
- 市场机制详细设计#136：2‘
- 黑客攻击防御系统初步设计#125：2’
- 竞争机制具体设计#123：3‘
- 所有公式汇总#130：4’
- 竞争公司背景设计#122：1‘
- 公司活动机制详细设计方案#131：1’
- 员工属性再设计#124：1‘
- 参与会议报告进度：11*0.5 = 5.5‘
-
蔡帜：策划，将软件发布到目标应用市场上
-
王辰昱：美工组组长
-
赵晓宇：美工
-
解小锐：开发组组长，架构师，测试开发银行系统等；具体贡献为：
-
陈鑫：开发，负责科技系统及其相关开发工作；
-
杨森：开发，负责人员以及聊天系统的开发工作；
- 人员系统开发：2’
- 聊天系统开发：4‘
- 聊天系统ui对接：4’
- 聊天系统修复测试(#163,#164,#172)：3'
- 开发贡献：2 * (2.8+2.1) = 10
- 参与会议报告进度：10*0.5 = 5‘
-
李金奇：开发，负责整个独立开发及其相关开发工作；
- 根据wiki对alpha阶段的代码进行修改和重构#146：2’
- 独立开发部分ui对接：4‘
- 独立开发部分bug修复：8*0.5 = 4'
- 完成整个独立开发部分的开发：4‘
- 存档功能初探：1‘
- 开发贡献：2*(3.6+3.5) = 15'
- 参与会议报告进度：10*0.5 = 5‘
- 加班：1’
每个人的代码贡献量：
贡献分分配规则为: http://www.cnblogs.com/cxyscpjljt/p/7731573.html
最终每个人得到的贡献分
| 姓名 | 角色 | 得分 | 贡献分折算 |
|---|---|---|---|
| 项目经理，策划 | 游心 | 57 | 81 |
| 策划 | 王子铭 | 35.5 | 50 |
| 策划 | 蔡帜 | 22 | 31 |
| 美工 | 赵晓宇 | 14.5 | 21 |
| 美工 | 王辰昱 | 26.5 | 39 |
| 开发、架构师 | 解小锐 | 61 | 87 |
| 开发 | 陈鑫 | 33 | 48 |
| 开发 | 李金奇 | 36 | 52 |
| 开发 | 杨森 | 28 | 41 |