M1&M2总结
软工最后的团队展示终于结束了，一个学期的软工历程也算有了一个比较完整的体验，自身从原本没有一点点的软件开发经验到现在参加了一整个软件的生命历程并且坚持下来，内心的体会也是非常的复杂。在结束了这学期大部分事情后，现在终于可以停下来，好好总结一下这歌过程得与失。
在团队阶段中，我的角色是一个后台开发人员和测试人员。之前我已经在一个大创团队工作了一个学期，原本我以为一个开发人员的工作应该和我之前的感觉差不多，但是之后发现我大大的错了。现在回顾来看，其实我们在团队阶段中的角色远没有职责定义那么简单，我们是这个软件的缔造者、创造者，这个软件的设计到开发、到发布、到维护，都与我有着极大的联系。我受到的锻炼是比较系统的软件工程体验，绝不是简单的开发一点代码的感觉。
首先在项目启动前的准备阶段，我们需要开会商讨软件的题材、市场定位、软件类型、开发环境等等问题，同时在这个阶段我们还需要学会与新认识的队员进行沟通磨合。领域陌生、人员陌生、技术陌生，我们团队就这样开始了Lets的开发。在分析需求阶段，我学习着如何设计挖掘需求的问题，将自己代入用户的情境中去判断用户希望我们的软件为他们解决什么样的现实问题，并学着对我们自己设计的调查问卷进行统计分析。在做完这些之后，我们还需要制定我们的代码规范，开发过程中的管理规定，源代码管理方案，不同职责成员之间工作进度与设计协调方案等等。这些方案与规则的设计主要是有PM负责，但是作为团队的成员都应该参与整个制定的过程，这些必要的文档和方案的制定让我领悟到真正的软件工程被称之为“工程”的大致原因，因为这样的处理方法或者说处理环节是通用于所有软件开发过程的，我也逐渐进入一个软件开发的情境中。
在开发过程中，我们需要对确定的不同的需求进行功能设计以及任务分配，整个团队来协同完成软件的开发。在整个开发过程中有体会比较深的有几点。
1.个人利益与团队利益的冲突
尤其在M2阶段，编译大作业、数据库大作业、还有各种考试，一起压在身上，使得我们都喘不过气，个人的作业完成都看不到头，但是这边还有一个团队的任务没有完成。但是我们应该要明白，无论是个人的任务，还是团队的任务，对于我们而言都是应负起的责任，无论哪一个都不能轻易抛弃。所以我渐渐能够对每一项我要完成的任务进行预估时间，然后合理的安排我的时间，尽量不浪费时间的情况下，产出最大。
2.PM管理与团队交流
整个开发过程中，我们团队实际上采用的是敏捷开发的模式，正是这样的模式我才体会到我们团队惊人的能力与工作效率。当然这离不开我们团队的PM的管理与协调，在阿尔法阶段我们的团队中发生了多次的摩擦与争吵，有关设计的、有关软件设计框架的、有关任务进度的、有关任务优先级的……现在的我大概能摸索出一些门道，一个团队产生矛盾是必然，一旦产生矛盾，成员需要以积极的态度来通过交流解决矛盾点，PM在这个时候的角色显得比较重要，需要他／她来实现搁置矛盾，寻求解决方案，保证开发进度。
3.设计原则和代码规范
代码的开发的具体过程中，应该有团队约定好的设计原则和代码规范在发挥持续作用。设计原则的意义在于，使得整个软件的代码看起来比较统一的风格和结构。比如我自己在开发的时候，有一次忘了自己的设计原则，没有将一个小功能部件的代码进行很好的封装，而是直接把代码写在了一个UI方法中，并且代码行数、体积都很大。后来我想复用该处代码的时候就发现非常的困难。而代码规范也是一样的，不同的人的变量命名若是不遵守统一的命名规范那么被人读起来将十分耗费精力。
最后，发布后我明白了收集用户反馈，修正自己对于软件的定位以及需求是一个提高自己软件很重要的途径。开发者最初对于软件的定位和需求的确定很有可能存在偏差或者不全面，所以通过真正的用户反馈、最真实的使用体验来完善软件是十分重要的方法。
最后的最后，当然要感谢下Chronos的所有成员。大家的热情、积极和责任心让整个团队都充满了凝聚力！～～～
阅读问题
原问题链接：http://www.cnblogs.com/nightcool/p/4830459.html
1.结对编程
在体验过结对编程和团队编程后，我明白了结对可以有不同的模式，可以只有一个人编码，一个人复审；也可以两个人编不同的功能，通过代码复用交叉进行交互。两者的交互往往能带来质量或者效率的提升。
2.单元测试
在个人项目中曾经尝试过写一些单元测试，单元测试的目的是为了检测模块或者函数内部对外部满足的逻辑条件是否在所有情况下都满足。每个函数或者方法都有其前置后置条件，即其对调用者可以提一定的要求，这样可以将部分错误处理在调用前就消除。
3.敏捷开发
在真正的体验过敏捷开发的团队过程后发现，敏捷开发的中间，我们是不会对需求进行大的改动，况且每次敏捷开发的目标往往都是一个比较小的需求和功能的实现，这样就能够保证敏捷开发的最重要的敏捷这个指标。若需求真有改变，那也是需要在这一个小的开发过程之后再进行修改的。
4.用户体验
首先用户UI这个方面我只有一点审美感觉而已，故不多赘述。用户体验我现在看来，用户体验有两个很重要的性质流畅性和完整性。流畅性可以由开发人员设身处地的思考假设来挖掘。但是完整性很多情况下需要真实用户对app进行评价反馈，从他们的体验中挖掘不合适、不完整的部分来进行改进。
文章
其中体会较深的应该是敏捷开发模式。由于这学期的课业压力之大，我们必须在有限的时间内完成大量的任务，这样紧迫的条件采用敏捷开发模式是再合适不过的了。然而在Alpha阶段我们并没有采用敏捷开发模式，抓着一个方面就不放，一直想把它做得尽善尽美，这样的方式极大地降低了我们的开发效率。实现敏捷开发一个关键点即确定任务的优先级。于是在Beta阶段，我们吸取教训，对于不必要，性价比不高的功能，我们给予其较低的开发优先级。始终将主力用于必要功能的实现。那么什么样的功能才是必要不多余的呢？首先必须从用户的角度出发，按照测试场景代入，如果我们是用户，我们希望它能有什么样的功能来满足我的需求？
另外一个是大泥球的问题，由于自己犯下的错误所以记得特别深刻，自己留下的大段代码，在第二个阶段影响到了自己的开发效率，所以自己解决了这个问题。
知识点
需求：
在分析用户需求的时候不能带入开发者本身的臆测，将自己实际带入到用户视角中去；同时，为了更真实地贴近用户、发掘潜在需求，调查需要深入到真实用户群体中去，调查问卷不失为传统有效的方法。最后通过用户的反馈来修正或者增加需求也是很重要的。
设计：
设计软件的框架要保证开发效率以及最后的实际效果。开发的最终目标当然是实际效果可用切良好，但是也不能忽略开发人员的开发效率，否则到发布日期连产品都没有，何谈效果。
实现：
作为成员在实现的时候需要保障组内的信息流通，遵从代码规范，同时始终保持一个开发模式坚持下去（如敏捷开发）。提高代码重用率，避免为了赶工而产生的临时权宜之计，使得工程中有四处扩散的大泥球。
测试：
我们的小组在开发过程中没有进行单元测试，而是进行了格外详尽的功能测试。虽然功能测试能够从高层次直接快捷地找到问题所在，但客户端本身的逻辑单元测试也是很关键的。这也是我们开发过程中做得不够的地方。
发布：
发布时需要定义好出口条件。出口条件需要考虑用户使用软件的使用体验完整性，这一点很重要，不然软件某一部分功能再强大也会产生木桶效应，导致用户对软件的评价越来越低。
维护：
要设立必要的反馈机制。通过反馈机制我们能够收到真正用户的切实感受，软件发布后，我们的Let’s也通过反馈机制收到了许多宝贵的建议。这些建议都是后期改进的重要参考。同时需要由开发人员及时记录新发心的bug和修补bug。
