月度归档:2010年10月

对敏捷开发的一点认识

几天前参加了2010敏捷中国大会。因为以前没有对敏捷的实践经验,所以这一次的收获一不系统二不务实。下面把几点认识列出来,作为总结。

  1. 敏捷并非全新的一套理论和方法,实际上XP和Scrum等,比《敏捷宣言》更早出现。敏捷不是为了革命,而是对如何更好地为客户创造价值所做的一些改进。也因此,敏捷不等于抛弃一切原有的方法,实施敏捷,是一个逐渐的尝试过程。
  2. 敏捷不是银弹。首先,大量的实践表明它不能解决所有的问题,很多失败仍然发生;其次,并不是所有的项目都适合使用敏捷。对于需求较为固定和明确、能合理规划执行的项目,传统的开发方法反而有不错的效果。然而,绝大部分情况并不在此列。
  3. 是否切换到敏捷,有两种驱动力:一、现状中有无法解决的问题存在,很痛苦;二、管理人员对此很有信心,大力推动。诺基亚西门子的演讲人介绍了经验:先小范围实验,通过实效来让管理者认同。
  4. 敏捷的具体实施方法并不是固定的。这次大会多次对Scrum的标准认证提出了质疑。事实上,敏捷并不是一套完整的方法,我始终认为可以将其拆分开来,根据实际情况逐一评估和试验是否好用。每一种方法本身也应该有所改进,根据自身情况来试用。简而言之,不教条,吸取思想。
  5. 敏捷的思想可以分为几个层次:一、极限编程、重构、TDD等;二、流程改造、新的管理方式;三、持续集成和持续发布。国内的开发者往往一上来就想实施二、三,但一是技术基础,需要先行。
  6. 尽早发现问题、暴露问题,然后正视并共同解决。我觉得这是特别好的想法,是一种良性循环。但实际执行的难度不小——最初肯定会是问题最多的时候。这就像做Code Review,最初很痛苦,只有长期地实行了,才会稳定持续改进,而且每次的增量让人可以接受。
  7. 敏捷团队的沟通。团队内部、团队之间应该避免神秘主义、敞开交流。互相了解情况不但有助于水平的提升,还对整个项目有促进作用。在Scrum团队中,避免出现特立独行的分工角色,测试参与需求和设计、开发人员参与测试,都有助于把本职工作做得更好。充分的交流可以避免重复浪费,这一点有实际的体会。
  8. 管理者应该让每个人都明白团队的使命、责任、愿景、方向和价值,从而激发大家的积极心态。
  9. 对个人的品质要求:有强烈的学习意愿、主动迎接变化、持续的重塑自我、乐于影响他人。
  10. TDD:技术上,没有想象的那么简单。刚开始实施在管理上也会有较大的难度。有案例是一年左右才做到整个团队能自然地TDD,采取有经验的先行者带动其他人的方法。不必要对所有代码都TDD。
  11. 敏捷的快速响应变化,来自于各种自动化技术,包括自动测试、自动构建、自动集成、自动部署、自动交付……而持续改进则来自于持续集成、持续交付等。
  12. 站会。每人2分钟左右,将有必要告诉其他人的情况予以说明,遇到问题也可以提出来。
  13. 文档。不是no-document,最重要的功能定义文档是肯定需要的,而且应当具体。项目估算偏差较大,主要原因一般是对需求和功能的描述不具体。
  14. 版本控制。具体技术也许并不难,养成好的习惯、有版本控制的正确思维,才是需要引导的。
  15. 管理:减少管理力度,杜绝强制性命令。”Help others, not order.”