初始Agile Software Development

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

Agile Software Development 在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."，Martin Fowler有一篇关于如何对离岸offshore实施agile开发的文章。
3. 100%不能允许错误发生的项目，比如外科手术项目；
4. 如果团队成员本身不够能力敏捷，则不宜强行实施敏捷，agile需要的团队为少而精且人人都能自行管理并且是能cross-functional，还可能涉及到对不同文化的认可和适应。（如果了解一下ThoughtWorks对高级.net开发人员的JD, 就能大概了解agile对团队成员的要求了）。

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

在迭代过程中，可利用到一些提升编码质量和提高项目敏捷的技术、工具和方法，如 continuous integration, automated or xUnit test (如NUnit), pair programming, test driven development, design patterns, domain-driven design, code refactoring.

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

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

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

posted @ 2011-03-06 14:11  Elaine Shi  阅读(577)  评论(0)  编辑  收藏  举报