采访对象：
由于北航上过软件工程，邹欣老师开课的。所以我选择了两个北航的同学进行采访。谭传奇做的是一个手机的游戏，殷鹏程做的是一个Web的网站。两组均在去年获得非常好的成绩，于是我便学习了一下这些组的成功经验与不足。
1、谭传奇的采访
今天采访了谭传奇，他是上届在北航上了微软开发者邹欣老师开设的软件工程课程。他们组去年的team project 是一个安卓的游戏。
我：你们去年软件工程做的是什么？
谭 我们Shine小组的团队项目是自选项目，我们选择了一个跨平台的移动游戏应用，名叫AbsoluteDefense。
我：你们的人员安排是什么？
谭：
经过我们的讨论和对各自特点的探讨，我们决定了如下的人员安排：
王安然：对游戏架构的设计及Android部分编码工作；
黄杨：对游戏本身逻辑的设计、部分美工及IOS部分编码工作；
谭传奇：基础架构编码工作，阅读代码并与编码人员沟通；
韩佳胤：美工及测试工作；
林璐：美工及文档工作；
谢伯炎：Cocos2d架构方面的编码工作及测试工作；
刘俊伟：测试工作；
我：你们如何做到小组内成员很好沟通的？
谭：拟定在每节软件工程课后开会，十分钟左右，说明各个成员该星期所完成的任务和遇到的问题；在QQ群里也可以进行讨论或者私下讨论，大家不要屏蔽群消息。
我：你们项目的采用了什么样的开发方式？
谭：开发方式多种多样，如果一个人也算团队的话，那一窝蜂模式挺好的
在学生团队中，最普遍的就是“明星模式”，其实会继续退化为只有明星干活
当然上面都是对团队分工的方式，下面就说对于工程本身的方式
瀑布模型就是“听上去很美”的一个方式
为什么说是“听上去很美”，其实这在于我们的能力有限
最简单的瀑布，就是水顺着流下来了，也没法再回流上去
显然，软件工程肯定不是一次性的，这个模型要改
那我们就加上回溯
加上回溯还不行，因为瀑布是顺着流的，最后一点肯定得最后流到
那我们总不能等水都流干净了才发现出问题了吧
这是一个多维的改进方式，很难面面俱到
作者提出了很多改进意见，其实是很多不同方向上的改进方法
对了我们的项目而言，可以近似的认为，使用了这样一种方法DO IT TWICE
我们只设计了一种机型，和一个场景，玩家也只有一个武器
然后我们就可以开始玩了，大家每个玩几遍，然后讨论讨论，还应该有什么飞机，场景应该怎么样，武器应该怎么办，等等
然后吸取经验，再来一遍，把要加的东西都得加上
不过我觉得，瀑布模型好像并不适合我们，接口不成熟，技术不成熟，反而是有时间多交流
这样实际上敏捷比较适合我们，关于敏捷，下面再说
我：团队分应该怎么给？
谭：团队也分很多种，如果是公司里大家都上班拿着工资，我觉得评价方法很简单，谁做的多谁做的好谁能力强
就理应拿的多，相信也没有人有意见
但对于我们这样的团队，这种评价体系就不可行了
在目前的条件下，学生团队可能有退化为一人工作多人酱油的分工
这正是因为有人能力强
而如果在团队建立之初就已经确定了能力强的人拿的分高
那其他人的工作热情就会受到很大的影响
当然也可以有人说因为要拿高分，我要努力，我要把我的能力变强，然后拿高分，这个就不讨论了
所以我认为，团队的分应该这样给
分数=完成情况*工作量+积极程度
2、对殷鹏程的采访
今天采访了殷鹏程，他是上届在北航上了微软开发者邹欣老师开设的软件工程课程。他们组去年的team project 是一个叫做学霸的网站。
我：你们去年做的是什么项目，你担任了什么角色。
殷鹏程：
在M1阶段，我们负责UI展示的设计，作为团队的PM，我在很早的时候就给各个Dev分配了任务，由于M1阶段学业压力较轻，我们可以拿出很充裕的时间来做这个项目。当时，我大概每天能够拿出3个小时来做项目，当初，在第一个星期里，我们围绕如何在线展示PDF文档进行了技术攻关，用了大概4-5天的时间，最终敲定了FlexPaper的开源解决方案，这次的攻关是我的一大收获：不仅提升了我个人的技术能力，也锻炼了自己分析问题，解决问题的能力。
做网站，架构很重要，我们在项目中使用了贫血模型，这也是我个人在网站架构设计上的一大心得，这种模式的使用使得美工与DEV能够在完全解耦的情况下进行开发，提高了整个团队的效率。
但是，在M1阶段，我作为PM，遇到了许多问题：TFS不会使用（没有修改剩余时间、完成时间等），导致好多天的燃尽图都不对；学霸网站在代码上存在相当大的冗余，没有得到很好的处理（传说中的big ball of mud）；再者，3个UI团队之间协调不力，UI团队与上层团队（crawler&pipeline）之间没有达成统一的接口，导致最后整合存在相当大的问题（犹记得那天的整合，从晚7点干到凌晨2点，导致我差点被锁在新主楼。）
在M2阶段，M1阶段的很多setback都得到了很好的解决，比如我们的燃尽图，得力于前期的任务规划，hidden tasks变得很少，加之我本人使用TFS已熟练，整个项目的10天Scrum变得很平稳。其次，在M1结束的第一次课上，我们PMs用了大半节课的时间来讨论接口的规范化问题，并对很多存在歧义的地方达成了共识。这使得在M2阶段各个组之间的配合更加紧密。
我：你们去年在开发中有没有遇到什么困难。
殷鹏程：
我们和其他两个UI组一起做这个项目，对于我们3个UI组而言，问题还是蛮多的：
- 3个组的代码托管在tfs的不同项目下，硬生生的把一个统一的网站拆成三份，导致编码与整合的困难。
- 由于我们组在M2阶段跟DOOM团队交换项目，M2对于我们而言也是个M1，我们又遇到了许多新的问题。
- 我们交付给DOOM的代码（M1阶段的）有很多Bugs，DOOM团队由于种种原因没有很好的修复。
在M2阶段，我们组由UI转向了搜索，在这一个阶段，虽然面对新的问题，新的挑战，但我想，相较于M1，我们继承了如下的优点、达到了如下的提高：
- 代码复用：UI代码大量复用M1阶段的设计，UI本身工作量较少；
- 架构设计：彻底放弃了DOOM团队的方案，采用Lucene.net+SqlServer Full Text Search的开源解决方案，开发效率高，开发周期可控。
- 继续使用贫血模型
3、从中所学以及我还会做什么以改进
经过阅读他们的博客，我获得了很多很多经验。一开始大家都信心满满的描绘了宏图，但是随着项目的进展，以及其他杂事的加入，事情往往会进展的没有想象的那么顺利。有很多很多瑕疵。于是开始的进度就被一拖再拖。
并且，一开始可能会考虑不全很多事情，每次编大的工程，如果经验不足的管理员会在之后遇到很大的之前意想不到的麻烦。所以要把困难估计的大一些，并且组长必须熟悉每个人的战斗力是什么，要尽量利用好组里面的每个人。
而且在真正的开发过程中，只有PM能够学到足够多的知识，其他角色可能任务量不是很大，学不到什么知识。而且真正给分的时候人情因素有很多，所以给分的分数与实际他们的付出是不成正比的。
还有就是建立模型的问题，殷鹏程在采访中向我们介绍了贫血模型，虽然现在还不是很了解，但以后一定多多学习。因为一个工程良好的架构才会让开发事半功倍。并且我们需要一个TFS的代码管理平台，让该工程进行的更加顺利。
其次就是要经常向他人请教问题，很多设计模型与开源软件都能对你的工程有很大的帮助。
如果我当初和他们一起做，我一定多和技术大牛交流，他们两组基本都是埋头写程序，只在组内讨论，没有和其他人交流。我觉得好的点子都是交流出来的。并且关于组内会有人水的问题我相信在MSRA会好一些，因为每个人都很优秀，但也需要PM的协调调度。还有就是软件工程最重要的就是过程，你在过程中可以学到很多很多知识，所以真正动手实践才是我们获得知识的唯一路径。