该文档探讨了敏捷软件开发的理念与实践，包括团队协作、快速反馈和持续改进的原则。强调了面对面的沟通和自组织团队的重要性，同时提出了实施敏捷方法的策略与建议。文中还体现出对团队氛围和有效沟通的重视，以及不同情况下选择适合的敏捷实践的灵活性。

1. 敏捷软件开发 ——一个实践者的思考 上海研发中心商户集成组 普渡 2009-05-12

2. warning 以下分享代表了一个敏捷实践者的价值观，纯属一家之言，如有巧合，实属雷同 ! The following presentation represents values of a practitioner of agile methodology. It is personal. If there are something same to that, it is coincidental.

3. 我们的远景

4. 时而我们前进的路很清晰

5. 因此，我们高兴，步履轻盈！

6. 时而，又迷雾重重！

7. 因此，我们也会失落…

8. 但我们坚信，希望——

10. 团队的成功 软件开发是协作者之间的游戏 —— Alistair Cockburn

11. 没听过敏捷软件开发？

12. 进行过敏捷软件开发的实践？

13. 目标 开始尝试敏捷软件开发实践

14. 内容提要 软件开发的现实 敏捷软件开发介绍 敏捷实战体验 实施敏捷软件开发方法的建议 敏捷巡游

16. 如何保证不失真？

17. 回到现实 业务变化 信息烟囱 进度延迟 复杂性膨胀 系统恶化 需求误解 人员调整 效率低下 单点故障

18. 几个问题 你的困惑？ 软件开发——工程还是艺术？ 从上海到北京的走法？ 走的快，还是跑得快？ 走的稳，还是跑的稳？ 跑一定不稳吗？

19. 内容提要 软件开发的现实 敏捷软件开发介绍 敏捷实战体验 实施敏捷软件开发方法的建议 敏捷巡游

21. 敏捷软件开发原则 尽早的，持续的发布软件以满足用户对软件的需求。 欢迎用户改变需求，即使是在开发后期。 经常发布软件，从几个星期到几个月不等（迭代开发）。 业务人员和开发人员一起工作（现场客户）。 有激情的开发人员，给他们支持和环境，相信他们能把工作做好。 最有效的方法是面对面的沟通。 良好节奏的开发过程，保证开发者，用户，客户的步调一致。 衡量项目进度的唯一标准是能运行的软件，而不是文档和散落的代码 持续关注技术和设计，好的设计带来灵活性（重构）。 简单化原则（简单设计，只考虑目前的需求）。 自组织的团队，最好的架构，需求和设计都出自这样的团队。 团队应该定期的反思和调整使团队更有效率。

22. 极限编程（ XP ）的价值观 沟通 简单 勇气 反馈

23. 极限编程（ XP ）实践 计划游戏 (The Planning Game) 结对编程 (Pair programming) 测试 (Testing) 重构 (Refactoring) 简单设计 (Simple Design) 代码集体所有权 (Collective Code Ownership) 持续集成 (Continuous Integration) 现场客户 (On-site Customer) 小型发布（ Small Release ） 每周 40 小时工作制（ 40-hour Week ） 编码规范（ Code Standards ） 系统隐喻（ System Metaphor ）

24. Scrum 实践 产品负责人（ Product Owner ） 每日站立会议（ Daily Scrum ） Sprint 计划会议 用户故事 Sprint Review Sprint Retrospective

26. Lean—— 精益软件开发原则 消除浪费——没有对客户产生价值，就是浪费 增强学习——软件开发是发现过程，而不是生产过程 尽量推迟决策——是决策而非预测，压缩不确定性 尽快交付——快鱼吃慢鱼，压缩价值流 授权团队——自适应团队 嵌入完整性——感知完整性和概念完整性 着眼整体——系统化思考

27. 升级包价值流图（ Lean ）

28. 消除浪费——连续式沟通（ 1 ）

29. 消除浪费——连续式沟通（ 2 ）

30. 内容提要 软件开发的现实 敏捷软件开发介绍 敏捷实战体验 实施敏捷软件开发方法的建议 敏捷巡游

31. 行不行？走两步

32. 那就开始实践吧！ 每日站立会议 团队计划会议 以周为单位的工作周期 坐在一起 结对编程 项目看板 集体分析和设计 反思回顾

33. 每日站立会议 开门三件事 昨天做了什么 遇到什么问题 今天打算做什么 沟通依赖 沟通信息 沟通知识 进入工作状态

35. 团队计划会议 统一上下文 集体评估任务 让听见炮声的人参与决策 类似 Scrum 的 Sprint 计划会议

36. 以周为单位的工作周期 Scrum ， 30 天一个迭代 时间上的连续性 任务不要超过 5 天 一个自然的工作节奏。

37. 坐在一起 开发测试需要坐在一起。 隔间，背靠背是比较合理的排布方式。 回头和侧身就可以和相关的人建立交流。 保持持续的沟通和反馈，沟通没有死角

38. 结对编程 互相学习 互相讨论 互相检查 互相督促 持续的 Code Review 专家＋新手：快速入门，上手工作。 专家＋专家：关键模块，解决疑难问题。 常见的错误理解：所有任务都结对

39. 看板 信息辐射器（ Information Radiator ） 公开任务信息 公开风险和问题 公开本周关键任务 图表 燃尽图 总体 bug 趋势图 日 bug 趋势图（每日发现和解决的个数）

40. 项目看板 - 开发阶段

41. 项目看板—测试阶段

42. 看板一角—任务表和燃尽图

44. 集体分析和设计讨论会 盲人摸象 集体以获得概念完整性 设计决策的随时 check 场景：系统复杂，超出一个人可以理解的范畴 角色 导航者：引领讨论的主题和方向 参与者：分别在当前上下文，贡献自己的理解。

45. 反思总结 曾子曰：“吾日三省吾身——为人谋而不忠乎？与朋友交而不信乎？传不习乎？” 曾广贤文：“学如逆水行舟 , 不进则退 ; 心如平原放马 , 易放难收 .” 坚持提高团队效率的实践 去除或改造制约效率的实践

46. 内容提要 软件开发的现实 敏捷软件开发介绍 敏捷实战体验 实施敏捷软件开发方法的建议 敏捷巡游

47. 实施策略 反对教条主义：全盘按照既定方法学实施。 毛泽东思想：解放思想，实事求是。马克思主义在中国的最佳实践。 将方法学打散成最佳实践的粒度，不要迷信任何一种方法学。 Think why ， then think how

48. How to get started? 思考团队正面临什么样的问题。 根据具体问题，选择敏捷 Catalog 中的相应实践。 在团队中进行尝试，并根据具体情况修改实践。 团队一起进行反思，发现哪些做的好的，哪些做的不好的。好的继续坚持，去掉或改进效果不好的实践。 开始下一轮改进循环。

49. 什么是最重要的？ 团队气氛 积极沟通 持续关注 持续改进 减少浪费 不要完美

50. 编程心理学角度看人与方法 方法过程非常详细，人就按着步骤执行就可以了，人的不同能力对编程不会有多大影响。 如果只有高层次的指导方针，每个程序员都会有不同的诠释，人的能力对结果就有很强的影响力 如果没有任何方法，就完全依靠人的能力了。

51. 内容提要 软件开发的现实 敏捷软件开发介绍 敏捷实战体验 实施敏捷软件开发方法的建议 敏捷巡游

52. 国内情况 UT 敏捷实施（ 70% 的团队实施 Scrum ） 华为敏捷实施情况（从 CMMI5 到 Agile ） 转折点 , 开始逐渐接受 仍然处于实践和探索阶段

53. 办公地点

56. 贴满墙的用户故事卡

57. 故事看板

58. 故事看板

60. 结对编程

61. 远程结对编程

62. 构建指示器

63. Everything is trade-off 方法学的本质是什么？ 如何在周边开始实施敏捷软件开发实践？ 要进度还是要质量？ 重量级还是轻量级？ 是意识缺失还是缺乏行动 ? 家俱警察？ 如何保持团队士气？ 如何保持概念完整性？（复杂系统，持续演化）

64. 敢 问 路在何方？

65. 参考资料 解析极限编程 - 拥抱变化 敏捷软件开发 - 原则、模式、实践 软件过程管理 . 朱少民 代码大全 Crystal Clear- 小团队的敏捷开发方法 统一软件开发过程 超越传统的软件开发 - 极限编程的幻象和真实 Lean Software Development——An Agile Tookit The New Methodology. Martin Fowler