M2后日谈
团队成员的简介
（按照字母表序）
韩佳胤：http://www.cnblogs.com/yinee/
黄杨：http://www.cnblogs.com/skyjoker
林璐：http://www.cnblogs.com/linlu1142/
刘俊伟：http://www.cnblogs.com/illlllllL/
谭传奇：http://home.cnblogs.com/u/Tjamie/
王安然 ：http://www.cnblogs.com/wanganran/
谢伯炎：http://www.cnblogs.com/iamotaku/
谢永青：http://www.cnblogs.com/xyqhello/
谷骞：http://www.cnblogs.com/5215guqian/
产品简介：
开始做的时候，我们是有个野心的。开始的时候目标大也有好处，能给人以一炮牛逼的希望，最能调动成员工作的激情，当时我们有7个人，人多这么多应当也是力量很大，确实不妨说大点。
预期的典型用户：对新鲜游戏有爱的玩家。
预期的功能包括回放、应用内支付功能、从文件进行游戏恢复、游戏道具解锁、高分榜。
团队目标：
我们的游戏目标首先是在内测时获得很高的评价，随后，我们将其推广到官方的IOS、Android市场，并在各大论坛宣传。我们会将其定价为免费，以得到更高的下载量，并通过应用内支付(Android IAB: In-app Billing or IAP in iOS: In-app Purchase)获得收益。预计发布后一周的用户数量（下载量）为：
IOS市场：1500.
Android市场：700.
Android总下载量（包括各种市场、论坛、下载网站）：2000
发布后一个月内收益为：
IOS：100美元
Android：50美元
现在M2已经过去了，最后既然已经发布了，就叫beta版吧。功能和游戏内容方面，在最后发布期限的迫近之下稍砍、轻砍、慢砍、快砍、挥泪砍之后，到现在的beta版，已然只剩冰山一角（只做了游戏道具解锁和高分榜我好意思说？）。而且很抱歉地是发布时间还经过了很不靠谱的跳票，we’re sorry.不做解释，解释都是掩饰。
游戏本身新颖是有的，效果也还是有一点的，但用户体验远还没有达到标准，内容也不够丰富，还不足够吸引人，下载量基本肯定是达不到的。收入？那是个笑话。
截至1月7日早上9点55分，共计下载量为：
IOS：169（尚未发布到app store，app store的工作人员都吃shit去了。）
Android：403
但是纵然说了这么多自打耳光的回顾，有一点，我们的项目成果和其他的项目还是在一个水准上的，严肃地说。另外，据小道消息，我们一个项目的代码量大于“学霸”项目（总人数约40人）的总代码量。
工程回顾：
经过第一次迭代开发，团队合作的很多问题暴露出来。
问题1：设计不足。一个软件工程的设计到实施，其实是很重要一步。在我们的项目中，为了满足游戏设计的需求，我们的软件工程设计中保留了很多的可扩展性，但是却没有足够关注到细节，没有给出所有具体的要求。在实施工程的时候经常发现有的问题在设计中找不到参考，导致开发人员的效率低下。
问题2：开发人员水平有限。分配任务的时候经常有说这个事儿做不到，或者压根不知道怎么做；验收工作频出意外，DEV写了一个模块之后，验收的时候发现模块质量不行，代码质量低是其次，无法按照给定的接口工作。
问题3：工作分配及目标不够明确，PM在分工时，没有对各项工作进行足够细致的描述，也没有设立一个明确的短期目标，使得开发人员对自己的工作目标模糊，没有验收时标准的参考。
问题3：在M1阶段，开发人员工作时和相关模块开发人员、PM的联系太少，总是PM下达任务，Dev之间缺乏联系。对于工作目标中模糊的部分采用了模糊处理，验收时代码没有达到预期的效果。M2阶段效果好了一些。
问题4：有关游戏制作的特殊性。游戏制作大家都是第一次，一个游戏玩起来基本的逻辑也许不复杂，但是难在它对交互效果要求极高，如果只能满足基本的逻辑正确而交互效果极差，那这段代码必然失败。为了提供一个优秀的游戏体验，好的美工重要，开发人员要写出交互效果良好的代码也很重要。开发人员自身需要有一定交互设计功底，并且有美术功底或者有美工的指导，这是我们的大部分组员都缺乏的，这也导致了后期的用户评价都是“游戏很好玩，但是不协调，不好看”。程序员，有心无力，没办法……
问题5：错误的预估了项目的大小。我们都没有制作游戏的经验，没有想到，这样一款比较简单的游戏都需要这么大的工作量。这导致了最后的套票。
另外，工程项目本身也存在很多问题，使用跨平台C++游戏引擎编写的一个不好就是我们没捣鼓出来配合VS进行代码质量管理的有效方法。而且游戏程序的测试野相当复杂，我们仅能采用大量测试工程来分开游戏单位测试，保证没有意外错误和运行效果，最低限度是保证代码逻辑功能正确。
代码覆盖率测试？oh算了吧……这么说实在是太不专业了太不专业了，做得这么不专业也实在是很无奈，Native C++与C#或者托管的C++不同。试过VS自带的代码覆盖率测试，效果很不好。尽力了……
我们觉得碰到这种情况，就应该把游戏设计那人吊起来，把文档写到游戏逻辑的每个角落，每个效果都有动画演示和运算函数，然后大家照着文档开始干，缺一否则皆不能安天下。否则光干游戏设计的人工作量也不够大。
进展和发布
2012/10/16左右：已经有游戏的想法
2012/10/22：确定了软工大作业为这款游戏，同时完成了一个简单的小Demo
2012/11/1：开始M1
2012/11/12：完成M1.M1阶段完成了游戏的Alpha版，游戏的主要元素已经完成；缺少游戏体验、AI、菜单、排行榜、武器和道具等。
2012/11/27：开始M2
2012/12/9：完成M2,M2阶段完成了游戏的菜单、排行榜、武器；缺少各部分之间的串联、游戏体验、AI、IOS和Android移植等。
2012/12/11：开始M3
2012/12/27：完成M3,M3阶段完成了游戏体验和一些效果（粒子特效等）、AI、各部分之间的串联。
2012/12/31：完成IOS版的移植，发布。
2013/1/4：完成Android版的移植，发布。
具体贡献
|
名字 |
角色 |
具体的, 可衡量的, 可验证的贡献 |
|
韩佳胤&谷骞 |
美工 |
Psd游戏单位设计11 ，面板按钮设计32，图标1。博客2 |
|
黄杨 |
PM、Dev、美工 |
Demo工程代码1996//652，工程代码13286//260，文档3，博客10 |
|
林璐 |
美工 |
Psd菜单元素41，图标2，logo 1。博客2 |
|
刘俊伟 |
Test |
单元测试工程代码3927//1281，大测试工程15，BUG数不胜数，博客5，推广2 |
|
谭传奇 |
Dev |
工程代码2899//59，博客8 |
|
王安然 |
PM、Dev |
工程代码5979//117，博客33，推广2，文档3 |
|
谢伯炎 |
Dev |
工程代码3544//71.72，博客3 |
|
谢永青 |
Dev |
Demo工程代码1330//435，工程代码7307//143，博客2 |
用户反馈
软工课堂现场评论：
“用手画盾进行防御的思路很新颖。”-----路人学姐A
＂游戏画面挺不错，就是有动态效果更好＂---路人学姐B
＂图标意思不明显，不知道是干嘛用＂---路人同届汉子C
“用户体验不佳，一上来难度太大，让玩家失去信心了。”----同班汉子D
“游戏操作比较顺手，但是要是能够多点画盾就更棒了。”-----路人同届姑娘E
用户评论摘录：
“这个画面看起来很赞啊！赶快下到手机上玩嗯” ——出自 未来花园
“LZ人才”——出自 未来花园
“真不错呢，话说这创意有点像当年DC上红得发紫的斑鸠，期待一下” ——出自 博客园
“很新颖，比较好玩，但是就是美工有点不协调”——出自同学评价
M2的里程碑
在M1中，我们专注于游戏本身的效果和逻辑。M2的重点则是游戏外部功能，完成了游戏菜单、解锁游戏内容、高分榜这些部分，对于游戏本身，只是对效果进行润色、添加内容。
关于敏捷开发
在M1中，作为PM，我只是觉得我们敏捷开发做的不够好，也似乎找到了一些原因。在M2阶段，通过阅读了一些项目管理的书籍，我终于找到了根本原因。
1. 敏捷开发需要及时的反馈。反馈是敏捷开发的灵魂所在，传统的工程期望的是一个大的时间段后的反馈，而敏捷开发期望的是一个非常短时间的反馈（如Daily Scrum)。
2. 敏捷开发需要高水平。反馈的目的是为了更好的提升接下来的代码质量。但是，如果开发人员的水平不是很高，那么反馈的结果便是：“这个我不会，我不做了。”。这样，反馈也就变得没有用了。
3. 敏捷开发需要全职。不仅是敏捷开发，任何一个大项目都不允许任何一个组员在别的组员辛苦劳作的时候去干别的事情。这不仅是对组员的不公平，也是对项目的不投入。但是，学生不可能做到这一点。
于此，我们的敏捷开发工作做得比较糟糕。但是认识到了上面几点，也是一个进步。
总结
这学期的软件工程课，无疑是充实的。动手做，是学习工程知识的重要途径。其实我们在一片茫然中动手，必须完成了一座雕像，尽管无论是从技术上、艺术上，都没有办法入流，但是我们必须完成它。我们遇到了书上找不到答案的问题，遇到了真正工程中的问题，我们要迎难而上，也许方法很土，也许解决不了，但是谁也不想交上一失败的半成品。也许花了好大力气，走了好多弯路，才有最后的结果，才发现有时候经验之谈很重要。但是这个时候课程已经结束了，老师貌似觉得你们已经学到东西了。这时……是该回去再看一遍书呢，还是应该再动一些手，再感悟感悟人类捉摸了几十年的问题？
一己之言，不能说出所有人的心声。总而言之，看书学习+动手做出成品一个学期时间太短了，老师您觉得不短？那换句话说项目定太大了，老师您觉得不大？那再换句话说其他课排太紧了，老师您觉得不紧？那就是学生都TM太懒了。
软工大作业，用于学习，那是非常好的。用于真正的工程，还是等毕业吧。
集体照
