开始的开始，采访往届ASE班的blog：http://www.cnblogs.com/legs/p/4894362.html 和北航软工M1检查：http://www.cnblogs.com/legs/p/4973542.html；
最后的最后，写下这篇总结，沉淀反思，与自己开诚布公；
其实这是同一件事：前事不忘后事之师。
具体的项目实现见我们的置顶博客：http://www.cnblogs.com/legs/p/5149065.html
具体的项目分析在报告中已经详细描述，其他几个同学的总结也已经基本涵盖，所以总结的重点不在项目本身~
项目选题：
其实这部分是我最想吐槽的，(课前要我们提交的方案：http://www.cnblogs.com/legs/p/4892151.html以及课上一些项目的简介),最后大家都跑UWP平台的必应词典去了。其实大家的调研未必深入，大抵是觉得跟着bingdict有肉吃。我们组又希望可以做一些自己的工作，所以没有选择必应词典项目向UWP平台的移植，而是结合林建平同学提交的方案，和必应词典查词功能结合，去完成一个新的在线取词功能，于是做了一些关于取词方面的调研，又和必应词典的负责人进行了讨论，包括我们最后的pdf阅读器方案，也是在那个时候敲定的。但是由此而引发的一系列关于adobe，foxit不得不陈的血泪，就是另外几个long story了。
在项目选题过程中，初心还是不错的，也进行了积极努力的前期筹备，但进行的技术调研不够，对于一些技术问题过于乐观。
团队组织：
构建之法里简述了不同的团队开发模式，如果非要选择一个的话，我们的团队应该是“业余剧团模式”。不但是因为我们几乎都没有软件开发的经验，甚至是相应的知识储备也不足。以我为例，C#和xmal都是边做边学的~所以在选题确定之后，我们首先对软件的各个功能模块进行了切分，并且定义了接口的数据格式，来方便各个模块“多点开花，齐头并进”（http://www.cnblogs.com/legs/p/4930117.html）。实际却是为了达到这样一个目的：各自研习，互不干涉。为了防止一人不在，项目停工，我们在每个方向上都进行了尽可能的考量，安排了人手。这对于项目初期的推进效果显著，却也为后来的种种麻烦埋下了种子。其实这样的各司其职的模式，更适合建立在稳定成熟的开发流程和专业的开发人员基础之上，即所谓的“交响乐团模式”下，才能真正的提高生产力。
在这个项目里,每位组员选择了不同的角色，并且随着项目推进，任务动态分配。
课程推进：
前期的两个个人项目，占用了我们很长的时间，压力也比较大，最后估计权当是提高编程能力和进入学习状态，并服务于最终成绩判定了。
但是课程对于团队项目似乎是越来越鸡肋，毕竟当时上课秋丰老师讲的东西，我们都半懂不懂，而我们在项目开展的过程中亟待解决的问题，却不是课程上短短的一两个小时可以解决的。老师可以和我们分享经验，帮我们指点雷区，最后每个坑都跳一跳的还得是自己。老师可以向我们指明先进生产力的发展方向，git，TFS的详细使用方法还得“实践出真知”；然而这又好像是课程本来的样子，我们虽然学步，但l路总要自己来走。哦，我似乎明白了为什么课程要把师生关系放在第一节讲：教练与学员~详情可翻阅构建之法第5~13页，教学相长，共同进步嘛~
课程的推进服务于项目，课程的内容又抽离于项目。那些懂得的，记下来；那些不懂的，终会懂得~毕竟我们的终极目标，是跑啊~
项目实现：
这是很值得被记录下来的故事~项目检查的时候，秋丰老师如是说。
但是坑深且复杂，而且不在我负责的部分，所以仅是列举。多谢后来人，戒之慎莫忘。
“业余剧团模式”下，一切看似有条不紊的进行着，第一个大坑来了：负责逻辑控制的同学，决定使用dll互相调用的方法来实现各部分代码的交互，简单来说，A，B都会被编译成DLL，其中A调B的dll，B也调A的DLL。注意，这是一个深坑；
本身设想的是设计插件，但是经不完全调研，现有技术并不支持这么做。（然后被review的时候被各种challenge），然后决定利用win32 adobe的阅读器实现，注意，这是另一个深坑；
在alpha release的时候项目完全不知何去何从，秋丰老师热心开脑洞，帮我们设计了planＢ，plan C，plan D。。。没想到后来忽然柳暗花明，成功实现了foxit SDK的调用。然而由于版权问题，注定无法release~
深坑，不忍卒讲：一个在Beta进程中去完成一个pdf阅读器，并就美工问题剧烈讨论的故事~一个始终不做release版本最后server是谁起的都没弄清楚的故事~
在这条道路上，我们似乎画地为牢，又似乎和正确的道路渐行渐远，认真回忆起来，也确实值得反复咀嚼。不过长歌当哭，必在痛定之后。
团队合作：
哦，团队，我们还是个“业余剧团”，什么，我是PM，负责更博并催更博吗？开个玩笑~
其实我们团队的模式是相互驱动，毕竟大家的任务区分开来之后，能掌控全局的就没有人手了。所以争吵，妥协，无可避免~但对彼此任务的不理解，消磨着彼此的耐心。比如说，我最开始负责的词典翻译部分，是解析在线查词api返回的释义，从json格式抓取出来之后还要完成数据格式转换拼接成string，控制模块才愿意接收，所以后来的popUI的数据转换也必须自己完成。这不仅降低了效率，也人为的割裂了词典和我们的软件。所以从这时候开始，我们和词典负责人没有再次接洽，查词只是作为一种工具存在。老师在review是总是提说能不能和词典的其他部分结合，所以我们加入了导入导出生词列表的功能。毕竟从数据格式上，他们已经是两个东西了~比如说，没有设置测试员，自己设计好的模块，自己搭个环境全方位调试好，测试好，还要等对方做好才合起来检验~比如各个同学相继返校考试或其他，耽误了工作进程，各司其职又导致项目停滞。。。其实完全可以设置一个负责测试，同时也能掌控全局，协调各方的职位，PM~然而我们实际的PM，却只是完成自己项目之余volunteer负责组内各项事宜的人，组内的很多事情也是大家激烈协商，友好妥协的结果~
我们是一个饭团，也是一个成长中的团队。
个人进步：
blog可查，我的任务均顺利完成，返校时间短，团队项目没有在我的部分受到限制或拖累。
最后美工部分受到各种质疑，我只表示，删张图只是注释一下的事情~
从小白到伪小白，我的技术之路前进了一大步~
关于团队合作，关于软件开发流程学习，亲身走过一遍，受益匪浅~
经验教训：
必须充分调研，在时间有限的情况下，依赖尽量成熟的标准；
建立科学有效的管理机制，包括版本控制和人员控制；
平衡项目和工作，重要的事情才不会变成紧急的事情；
团队工作能力第一，沟通第一；
和团队以外的人加强沟通，聆听他们的建议，帮助项目成长；