敏捷软件开发 从“是否 敏捷 ”到“如何 敏捷 ” 李默

李默

About Me 李默 / 冰云 (icecloud) 高级咨询师、业务分析师、敏捷教练、社区活跃分子和组织者、 Blogger 、 Twitter About

有谁 没有 听说过敏捷方法？

有谁 正在实践 敏捷方法？

谁认为自己敏捷实践是 成功 的？

敏捷方法适合 互联网 产品吗？ By http://www.flickr.com/photos/stabilo-boss/93136022/

一个 互联网 产品采用 敏捷开发 的案例

20 人的开发团队，近 3 年的持续发布，数十个第三方集成点

结果：频繁 的 交付和 反馈周期使得产品质量和用户满意度不断提高 By http://www.flickr.com/photos/mmoorr/348606055/

哪些公司 已经 采用敏捷方法？

已经采用敏捷方法 的公司

敏捷 开发 方法已经逐渐成为主流方法 By http://www.flickr.com/photos/mychatham/206928250

许多公司已经不再犹豫 问题正在从 WHY 变为 HOW By http://www.flickr.com/photos/ntr23/730371240

他们面临的 问题 是什么？

调查问题：继续推进敏捷的 阻碍 是什么？ VersionOne AgileSurvery 2008

分析和解决问题之前 先对 敏捷方法 做个 小回顾 By http://www.flickr.com/photos/shutterberry/75692645

软件危机 1960 1970 1980 1990 2000 2010 软件工程的提出是为了解决软件危机

软件危机 1960 1970 1980 1990 2000 2010 瀑布模型 瀑布模型是第一个软件工程方法，也叫顺序线性方法

软件危机 1960 1970 1980 1990 2000 2010 瀑布模型 原型模型 原型模型是为了解决瀑布模型中的问题被提出

软件危机 1960 1970 1980 1990 2000 2010 瀑布模型 原型模型 增量、螺旋模型 增量和螺旋模型综合了瀑布和原型模型，并更进一步

软件危机 1960 1970 1980 1990 2000 2010 瀑布模型 原型模型 ISO 增量、螺旋模型 ISO/IEC 12207 制定了软件生命周期标准

软件危机 1960 1970 1980 1990 2000 2010 瀑布模型 原型模型 重量级方法 ISO 增量、螺旋模型 按照 ISO 要求综合了以前模型的所有特点的重量级方法

软件危机 1960 1970 1980 1990 2000 2010 瀑布模型 原型模型 重量级方法 ISO 增量、螺旋模型 CMM CMM 衡量一个过程的成熟度方法

软件危机 1960 1970 1980 1990 2000 2010 瀑布模型 原型模型 重量级方法 ISO 增量、螺旋模型 轻量级方法 CMM 反文档、反重型、重视交付速度的一系列方法

软件危机 1960 1970 1980 1990 2000 2010 瀑布模型 原型模型 重量级方法 ISO CMM 增量、螺旋模型 轻量级方法 敏捷方法 轻量级方法的大融合

敏捷宣言 , 2001

说过一百遍的敏捷宣言 人和交流 胜过 过程和工具 可工作的软件 胜过 面面俱到的文档 客户协作 胜过 合同谈判 响应变化 胜过 遵循计划

人和交流 胜过 过程和工具

可工作的软件 胜过 面面俱到的文档

客户协作 胜过 合同谈判

响应变化 胜过 遵循计划

SCRUM 49% VersionOne AgileSurvery 2008

XP 30 ％ VersionOne AgileSurvery 2008

技术 团队 组织

交流 反馈 简单 勇气 尊重 XP 的价值观

交流

反馈

简单

勇气

尊重

用以支持敏捷方法的 工具

敏捷开发工具 几乎涵盖了所有开发语言 Java B/S Java C/S .Net C/S .Net B/S RoR Tradition RoR Fashion iPhone Mac PHP JUnit NUnit RubyUnit RSpec GHUnit phpUnit OCMock RhinoMocks JMock Selenium Ant DBUnit Abbot WHITE EFT watiN Selenium macinist NAnt MSBuild Twist webrat cucumber rake rake C++ cxxTest make mockCpp cygwin SQL Lite PersistObject Selenium DBUnit.net

开发工具之外的一些容易被忽视的工具

需求和 项目管理 版本控制 发布管理 数据迁移 Mingle GIT/Hg Cruise DbDeploy Version One Rally SVN CruiseControl AntHill Team City

Mingle 集成了这些能力 #142 points: 4 View transaction list high *credits/debits Do we have a service we can access? *date *transaction ID *other account name Need to see: bsb/number Cards Card Wall Excel Wiki Bug Tracker SCM Viewer Reports

敏捷方法涉及了太多的 具体实践 和 工具 ，因此实践者容易迷失方向并导致各种问题，而问题的根源来自于 2 方面

过于强调技术、过程或工具而 忽视敏捷 价值观体系

经济人－》社会人－》自我实现人－》复杂人－》创新人

结论： 1 ：敏捷是思想和做事原则，而不仅仅是实践 2 ：采用敏捷方法对人有特殊的要求，即思想要向敏捷的价值观转变 3 ：对于具备敏捷价值观的人需要有相应的管理方法

团队的进化过程和相应的管理方法 无意识不能 (Unconscious Unable) – 命令式 无意识能 (Unconscious Able) – 教练式 意识到不能 (Conscious Unable) – 支持式 意识到能– (Conscious Able) － 委任式－自组织

无意识不能 (Unconscious Unable) – 命令式

无意识能 (Unconscious

Able) – 教练式

意识到不能 (Conscious Unable) – 支持式

意识到能– (Conscious Able) － 委任式－自组织

孤立进行某种实践却 忽视 实践 之间的 联系 和 依赖

交流和协作 质量和反馈 拥抱变化 价值驱动 团队责任 消除浪费 适应性 人 简单设计 重构 测试驱动开发 持续集成 短迭代开发 频繁发布 适应性计划 结对编程 集体责任 制 回顾与总结 站立会议 统一愿景 代码标准 用户故事 客户验收测试 自动化测试 用户交流 版本控制 验收条件 可视化管理

结论： 1 ： SCRUM 是相对独立的实践的组合 2 ：仅靠 Scrum 的实践并不能保证频繁发布 3 ：实践的基础是价值观，可以在价值观的基础上创新实践

敏捷转型和实施 建议 By http://www.flickr.com/photos/ul_marga/755378645/

1 ：版本控制、持续集成和自动化测试是所有实践的基础 By http://www.flickr.com/photos/pgoyette/2280685630

2 ：从采用 Scrum 实践开始，注重对价值观的培养和转变，尤其要重视交流和反馈 By http://www.flickr.com/photos/arguez/2247369944

3 ：正确利用 Retrospective 对团队进行自我改进 By http://www.flickr.com/photos/9550033@N04/3333852364

4 ：获得管理层的认可和支持 By http://www.flickr.com/photos/tjflex/233574885

5 ：如果推行遇到困难，寻求第三方咨询师帮助 :P By http://www.flickr.com/photos/mdt1960/67556153

Thanks Q&A