几年前就经常听过结对编程、每日构建、XP极限编程、Agile和Scrum了，可从未好好去了解它，纸上谈兵对我来说实在是件很难的事。可是，在接触到现在的外包项目一年后，我才在上个月后知后觉的发现，这个项目就是典型得不能再典型的Agile敏捷迭代模式，并开始对敏捷开发兴趣浓浓，力争要全面了解它，包括各种methodologies。之前在网上下载了好几本关于Agile与Scrum，还有了解了日本丰田Toyota的，并再延续着看了个人敏捷管理等，吸收了一些如何管理个人、任务和时间的知识和方法论。Agile和Scrum的书是多，可是一开始就觉得都太偏重应用了，于是今天就从下午3点起，开始在wiki上从开始一路了解，里面涉及到敏捷开发及XP等各种要求、各种方法论，不同方法的利弊等，为我展开了一处不算全新却很系统的画卷，让我能够为之后看此类书籍打下基础。在浏览的过程中，也手记了一些笔记，这儿粗略的整理一下。（实际上，自己去自行浏览，更好，帮助更大，这只是一篇wiki浏览笔记，我仅结合自身项目经验及能力，来记下其中我认为值得记录的）。

在2001年被提出，敏捷软件开发是基于迭代及增量开发的软件开发方法论的组合，在和的团队的协作过程中，这些方法论的需求和解决方案不断进化。

每个敏捷迭代中的流程都是完整的，从planning, requirement analysis, quote, prioritize, design, test case, coding, unit testing, acceptance test, code review, release, working，全部在一个周期在 1~4周的迭代中完成，如右图。

Agile声明中提到的12条准则为 （Twelve principles underlie the Agile Manifesto）：

1. 客户满意于快速交付可用软件；

2. 欢迎客户改变需求，即使是发生在开发后期；

3. 可频繁发布软件（周期按周而非月）；

4. 用实际运行的软件来衡量迭代流程的规则；

5. 可持续的开发，能被规律性的维护；

6. 业务人员及开发人员每日近距离协作；

7. 面对面沟通是沟通的最佳形式（即一同工作）；

8. 项目成员要主动积极且可被信任；

9. 连续性关注技术和设计；

10. 简化；

11. 自组织（self-organizing）团队；

12. 定期调整以改变结果。

Agile团队的局限性：

1. 敏捷团队通常都为5~9人，不宜过多比如多于20人，不过也有大型项目的敏捷成功案例，将大项目分割为多个小项目感觉也可以避免；

2. 离岸也会对敏捷造成不利影响，不过我目前的项目就正是离岸外包项目，感觉进行得目前为止还算顺畅，保持沟通顺畅且人员较少可避免；WIKI上有一段"the offshore team. . . should have expertise, experience, good communication skills, inter-cultural understanding, trust and understanding between members and groups and with each other."，有一篇。

3. 100%不能允许错误发生的项目，比如外科手术项目；

4. 如果团队成员本身不够能力敏捷，则不宜强行实施敏捷，agile需要的团队为少而精且人人都能自行管理并且是能cross-functional，还可能涉及到对不同文化的认可和适应。（如果了解一下, 就能大概了解agile对团队成员的要求了）。

敏捷方法不涉及到很大的任务，主张将大任务分解为小任务，来进行短期迭代。项目成员需要能够自组织（self-organizint）和跨功能（cross-functional），而不需要去理会管理的组织结构及每个成员的项目职责，人人均能自行全面负责被分配的任务（在一文中，agile也被定义为anti-management），并能参与面对面的每日会议（对offshore，则需要每日邮件,voice meeting等），向团队汇报前日工作并确定当天工作内容 - 参会人员中通常会有一名客户代表(customer respective)来确认需求优先级、及观察和审核agile流程和内容，并能回答迭代过程中出现的问题。

在迭代过程中，可利用到一些提升编码质量和提高项目敏捷的技术、工具和方法，如 , automated or (如NUnit), , , , , .

开发方法总体而言分为两种，一种是adaptive，即根据需求随时调整开发适应需求变化，都是短期任务；另一种是predictive，关注详细的计划，可以非常具体明确的对整个开发过程做出计划，开发过程中很难调整方向，因为整体计划已经根据初期目标决定好，一旦出现需求变理，需要使用change control board去确定最值得做出的变更开发。

---

一些知名的Agile Methods,

• (AUP)
• (DSDM)
• (EssUP)
• (XP)
• (FDD)
• (OpenUP)

延伸阅读：

• Self-organizing team, Self-directive team
• Cross-functional team
  对开发人员的知识掌握及尝试scope&depth要求较高，甚至有可能存在因为不需要与项目关系太大的学习目的，即捡啥学啥，所以在 中，Vikas提到了这种团队建设会存在开销甚至说明“This might lead to the scenario of doing major optimization on their own project which .”
• Pair-programming
• Code review, Code analysis tool
• NUnit test, TDD (test-driven development)
• Scrum
• Extreme Programming

敏捷初始，大概如上述，以后我会继续学习敏捷开发及敏捷团队，和各种敏捷方法。