序二

很难形容当我看到这一篇篇实践经验时的感受。不光因为这些文章中所描述的经验也有我参与讨论的共鸣，我更是被这不停探索技术卓越的状态所感动。

回想2001年我在《程序员》杂志看到那一页描述极限编程的文章，震撼之后我深深相信这就是软件的未来。你可以想象一下连讲J2EE的书籍都充满错误的年代，找到关于敏捷软件开发的资料是多么困难的一件事情。在实际工作中，这些书籍更是缺乏最后一公里的力量。为了更加拉近信念与现实的距离，我加入了ThoughtWorks中国公司。在交付与咨询之余我们不停思考、不停质疑、不停总结。所以在你面前的这本书充满了最后一公里的力量，虽然有些内容在文字和理论方面略显单薄，但我相信你在阅读本书之后会更有信心地面对日常软件开发过程，也会再次注入更多的软件热情到你的身体之中。

过程改进部分，你可以理解以过程为形式的改进，所以重音在应该在“改进”之上。

看板任务管理：看板方法已经成为企业渐进式变革的一套方法论，其核心观点是把管理职责交还给知识工作者本身通过可视化的方法实现渐进式的管理。对于看板理论我非常留意我们说的是Kanban还是kanban（大写K哦），可以说文章更多地触及kanban落地的一些具体实践，并详细说明背后意图。

实战：持续交付中的业务分析：虽然业务分析的套路现在已经被“精益创业”，“商业模式画布”，“设计思维”等高大上的词语或概念所占据，但如果仅仅回到价值交付而言，看完这篇文章你会有一些基本思路来面对眼前的问题并引发更多的思考。

建设DevOps能力，实现业务敏捷：我认为熊节这篇文章是一篇非常好的宣传性文章，整体思路清晰，我看完之后有想动手实践的冲动。如果读者你也和我一样，建议你先拿文中的几个工具开始试验一下，我相信你的收获会更多。

自我成长时考虑精益的方式：熊子川这篇文章是精益画布的一个精简版本，看完之后我在思考我们是否需要商业画布上的这么多的部分，还是用这个精简的版本确定思路之后就着手制作第一个短裤版本的软件扔向市场。我个人感觉很多情况之下第二个选择就已经足够。

运用系统思考，走上改善之路：这篇文章非常切“改进”这个题目，强烈推荐。

分布式开发：敏捷的实践对于本地团队基本上是有一些最佳实践的，但是如何在分布团队也能实现敏捷呢？看看ThoughtWorks中国的经验吧。

精益创业和敏捷：两个都是大词，虽然当今的敏捷已经包罗万象，但如果给敏捷一个小一些的帽子并思考与精益之间的关系还是非常有必要的。

我和敏捷团队的五个约定：短短文章包含了很多内容，我个人觉得覃其慧可以用更多的笔墨来描述背后的故事。但这种留白也可以让读者思考自己环境下测试人员的状态与挑战，体会这五个内容背后的故事。

工程实践部分，此部分我认为是本书含金量最高的部分。如果你对其中的某些知识领域不感兴趣，建议你推荐给喜欢相关领域的朋友，相信他们会非常感谢你的推荐的。

团队建设，人始终是敏捷的关键挑战，读者可以在这里看看ThoughtWorks如何面对这个挑战的。

建设全功能团队——实践篇：看看胡凯是如何带好新人的。

建设全功能团队：看看胡凯是如何进行人员配置的。

高杠杆敏捷团队中的团队建设实践：看看ThoughtWorks的新人是如何快速提高技能的。

全功能团队——数据篇：看看跨职能团队的数据吧，如果你在乎“产能”的话。（虽然我个人非常反对使用这个词）

体验设计，好的开始是成功的一半，这也就不奇怪现在这篇文章放在本书最后一篇的重量。我非常认可纸质原型Paper Prototyping而非Visio或Axure此类原型工具这种观点。我相信这篇文章会给那些UX或UI人员以更多的弹药来面对敏捷转型的挑战。

羡慕你拥有这么多支持与资源之余，我开始有些担心你是否能承受这一软件经验的饕餮盛宴了。

敏捷教练 王宇