闲亭信步（KISS）

《爱丽丝梦游仙境》中有一个场景，兔子说：“你必须跑得非常快，才能一直站着。”这句话简直就是当前商业环境的真实写照。那么，如何才能跑得快呢？自从“互联网＋”被提出来以后，“转型”成了热门词。向哪个方向转，如何“转”呢？

很长时间没有更新博客了，一直在上海，上星期刚从客户现场回Office。在很多刚刚开始实践Agile的团队中，有这么一种想法：“Retrospective太花费时间了，所有成员在那里开上一两个小时的会议。在会议上，要么大家发发牢骚，要么项目经理讲讲话，强调一下后续工作中的注意事项。还不如回写座位上写代码来得直接呢。”其实，如果有这样的认识，说明团队还不成熟。如果没能发挥这一实践的重要作用，那么可能比"不会做TDD"有更严重的后果。

什么是 LAMDA?  什么是 LAMDA? LAMDA 是一个用于发现问题、积累知识的改进环路。Dr. Allen C. Ward发现美国工程师在尝试使用Plan-Do-Check-Act环时，常常是一种不恰当的使用模式：在Plan的投资方式不正确，而Do和Act的重点也不明确。这反映出两个问题：（１）在ＰＤＣＡ环中，对于Ｐ和Ｃ这两个阶段，人们需要很更多的指导；（２）对于Do

不能持续学习的团队，会出现下面的一些症状：·     疲劳（持续在紧张的节奏下工作）导致士气低落。·     在一个迭代周期中，反复地出现无法达到 “完成状态”的现象。·     承诺的任务总是无法完成（有些特性或任务甚至还没开始）。·     已经部署的软件不断地有缺陷暴露出来，导致开发计划流产。·     减少或者取消回顾会议（“因为从来没有真地解决过发

1. Your Single Path to Production:From Point-and-Click Package Promotion to Integrity Assurance to Package Deployment and Redeployment to History and Traceability, you will find that once you us

持续集成已经是一个古老的话题了。有的公司跃跃欲试，有的公司浅尝则止，有的公司半路放弃，而有的公司去能持之以恒。这是什么原因呢？既然是一个古老的话题，那与它刚出现的时候相比，现在是否有了新的变化呢？受优快云之邀，本人将在软件开发2.0(SD2.0) 软件工程专场（本月23日上午9:00）和对此话题有兴趣的朋友一起探讨这一主题，题目

自从2009年6月，Cruise team 开始尝试在项目中使用Kanban。作为项目经理，非常高兴这个改变，在回顾会议上，Team反映也很好。它让整个团队更加聚焦于频繁部署产品，因些也非常容易识别项目运行过程中的瓶颈，以及对事情排定优先级。不再有项目估算会议，取而代之的只是平均每张卡片的生命周期。所以，对于整个团队来说，唯一重要的事就变成了“如何让每张卡片快速走完它的生命周期”。Releas

几个月前参与翻译的《the Thoughtworks Anthology》终于面市啦，中文名为《软件开发沉思录》。共有13篇文章，是ThoughtWorks的思想沉淀，内容包括软件开发过程中的各个方面，如项目管理、迭代管理、发布管理、敏捷开发与测试。 以前发布的《一键发布》就是其中一篇。还包括《练习OO的原则》。这是豆瓣上的链接。

在Cruise项目使用了Story&Process/Themes Mapping的方法来检查Story list是否有遗漏。操作起来也非常简单。其步骤是： 一、将所有业务流程画在一个大白板上；（画不下的话，找更大、或更多的白板。自己想办法吧）二、将所有的Themes分栏放在桌面上。三、将所有的Story打印在小卡片上（两份）。四、根据业务流程的相关性，将小卡片贴在相应的

 昨天中午的BA交流讨论会上，小裴讲了一下在某项目收集需求，捕捉用户故事（Story）的过程，很是值得深思。其关键在于INVEST原则中的V（Valuable）。该项目是一个有很多分析图表的改造项目，需要保持当前的数据，并修改或增加一些图表。例如：  那么，对于这类分析图表如何写用户故事（Story）呢？ 最初，是根据图表的区域来划分用户故事（Story）。即左边的折线

大家都说瀑布、迭代式瀑布、SCRUM和Lean之间的流程是不同的，那到底有什么不同呢。这个图很能说明问题。     From  http://agile101.net/2009/09/08/the-difference-between-waterfall-iterative-waterfall-scrum-and-lean-in-pictures/ 

 在上个星期，与一个项目的开发人员讨论了有关项目中的非功能需求（我们手中有一些关于非功能需求比较High Level的描述），目的是让这些东西落地。 这种形式的讨论一下子让我想起了CMMI中的评审过程，非常的类似，但却有本质的不同。＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋CMMI中的评审过程是当项目某些Artifacts产生出

AgileChina 2009大会官方网站 由在敏捷领域最具有影响力的技术社区InfoQ中文站、敏捷方法论的领导厂商ThoughtWorks共同主办的敏捷中国技术大会（Agile China2009），将于9月11日~12日（周五、周六）在北京举行。届时将有超过500人来自电信、金融、互联网、教育等行业在内的高级软件开发人员、项目管理人员等参加。本次大会将特别邀请敏捷宣言缔

前些日子写了关于小规模产品团队的持续集成实践，之后就一直就忙于项目，今天终于有时间完成这一篇关于大规模项目的持续集成相关问题了。 一、持续集成基础在典型的软件项目中，集成阶段一般都是在最后，因此也是出现问题最多，而且最有可能导致不能按时交付。而持续集成（XP十二实践之一）可以用来解决这个问题。既然大家都认为“频繁地使软件在某一代码基线构建并通过测试”是个不错的做法，那么

一年一度的敏捷中国即将于10月14日开幕。“敏捷十年，让我们自省并继续前行”。本次盛会邀请了数位国内外嘉宾，精彩演讲，不容错过。另外，本次大会演讲题目有收集方式有所改变。现面向整个软件行业征集敏捷相关的话题。本次大会的四个主题分别是：业务敏捷、组织变革、管理实践和技术实践。详情请参见敏捷中国。

有位童鞋问了这样一个问题："我现在的团队也面临这样的问题，更糟糕的是我们还没有测试套件。目前只是面临企业内网，马上也面临外网的应用了。痛苦。。。那个大侠给个好建议！"其实，文章中已经给出了答案，即一直保持“主干开发为主的短周期分支策略”。当然，很多团队无法达到这种境界。原因可能非常简单。比如，无法拒绝客户要求，否则就有可能失去重要客户。开发时的代码质量太差，当需要发布时，在分支上修复Bug的时间需要很长，而在主干上开发新功能时仍旧不注重质量。传统的瀑布开发方式使两次发布之间的时间间隔太长（每次发布都需要三个

Produce Value EarlyWelcome ChangeIterative DeliveryDaily Business CollaborationTrust Motivated TeamFace to FaceWorking SoftwareSustainable PaceTechnical ExcellenceK.I.S.S.Self-Orga

今天收到yahoo group中极限编程组（extremeprogramming@yahoogroups.com）的一封求助信，大意是：“需要自动化构建和持续集成的收益数字，好让他们的VP能让他花上一段时间专门优化他们的构建脚本，以便将时间从3、4天缩短到12个小时。因为他们的单元测试运行时间太长，而且构建经常因为单元测试的失败而失败。”这也没什么可笑的，因为这种事在很多公司都常见，但是，当这

本文源自我在2012 Top100Submit大会的演讲《细节决定成败》，并会收录到麦思博公司将编集的《2012案例年鉴》中。为期三天的Top100Submit会议中，你能听到来自不同IT领域、不同背景的嘉宾分享他们的故事，总能从中找出一些值得你学习的亮点，可能是你之前有疑惑的问题，也可能是你之前遇到过，但却是不同的应对策略。在这里，我把自己所遇到的状况，以及应对策略记录下来，与大家分享。

1) Visualize the workflow2) Limit the work-in-progress3) Measure and manage flow4) Make process policies explicit5) Implement feedback loops6) Improve collaboratively (using models & scienti

The ultimate measure is the number and severity of defects in the working software delivered each iteration.  But, this is a metric for the whole team, not just the testers.In order to minimize

本文已发表在 InfoQ中文站的《持续集成》专栏，关于“持续集成”和“持续交付”更多的文章、视频资源请访问“持续交付中文站”,http://www.continuousdelivery.info/index.php/resources/。在前文《软件自我识别》中，我们讨论了如果使软件做到自我识别，以促进自动化部署和版本检测等工作。 随着互联网的飞速发展，以及基础设施的改进，越来越多

本文是 王晓明同学在InfoQ发表的文章《关于项目估算的微博讨论》中提到的排序法详解。一、引言软件项目的估算历来是一个难题。由于软件开发活动还无法实现土建工程那种成熟度，所以也无法像做土建工程那样通过预算速查手册来评估。但是，对于一项投资来说，总要说出要投资多少吧，软件开发也要给出投资额，这就需要做估算了。本文主要讨论敏捷软件开发中的用户故事（User Story）

持续交付成熟度模型更新，新版本v1.2发布《持续交付》一书中提供的“持续交付成熟度模型”是1.0版本。这是经过再次调整的改进版，更具有指导性和可操作性。使用说明：建议使用该模型进行现状分析，发现改进点，不建议将其作为绩效衡量的标准。共有七个维度，它们分别是：

软件开发中，“配置开关”根本算不上是一个“新”概念。无论是通过启动时加载配置，还是应用程序运行时动态刷新配置，都可以用来决定或改变应用程序的某种具体行为。比如：通过配置文件，使用应用程序连接不同的数据库通过模板配置，达到应用程序“换肤”的目的通过系统管理员的配置，使不同的

现在，服务器集群已经是司空见惯的事情了。随便一个小的互联网应用程序都需要用集群来支撑。而当采纳“持续集成”，尤其是“持续交付”实践时，在各种环境上的部署让你发疯。这些环境包括开发环境、测试环境（包括功能测试和非功能测试）、试运行环境和生产环境。而且，每种环境可能会有多套实例，而不

回顾会议的目的：（1）创造一个安全的团队环境；（2）建立信任和参加感；（3）对成功的欣赏；（4）为改进提供一个框架；（5）情绪宣泄；（6）直面问题；（7）自我建立团队“规则”：创建并改进团队流程。看看你做了哪些？经常被忽略的可能

在过去多年的持续集成咨询经历中，最常听到的一个问题是：如何来评估企业在配置与发布管理方面做得到底怎么样？还需要在哪些地方进行改进或提高？两年前，CITCON的几个参与者给出了一个成熟度模型，主要关注于“持续集成实践”，而在《持续交付》一书中，Jez与Farley也结合Thou

只写给尝试过敏捷，并还想尝试的人。

Martin Fowler 最近在用分布式版本控制工具（mercurial/GIT），并写了一篇博文，名为《特性分支》，主要讨论了使用分布式版本控制工具以后，可能的三种工作方式。（非常佩服Martin Fowler的总结能力。） 1. 堆积变更，推迟合并       在我看来，这种方式的确充分利用了DVCS的灵活性，但显然，不爱频繁提交的开发人员很可能一直发扬这个坏

继续《理解面向对象的练习原则》 所有原则要在大家做练习时使用。但只有练习过，才更容易理解面向对象。 一个整型数字本身没有任何意义。当某个方法用一个整型参数做参数时，这个方法名就要负责解释一切。假如这个方法使用Hour作为参数，那么就更容易知道它是做什么一些了。小对象可能会使代码易维护一些，因为你可能把一年的"1"传到这个方法中。 而且使用原始类型的变量时，编译器无法帮助

什么是个人预提交（Personal build）?Personal build简单来说，就是开发人员在代码提交之前，先要自己在本地运行一次构建和测试代码，保证本地没有测试失败后，再将其提交到中央代码仓库。Personal build的痛处在哪里？“提交代码之前，必须在本地运行并通过单元测试”是敏捷团队的原则之一。而随着新功能的增加，我们的单元测试越来越多，运行时间当然也就越来越

以前没使用Nant和Nunit建立过C#代码的自动化构建，今天自己写了一个C#程序，想用Nant和Nunit构建C#代码。可写好build文件后运行UnitTest时遇到了麻烦。命令行提示如下：Could not load file or assembly nunit.framework, Version=2.4.3.0, Culture=neutral, PublicKeyToken=

最近，在google group的Agile china讨论组有一个关于Scrum培训的讨论。其中有一个回贴提到"scrum对管理层的要求更高"。那么，再进一步，Agile对管理层的要求更高吗？个人认为，至少在采纳Agile的初始阶段，这种提法似乎不是很正确。（我假设这里的“管理层”是指有决定权的组织级管理者） 首先，无论我们采用什么方法，最终都是为了一个目的，即“创造更多的价值”。如果能够创造

如果你的开发团队正在使用敏捷开发方法，而客户并不在意什么开发方法，他们只想尽快地拿到他们需要的软件。作为项目经理，你该怎么办呢？如果客户不知道敏捷开发方法，那么向他介绍敏捷开发方法是项目经理应该做的一件事，但是要适可而止。因为能用的软件才是他们想要的，在没有深刻体会到它带来的益处时，你是无法用嘴皮子来证明的。但并不能这么就算了，因为还要保持开发团队的士气呢。所以，一方面要在客户能够接受的程度下尽量

持续集成是敏捷最佳实践之一，但并不是只有使用敏捷方法的团队才能够采纳。但如果你能够采纳敏捷方法，那么它会发挥更大的作用。“什么是持续集成”在前面的文章中已谈过了，这里只把其中的一部分：持续集成的六个基本自动化再细说一下。这六个基本自动化是：自动运行测试、自动产生可部署的二进制文件，把它部署到类似生产环境中，自动标识你的代码基线，自动运行回归测试以及自动产生度量。一、运行测试 　　这本来是不必说的事

自从2005年开始，Yahoo! 在美国、欧洲和亚太地区就开始尝试使用Scrum进行软件产品开发。最初仅选择了四个团队进行尝试。到目前为止，已有近200个团队在不同程度上使用Scrum。这里所说的“不同程度”是指不同的受益程度。Yahoo!有一个由三个人组成的类似于教练团的组织，该组织成员与其他项目的成员一起参与项目，一起解决他们遇到的关于过程和方法方面的问题。根据实施效果来看，仅仅三个人是远远不

Mingle是一款敏捷软件开发管理工具，它即将发布就的版本。该版本中增加了很多新特性，当然，最主要的功能就是Card Trees啦。你可以在各种各样的卡片之间建立父子关系，这些关系通过树型结构可以展示出项目的复杂度。为了不同的目的，或针对不同的团队角色，你能够构建不同的树。项目经理可能希望有一个计划树，用来做WBS 分解（work breakdown structure），而业务分析师想要用Sto

在敏捷团队中，BA（业务分析师）的一项主要工作就是分析User Stories。一般来说，我们用纸卡写记录它们。Mingle发布以后，我们开始使用它来管理我们的故事卡片。Mingle是一个很好用的敏捷项目管理工具，说它好用是因为它的可定制性非常好。你可以用它管理你的项目，即使你用传统的项目管理方法。它暂时还不能完成我（一个BA）想要的功能，即（1）我可以任意拖动我的卡片，（2）在它们之间任意的画线

原文：http://www.infoq.com/cn/articles/SOA-Agile-Friends-Or-Foes这是一篇关于SOA与Agile的讨论，文章总结了当前使用这两种技术的观点。虽然没有结论，却也值得思考。其实，无论是敌？是友？都有共同的目标，那就是用技术为企业提供更大的价值。想一想，任何一种技术的产生都是同样的理由。下面是该文的部分引用：敏捷与ＳＯＡ是朋友