一、团队开发总结
我在窝窝头团队中担任网站后端dev，从事数据库相关工作。
一） M1阶段
M1是第一次接触团队开发与敏捷流程，诸多地方都有很深的感触。
- 对网站开发的初次尝试
我们的项目是北航社团平台管理网站，是以学生和社团之间的交流为需求的网站。这也是自己首次参与开发网站，一开始自然对网站开发一窍不通。初期学习成本巨大，外加自己的学习效率偏低，进度一直是小组中最慢的。这也导致自己在M1阶段贡献比较低。但随着开发过程的深入，自己也慢慢理解了网站前后端的交互，了解了ruby on rails，了解了API文档的作用。M1的一个月可以说是一个真正的拓展网站开发经验，锻炼能力的经历。
2. 团队开发
依然是第一次参与软件团队开发。之前虽然有和其他人共同进行课程实验或者简单参与过项目开发，但参与这样有严格审核标准、有软件开发理论模型支持的开发流程的确是让自己领略到了软件开发中的大学问。现在的大环境下，团队开发在软件开发中会占据越来越重要的位置。这门课程无疑为自己提供了一个宝贵的实践机会。
同时，开发过程让自己明白了做任何事，规范化与理论背后的支持都是不可少的，也对软件团队模式（功能团队模式）以及团队开发流程（敏捷流程）有了初步的了解与实践。
3. 敏捷流程的实践
从事敏捷开发的感触贯穿整个学期。Sprint、Backlog、Scrum meeting、PM这些之前接触极少的词汇伴随自己这几个月。这段时间的实践让自己明白了及时应对需求变化在软件开发中的地位，让自己看到成员之间的迅速沟通、面对面交流是怎样提高团队开发效率的。
自己在开发过程负责了很长时间的Scrum管理工作（也就是所谓的Scrum master），经过每天整理scrum的体验后，感受到了这一形式的重要作用。每天强制抽出时间，让成员报告进度，迫使大家把问题摆在明面上；同时通过燃尽图与TFS任务真是有效地反映当前进度；让时间驱动冲刺阶段，让可见的数据驱动开发。这种做法在我看来能有效避免开发过程的中盲目与低效，同时有利于根据需求变化及时调整
4. 文档的重要性
开发中采用API文档作为前后端交互标准，无疑省去了大量的麻烦。再一次体现了规范的意义。
二） M2阶段
这个阶段最直观的体会就是时间紧&累。
有了第一轮迭代的基础，几乎不再需要新的学习成本，对整个开发模式也已经较为了解。但M2过后却感觉并不太满意。主要就是严重低估了外部因素对软件开发的影响——其他学科的课程实验与考期对软工开发的巨大冲击，严重到在长达2周多的时间内开发进度处于近乎停滞的状态。
但这轮迭代仍然有一些好的收获：应对需求变化更加及时灵活，团队协作更加流畅，对代码管理工具的应用更充分当然还有自己对后端API的实现更加熟练更加有效率。
二、重看开学时提出的问题
问题地址 http://www.cnblogs.com/wcysoftware/p/4837147.html
2、4、6未解决，其他已解决
已解决
- 个人认为“大马哈洄游“的确是学习软工课程的一个有效办法。学习应该与真正的现实开发区分开来，一如课本中的软件工程师的发展，先由下往上继而一泻千里。这不仅是通过看课本得来，更是在两轮迭代后的直观感觉，在没有基础的情况下进入一个新领域，从最基础层做起肯定是最合理的。
3. 这两种开发方式这学期都尝试过了，自然就对这个问题有了感悟。结对与团队最大的不同，就应该是名字上体现的——两人开发与多人开发完全是不同的概念。结对编程中的两人角色往往可以互换，而在功能团队模式中这就显得不切实际。结对编程两人合作一般更加方便，诸如开会甚至开发时完全可以找到共同时间选一个场合一起开发；但在团队开发中，要找到一个所有人都能出席的时间并不容易。但同时，团队开发中的完善功能区分以及诸如敏捷流程中的scrum都是结对编程无法实现的。所以个人认为就是结对编程适合较小且周期较短的项目，团队开发适合工程量大且开发周期长的项目，可以讲它不如结对编程灵活的弊端降到最低，同时能发挥功能全面、规范化强的特点。
5. 依然是在两轮迭代中得来的体会。PM最重要的两点特质：对所作项目的理解与整体把控、管理团队与保持团队平衡的能力。代码开发能力不是PM的必备能力，PM应该是那个能为团队指明方向并且在遇到困难时能进行调整带领团队前进的人。
7. 极限编程的特点主要体现在4点：加强交流；从简单做起；寻求反馈；勇于实事求是
所以极限编程是十分灵活且能真是反映用户需求的。但这一切都建立在开发者是否操作得当上。缺乏经验往往是致命的，尤其是在寻求反馈上，未能及时调整项目目标的话会造成效率的低下。除此之外，面对大型工程采用这种方式未免显得压力太大。
未解决
- 未接触这门课之前，可能会脱口而出答案：创新。但经过学习后，却不再清晰。软件团队模式，开发流程乃至软件工程中的各种理论与方法论，哪个才是推动软件生产力发展的决定因素？正如那篇有关“银弹“的文章，可使软件工程的生产力真正提升的关键在哪里依然存在争议与疑问。
4. 纸上得来终觉浅，绝知此事要躬行。我们现在只尝试过功能团队模式和敏捷流程开发，其他的团队模式以及开发流程的开发效率没有经过实践无法做出定论。
6. 在两轮迭代中，我们的主要用户是学生以及社团，是与我们的生活十分贴近的实体。这让我们在分析用户需求时显得极为简单——只需将自己带入情景，进行情景分析，就可知道用户最想要什么。但如果涉及到我们不了解的领域和行业，想真正做到立足于用户，就需要大力度的调研与分析，这是我目前不了解的地方。
新问题
如何对任务时间做出精确的评估？包括开发周期乃至每个任务的耗时
这是在迭代过程中经常遇到的问题，在做规划时制定出的任务时间往往与实际花费差距巨大。甚至到了后期计划时间完全没有参考意义。
三、阅读文章新体会
Agile Method – by Martin Fowler
你的团队在开发中用了那些敏捷的思想和做法?
经过两轮完整的迭代，对敏捷开发有了更深的体会。但这次主要是我们团队做的不好的2点。
- 开发原则1：尽早并持续地交付有价值的软件以满足顾客需求
个人认为其实是敏捷流程的核心——寻求反馈。开发的目标不是以在截止日期做出一版能满足基本需求的产品，而是能够高效的做出产品交付给用户并根据反馈不断进行调整更改，使之尽可能符合用户需求。这一点我们明显做的不够。我们的发布日期过于晚，获取用户反馈的时间很短，根本无法做到敏捷的这一原则。产品似乎只是为我们开发者量身定做，而不是为用户准备的。因为绝大多时间，这款产品只是被我拿来不断使用。
2. 开发原则2：欢迎需求的变化，并利用这种变化来提高用户的竞争优势
这种需求的变化，个人认为可以是根据外界情况做出的目标调整。团队在开发过程中（还未交付用户）发现之前的设计有不周全或者多余的地方，及时调整计划就是一种欢迎需求变化的体现。在第一轮迭代中，一开始设想的商城、网盘、消息推送之类的功能，在开发中期就被认定为是”非迫切的“需求；但直到第二轮才真正的舍弃掉。导致M2初期仍花费了时间去学习，影响了效率。无法大胆地迎合需求变化，调整计划，是我们这次迭代存在的一个巨大问题。
四、各阶段学到的知识点
1. 需求：NABCD模型需求分析方法
2．设计：典型用户与场景分析——这是用来分析设计产品功能非常有效的办法；实体关系图（E-R图）——设计模块、交互的直观化的工具
3. 实现：结对编程中的实现部分——灵活、有效的编程方式，不但可提高效率，其复审制度更能提高代码规范度以及代码质量
4. 测试： 压力测试与黑盒测试——对于网站而言，压力测试必不可少，而黑盒测试则可以看成新用户刚接触产品时各种操作的另一种形式
5. 发布：敏捷开发中的持续交付，经常发布——发布只是为了更好的迎合需求的变化，从而发布更好的产品