Thoughtworks洞见

离岸BA顾名思义就是工作在离岸项目(offshore) 上的需求分析师（business analyst)。离岸交付面临的挑战是很多的，比如语言，沟通，客户关系，客户业务等等方面。作为offshore项目的BA，要把握好以下的10要。

在软件行业，或者说在程序员这个族群中，流行着这样一句话：不要重复造轮子。相对好的意思是应该尽可能用现有的实现来解决问题，而不太好的意思就是你太笨了，有现成的还要重写，醒醒吧？然而，纵观整个开源社区，几乎每段时间总会有各种各样的轮子被重复的造出来，不管是DI容器也好，还是MVC框架也罢。虽说随着语言的发展，有些新的轮子确实比旧的轮子优秀，然而大部分轮子都很快的销声匿迹了。当作为一个旁观者看到这样一番景象时，“重复造轮子是不好的”这个概念就会在你的大脑中被慢慢的强化，于是渐渐的，你就变成一个轮子的搜寻者，而放弃了作为一个轮子的创造者的机会。

通过引导、任务分配和沟通反馈等方式，让他逐步适应团队正常工作面临的压力、节奏和不确定性。对于一些心理预期过高的领导者，在此阶段应该明白，对于一个新手，还暂时谈不上能力判断和机会给予。

网站技术架构为什么会演进？我个人总结出来我们的技术架构演进的两种驱动力，驱动着我们为什么演进网站的技术架构：1. 内在驱动力：我们期望把当前的业务做得更好，开发更多新业务。2. 外在驱动力：用户量的上升、用户种类的多样化。

长期一来一直有个说法：“鱼的记忆只有七秒，7秒之后它就不会记得曾经的事情了，所有的一切又都会变成崭新的开始。所以，在那一方小小的鱼缸里面，它永远不会觉得无聊。” 当然这个美丽的谣言已经被一些死硬理派得人非常煞风景的辟谣了。

我会把收到的巨款用来置装，美容，健身。然后穿的花枝招展，抹的五彩绚烂，露出两条人鱼线。站在女程序员们旁边，给她们端茶倒水擦汗。并且忘掉我也可以是一个独立的个体，也可以通过某种其他的方式体现自我价值。成为一名雄性鼓励师，从此人生走上巅峰。

利特尔法则（Little’s Law）作为一个非常朴素的原理，为看板方法奠定了一个理论基础，看似简单的公式背后却有其复杂的一面。

在需要频繁交付、不断收集用户反馈、拥抱变化、追求业务敏捷的项目中，软件的开发和交付是迭代式进行的。在这样的项目团队中，BA（业务分析师）通常需要在一个开发迭代开始之前完成该迭代开发任务的分析。但在特殊情况下，从收集客户需求到将功能细节传达给开发团队的周期会缩短到一至两天。BA可以用于思考和分析的时间远远少于可以预先做出所有设计的瀑布式项目。

软件系统的稳定性，主要决定于整体的系统架构设计，然而也不可忽略编程的细节，正所谓“千里之堤，溃于蚁穴”，一旦考虑不周，看似无关紧要的代码片段可能会带来整体软件系统的崩溃。这正是我阅读Release It!的直接感受。究其原因，一方面是程序员对代码质量的追求不够，在项目进度的压力下，只考虑了功能实现，而不用过多的追求质量属性；第二则是对编程语言的正确编码方式不够了解，不知如何有效而正确的编码；第三则是知识量的不足，在编程时没有意识到实现会对哪些因素造成影响。

在长期运转的项目中，架构的腐化是怎么产生的？为什么常见的面向对象技术无法解决这类问题？如何延缓架构的腐化？

敏捷交互设计是敏捷方法论向交互设计领域的延伸，它提倡让所有相关人参与到设计过程中，迭代演进式地进行交互设计。从2010年开始，已经有越来越的团队在不同程度上使用敏捷交互设计的方法，而放弃了流程化的传统产品设计过程。

事实上，敏捷交互设计方法在很多方面都充分体现了敏捷价值观，因此，理解敏捷交互设计实践的最好方法是从记录在敏捷宣言中的价值观开始。

最近雷镇同学将Martin Fowler先生的著名论文《持续集成》第二版翻译成中文并发布出来，掀起了国内对于持续集成理论和实践讨论的新的高潮。笔者在本文中将全面对比持续集成论文前后两版的异同，分析并展示ThoughtWorks在持续集成领域的理论和实践方面的研究成果，以图对国内企业实施持续集成起到参考和借鉴作用。需要说明的是，本文所介绍的内容毕竟限于笔者的水平，并且主要是ThoughtWorks内部开发和对外咨询实践的总结，所以未必对读者所遇到的情况是适用的，请自行甄别。

我——作为一名测试人员——有一个与众不同的习惯：每当要加入一个新项目的时候，我总会找到项目中的同伴，真诚而亲切地说：“为了更好地合作，我有5个约定，希望大家能尽量遵守”。

随着敏捷越来越广为人知，敏捷测试也更多受到了大家的关注。在这里，我想谈一下我在敏捷项目中遇到的一个自动化测试相关问题以及我们如何借助DSL领域专用语言来解决它。