实施改进的五种策略
September 30th, 2009
- 跳跃（Leap）：当我们知道改进的目标，知道改进的手段，并且这个措施不会对团队造成大的冲击、或者改进过程越长只会越痛苦，那么就一步到位，直接跳到正确的结果，不再回到从前不佳的做法。
- 并行（Parallel）：如果我们知道目标和手段，但实施改进会造成较大冲击，并且小范围的改进也可以带来收益，那么可以先做小范围改进，与从前的做法同时存在一段时间，然后逐步推广到全局。
- 阶石（Stepping Stone）：如果我们知道远景的目标，但对于到达该目标的路径尚不清晰，可以朝着正确的方向先迈出一小步，稳固改进成果，发现问题，再迈出下一步，如此朝向目标逐渐推进。
- 简化（Simplification）：如果我们看不清远景目标，只知道一个大概方向，可以将正确的方向简化为一个可实施的、初具形态但不完备的目标，从而迈出改进第一步。
- 暂停（Pause）：如果我们完全看不清远景目标，或实施该方面改进所需的依赖条件尚不满足，应该将此方面的改进暂停，仍然保持现有的做法。暂停不等于失去跟踪，随着其他方面改进的深入，远景目标可能开始清晰，或者依赖条件逐渐具备，就可以考虑重新评估暂停的改进项。
采用适当的实施策略，是为了实现安全的流程重构。过程改进不是砸烂重来，不是破旧立新，不是脏水孩子一起倒。流程重构和代码重构一样，一切的改进必须建立在保持现有系统仍然工作的前提下。
基本的套路：（1）了解现状；（2）制定目标；（3）发现改进项；（4）选择实施策略；（5）跟踪反馈。
就这么简单而已。
Refactoring And Design, In A Real World
September 27th, 2009
Martin Fowler在《重构》里如是说：
如果你选择重构，问题的重点就转变了。你仍然做预先设计，但是不必一定找出正确的解决方案。此刻的你只需要得到一个足够合理的解决方案就够了。你很肯定地知道，在实现这个初始解决方案的时候，你对问题的理解也会逐渐加深，你可能会察觉最佳解决方案和你当初设想的有些不同。只要有重构这项武器在手，就不成问题，因为重构让日后的修改成本不再高昂。
如果做设计的人和写程序的人不是同一帮人，如果写程序的这帮人好不容易学会了写程序然后就会被拉到另一个再也不写程序的位置上，好吧，我们还怎么使用重构这把利器？
对此，我比较悲观。
《ThoughtWorks文集》中译本序
September 19th, 2009
这本《 ThoughtWorks文集 》中译本面世之际，也正值“敏捷中国2009大会”召开在即。两者可谓相得益彰。
从2004年进入中国，ThoughtWorks见证和参与了中国敏捷社区的发展历程：从五年前的筚路蓝缕，到如今的欣欣向荣。更令人欣慰的是，在原则、价值观等“大问题”上，敏捷的实践者们已经基本达成共识，社区的话题更加趋于关注实践──这意味着敏捷社区正在步入成熟，将用他们的知识和技能为各自效力的企业创造更大的价值。
我们在这个时候把《ThoughtWorks文集》翻译出版，是希望为社区的发展再尽绵薄之力。作为敏捷方法的积极推动者，ThoughtWorks从多年、多个行业的实践中积累了丰富的经验。本书收录的13篇文章涵盖了编程技术、项目管理、持续集成、测试等方面内容，将带领读者了解ThoughtWorks在软件生命周期各个环节所推荐的工作方式。
比较难得的是，这本《文集》不仅由ThoughtWorks员工撰写，也由ThoughtWorks员工翻译。译者们或是与文章作者素有私交，或是在文章所论述的领域有所专擅，这也使得翻译的质量更有保障。感谢这些译者在工作之余的辛勤翻译，才使这本《文集》如期付梓。他们是：韩锴，胡振波，金明，李剑，乔梁，熊节，徐昊，张晓庆，郑晔。
一本薄薄的《文集》当然不可能解决所有问题，我们更希望它能够收到抛砖引玉的效果。希望ThoughtWorks的经验心得能对国内的敏捷实践者们有所启发，帮助他们做出更多创新，创造更大价值。最后，希望你阅读愉快。
郭晓 总经理，ThoughtWorks中国公司
