可靠的消息传输协议，有必要吗？
Marc de Graauw对传输层的可靠消息机制（如WS-ReliableMessaging）存在的必要性提出了质疑。通过荷兰医疗保健中心的SOA项目案例他展示了特定业务逻辑如何在按序传达消息和一次且仅一次传输中表现得更为良好。
- SOA,
新闻
文章：跌跌撞撞的持续集成之路
作者 仝键 发布于 2008年9月18日 上午12时19分
很多人都希望用敏捷的方法去改造团队，提升工作效率，把我们自己和公司从无止境的重复的困苦中解救出来。可是敏捷不是一套衣服，说换你就换上了，就是一套 衣服你也不能说换就换上，还得看合不合身。原封不动的照搬最佳实践，其结果就是打击团队和公司对敏捷的信心。所以大家在推行敏捷的时候都是很小心的。
在 AgileChina讨论组里，每隔一段时间总会有一个重复的问题——我应该从哪开始推行敏捷。答案往往都是“从持续集成开始”。可是实际做起来并不像说 起来这么简单。这简单回答的后面是一条艰难的历程。尤其当技术发展到今天，各种语言都开始在企业级开发中开花结果，InfoQ中文站邀请一位一线开发者分 享其在一个采用Flex和Java技术的项目中进行持续集成实践的经验。
敬请阅读全文：跌跌撞撞的持续集成之路。
InfoQ能否加一个功能
发表人
R Lee
发表于
2008年9月18日 上午1时55分
Re: InfoQ能否加一个功能
发表人
申 刘
发表于
2008年9月18日 下午9时19分
同感，InfoQ 的 useability 有待改进
发表人
Charlie Zhang
发表于
2008年9月18日 下午10时30分
Re: 同感，InfoQ 的 useability 有待改进
发表人
霍 泰稳
发表于
2008年9月19日 上午1时17分
学习微软经验：超大规模的 SQL Server build 系统
发表人
Charlie Zhang
发表于
2008年9月18日 上午3时40分
Re: 学习微软经验：超大规模的 SQL Server build 系统
发表人
yi wang
发表于
2008年9月19日 上午1时23分
Re: 学习微软经验：超大规模的 SQL Server build 系统
发表人
isaac han
发表于
2008年9月19日 下午8时1分
仝键，你们为什么不用 Branch-Merge？
发表人
Charlie Zhang
发表于
2008年9月21日 上午8时23分
系统过大，该考虑分解为几个应用了
发表人
Yongshi He
发表于
2008年9月21日 下午10时20分
Re: 仝键，你们为什么不用 Branch-Merge？
发表人
jasson zou
发表于
2008年9月22日 上午1时41分
怪了，这也算广告？？？
发表人
Charlie Zhang
发表于
2008年9月22日 上午5时9分
Re: 怪了，这也算广告？？？
发表人
Jason Lai
发表于
2008年9月23日 上午7时49分
Re: 怪了，这也算广告？？？
发表人
凉粉 小刀
发表于
2008年9月23日 下午8时42分
做媒体的不可以这样无耻！
发表人
Charlie Zhang
发表于
2008年9月23日 下午11时33分
Re: 做媒体的不可以这样无耻！
发表人
Kaishen Chang
发表于
2008年9月24日 上午2时47分
Re: 做媒体的不可以这样无耻！
发表人
小 熊
发表于
2008年9月24日 上午3时0分
Re: 做媒体的不可以这样无耻！
发表人
Kaishen Chang
发表于
2008年9月24日 上午3时14分
Re: 做教练的不可以这样不注意身体！！！
发表人
小 熊
发表于
2008年9月24日 上午3时43分
Re: 做媒体的不可以这样无耻！
发表人
Steven Mak
发表于
2008年9月24日 上午4时14分
CC 2.7.x 支持比它的DistributedContrib更建单的分布式
发表人
Guanglei Li
发表于
2008年9月18日 下午8时1分
想省钱的话何必死抱着CC
发表人
Guanglei Li
发表于
2008年9月18日 下午8时2分
选择更加适合自己团队的运作方式
发表人
Kent wei
发表于
2008年9月23日 下午8时51分
Re: 选择更加适合自己团队的运作方式
发表人
Kent wei
发表于
2008年9月23日 下午8时56分
分析的不错，赞成！
发表人
Charlie Zhang
发表于
2008年9月23日 下午10时52分
Re: 分析的不错，赞成！
发表人
Kent wei
发表于
2008年9月24日 上午1时2分
对，要看效益
发表人
Charlie Zhang
发表于
2008年9月24日 上午3时5分
解决手段的分析有点问题
发表人
Charlie Zhang
发表于
2008年9月23日 下午11时4分
张恂将提供本案的详细案例分析
发表人
Charlie Zhang
发表于
2008年9月25日 下午8时41分
为什么推行敏捷非要从 CI 开始？
发表人
Charlie Zhang
发表于
2008年10月13日 上午3时22分
推行敏捷从理解敏捷开始
发表人
Charlie Zhang
发表于
2008年10月14日 上午1时37分
是否可以多级多粒度的持续集成
发表人
钱 翔东
发表于
2009年5月20日 下午9时15分
-
就是统计每篇文章的阅读次数，然后根据阅读次数做每周推荐，或者是每月推荐，现在很多网站都有的
-
微软中国研发集团服务器与开发工具事业部SQL中国研发中心博客：
SQL Server Build 系统（刘春雨 SQL Server中国build团队，2008-7-28）
先提两个问题：
1）如此成功的超大规模 build，微软是如何做到的？有什么杀手锏吗？
2）微软这么做，是不是敏捷？是敏捷，还是卓越？敏捷好，还是卓越好？
中西合璧的敏捷 OO 教练 张恂
www.zhangxun.com -
cruisecontrol.sourceforge.net/buildgrid.html
一句话总结就是在多台机器上构建, 而把结果汇总到一个页面 -
Hudson不也不错
-
谢谢您给我们提的建议！这些功能已经在开发当众，将会在我们的下一个版本中实现:)
而我们现在的做法是，每周通过我们的Newsletter（我们管他叫“每周精要”）向大家推荐本周的妙文；每个月，通过我们的电子期刊（将于下个月发布）向大家推荐这个月的精彩文章:) -
一年之前我也曾经提出过许多类似的建议。可是遗憾，至今好像没什么动静。
个人觉得，尽管英文版的内容很好，但 InfoQ 离真正的 2.0 社区还距离很远，现在顶多 1.5。 -
不要着急，这个功能已经指日可待了:) 而且还会增加评论邮件提醒功能，即你参与评论的内容，如果其他人有回复，会通过邮件给你发送通知。我们的开发团队人员稀少，backlog上的功能一大堆要实现，所以动作慢了一些，大家多担待。
-
偶不是ms的人也知道，SQL Server 这种规模的项目怎么可能用敏捷，找死吗。
-
大规模的项目用敏捷就是“找死”？怪哉～
-
仝键：另外，糖醋鼻子还提到了分支式开发，大家围绕这个还展开了激烈的讨论，不过我考虑到分支式开发对我们的利可能要远小于弊，最终还是放弃了这个方案。
为什么 Branch-Merge 对你们会弊大于利，你没有说明。问题可能恰恰出在这里。
刘春雨介绍了微软是如何解决这个问题的：
我们每天做这么多的build正体现了我们如何支持整个SQL Server工程体系和构架：
在SQL Server 2008的工程体系和构架中，我们将每个需要增加或增强的功能特性做成一个单独的分支，在这个功能特性开发和测试完成后，其代码才会合并到SQL Server的主线代码中 ... 每个分支都需要build来进行及时的测试，因此有了这个我们当前每周需要的build个数——130。当build结束后，Test Execution team和其分支团队会执行自动测试来确保其代码的质量符合严格的要求和标准。最后当这个功能特性开发和测试完成后，其代码将会融入到SQL Server的主线代码中，然后其它各个分支团队将重新获取主线代码并融合其分支的当前代码，来保证和主线代码的同步。
相关数据：
每个build 的大小在300GB左右。
每个完整的build需要几十台高端的服务器运行2.5天。
每个完整的build由几千个job、10000多个参数组成。
我们每天同时做20个左右的build，每周130个。
位于美国微软总部雷蒙德和北京的build团队能够保证build全天24小时不间断的顺利进行。
从去年至今，我们build team已经成功而准时地完成了数以千计的build。
很高兴看到刘春雨的这段介绍，它们和十年前张恂从《微软的秘密》中所学到的方法是一致的。这说明过去十多年来微软一直在沿用这套成熟的方法，它们当然是软件工程中的 Best Practice。正是受到微软经验的启发，张恂带领的研发团队早在 2000 年和 CMM 热之前就做到了软件配置管理和 Branch-Merge，领先于当时国内软件同行业的水平。
你们的系统规模不可能比 SQL Server 更大吧？对于如此庞大系统的功能开发和质量保证，微软运用 Branch-Merge 显然是非常成功的。我觉得你们应该跳出“极限敏捷”和 CI 的圈子，试一试其他成熟的“敏捷”方法。
中西合璧的敏捷 OO 教练
www.zhangxun.com -
可以把系统分解开，变成几个子工程，分别构建，只要协调好引用关系，分配好时间片，应该能把速度提高。
-
张敏捷又来做广告了！！！
-
2008年9月22日 上午1时41分 发表人 jasson zou：
张敏捷又来做广告了！！！
契合主题，张恂分享了自己的一些经验和成果，这也算广告？
就算是广告（广而告之），张恂的每一篇文章、每一次评论都可以算广告，这有什么不对吗？InfoQ 英文版、中文版的每个页面上到处是广告，你没看见？
没必要大惊小怪的。 -
怎么不算广告？你这是隐性软广告，InfoQ 最不做的就是这类。没错这个页面是有广告，数量也不少，但也是别人掏钱或者合作做的。这样吧，你给 InfoQ 掏点广告费，价格合理的话，肯定会给你一个好的 package，如何？
-
赞
-
看了文章，感觉该作者最初犯了点教条主义的错误：无论现实如何，既然持续集成要集成，一定要每时每刻都集成。其实包括后来作者的理解和Jeff Xiong的认可，都是在错误认识的基础上做的错误判断。
持续集成的基本的本意很简单，就是减少集成的成本，基本本质无非就是控制项目成本。所以采用什么集成方式，判断的唯一标准是成本（当然是指在某个质量底限下的成本）。
手段无非有三，通过如下手段综合考虑：
一、增加持续集成服务器投入;
二、增加build 人手投入，大的team甚至可以由一个build master带领一个“分布式"的team;
三、选定合理的集成周期,是real-time build 还是daily build;
如果你的项目很大,销售额也大，build的时间长，意味着你要选择一和二是比较合理的,因为客户得罪不得。
如果你的项目很大，build的时间长，销售额一般，则调整一和三比较合理，这些投入成本较好控制。
如果你的项目大，build的时间长，销售额很少，那么唯一的选择恐怕就是daily build.（实质是牺牲一定的质量)。
你的team情况看来，测试人员到位，build master也比较成熟，那么剩下就是看看项目销售额了：
销售额大，客户比较重要，那么选择增加集成服务器投入；反之，则可以让unit test 实现real-time build， 验收测试实现daily build（每天晚上跑一次或者两次，根据你要支持的浏览器来定）.
如果unit test都难以实现real-time build，说明结构设计上有些可以改进的,比如才用内存数据库服务器等等。
如果依然无法实现real-time unit test build，那么都采用daily build吧。但是强制要求team提交代码之前一定要跑单个unit test和单个功能测试脚本。 -
看了文章，感觉该作者最初犯了点教条主义的错误：无论现实如何，既然持续集成要集成，一定要每时每刻都集成。其实包括后来作者的理解和Jeff Xiong的认可，都是在错误认识的基础上做的错误判断。
持续集成的基本的本意很简单，就是减少集成的成本，基本本质无非就是控制项目成本。所以采用什么集成方式，判断的唯一标准是成本（当然是指在某个质量底限下的成本）。
手段无非有三，综合考虑：- 一、增加持续集成服务器投入;
- 二、增加build 人手投入，大的team甚至可以由一个build master带领一个“分布式"的team;
- 三、选定合理的集成周期,是real-time build 还是daily build;
如果你的项目很大,销售额也大，build的时间长，意味着你要选择一和二是比较合理的,因为客户得罪不得。
如果你的项目很大，build的时间长，销售额一般，则调整一和三比较合理，这些投入成本较好控制。
如果你的项目大，build的时间长，销售额很少，那么唯一的选择恐怕就是daily build.（实质是牺牲一定的质量)。
你的team情况看来，测试人员到位，build master也比较成熟，那么剩下就是看看项目销售额了：
- 销售额大，客户比较重要，那么选择增加集成服务器投入；
- 反之，则可以让unit test 实现real-time build， 验收测试实现daily build（每天晚上跑一次或者两次，根据你要支持的浏览器来定）.
- 如果unit test都难以实现real-time build，说明结构设计上有些可以改进的,比如才用内存数据库服务器等等。
- 如果依然无法实现real-time unit test build，那么都采用daily build吧。但是强制要求team提交代码之前一定要跑单个unit test和单个功能测试脚本。
-
搞软件工程，一定不能教条、先入为主，要算算投入/产出比。
2008年9月23日 下午8时56分 发表人 Kent wei
选择更加适合自己团队的运作方式
看了文章，感觉该作者最初犯了点教条主义的错误：无论现实如何，既然持续集成要集成，一定要每时每刻都集成。其实包括后来作者的理解和Jeff Xiong的认可，都是在错误认识的基础上做的错误判断。
... -
kent wei 推荐的三种手段不错，但推荐的理由和情况分析有点问题，存在漏洞。
如果你的项目大，build的时间长，销售额很少，那么唯一的选择恐怕就是daily build.（实质是牺牲一定的质量)。
Daily Build 是一个著名的微软实践，而微软的项目大，build 时间也长，销售额应该也不少，更不会去牺牲质量。
如何选择这三种解决手段，真的和项目销售额有关吗？好像没说清楚。 -
2008年9月23日 上午7时49分 发表人 Jason Lai
怎么不算广告？你这是隐性软广告，<strong>InfoQ 最不做的就是这类</strong>。没错这个页面是有广告，数量也不少，<strong>但也是别人掏钱或者合作做的</strong>。这样吧，你给 InfoQ 掏点广告费，价格合理的话，肯定会给你一个好的 package，如何？
什么是隐性软广告，你能不能给出一个科学的定义？是不是软广告，也不是由你说了算吧。
你们采访熊节、潘加宇、温昱 ... 有没有收费？算不算软广告？Ok，你可以说他们是合作伙伴，如果认定为合作，就可以免费。那么，合作不合作，岂不是由你说了算？你高兴，就算合作，可以免费；你不高兴，就算非合作，要收费。做媒体的不能这样无耻吧。
你知道什么是平等、人权和言论自由吗？什么是你的价值观？难道被铜臭味儿和所谓的哥们儿“义气”蒙住了双眼？
一个知名技术社区和论坛的编辑如此公开地向发表合法评论的网友要钱的，张恂记忆中好像还是头一回遇到，即便在 CSDN 上好像也没有出现过。
Jason Lai，作为 InfoQ 主管和主创人员，你应该向张恂和所有的 InfoQ China 网友道歉！
中西合璧的敏捷 OO 教练 张恂
www.zhangxun.com -
<block> 搞软件工程，一定不能教条、先入为主，要算算投入/产出比。 </block>
这里只是讨论持续集成实践，和哪种方法学不搭边。投入产出是所有开发方法学需要解决的问题，不仅仅是软件工程需要解决的问题。
实际上，持续集成在敏捷XP中实施会更好，因为XP强调pair programming,这样的持续集成更有意义. 错误的理解需求和错误的测试,无非就是集成出错误的结果. 所以持续评审可以强化持续集成的效果.
<block>Daily Build 是一个著名的微软实践，而微软的项目大，build 时间也长，销售额应该也不少，更不会去牺牲质量。如何选择这三种解决手段，真的和项目销售额有关吗？好像没说清楚。</block>
所以微软的东西那么多补丁. 如果一个普通的商业项目有微软那么多严重漏洞，这公司早被咔嚓了，那是垄断的话题了。而且还牵扯到产品领域开发和项目领域开发的不同。
daily build不是微软创造,也不是因为微软而著名。
我说销售额只是一个直观的判断，实质上是看效益。
-
在 InfoQ 冷眼旁观潜水很久了，今天看到楼上极品大叔一直在跳梁，实在忍不住了。
大叔之前在各个网站的所作所为，我是略有耳闻，原来以为嘴皮子仗是圈内常事，也不以为然。不过有幸看了几次大叔因为右脸一被摸就轰然倒在地上滚泥巴，大声哭喊自己下巴被打脱臼的荒唐喜剧，一直觉得忍俊不禁。我挺纳闷，为啥其他国内热门的软件社区和讨论组，就一直没有张大叔的身影呢？JavaEye？CSDN？AgileChina？Scrum 讨论组？甚至前几天上海的 Scrum gathering 活动？张大叔不是在上海么？怎么从来没听说过？我邪恶地想了想，应该是因为大叔已经把自己四处踢馆吵架，已经散播得臭名远扬了。InfoQ 这边是不是都不删贴的？每次一看见这个极品大叔过来这边搅浑水，以及他不断变换给自己贴金的签名，我感觉跟我杯子里面飞进苍蝇一样恶心。
InfoQ 为什么还留着这样恬不知耻的人在这里到处跳梁？一定要等到哪一天人都被他恶心干净了才知道该做些什么了？ -
个体临床表现为自尊受损，在自尊受到威胁时，常常反应强烈。
www.hrxl.cn/rengezhangai/renge_3053.html
我觉得还没有影响到您的自尊吧？很有威胁么，就反应这么强烈了？ -
2008年9月24日 上午1时2分 发表人 Kent wei
我说销售额只是一个直观的判断，实质上是看效益。
对，要看 CI 的投入/产出（效益）。
在本案中，如果投入 CI 的代价很大，效果又不好（损失了开发效率），甚至得不偿失，那么就应该放弃 CI，试试 Branching-NI（Nightly Integration）。在这点上，我们的看法基本上是一致的。 -
好笑。我怎么看不出公开要钱？人家只是建议你如果要投真正意义上的广告，你可以掏钱吧？逻辑都搞不清楚，就在这里混淆概念。
-
建议您别在InfoQ这里浪费您的宝贵时间了，原因有四：
1、您赶紧去找个诊所看看病，别等发展严重了，那可是中国IT界的一大憾事。对您来说，身体是忽悠，啊不对，是教练的本钱。其实我觉得您身体可能还成，就是这脑子……难道您是因为业务发展得太蓬勃了，没工夫？那怎么还有时间在这里混？要不我心理小小阴暗一下，是不是因为诊疗费上有困难？是不是因为您的事务所门可罗雀？没关系，我相信InfoQ肯定好人做到底，既然能看出来您的问题，再帮您报销个医药费，又怕什么的？到时候您记得把发票拿给霍泰稳报销，不过千万看清楚，别把超市买手绢的小票拿过来。
2、如果您还指望用这种几乎可算是超级无敌掌门独有的方式暴得大名，那么恭喜，您已经达到目的了。出名有两种方式：骂名人，抱粗腿。您怎么出的，人所共知。
3、您在这里东一榔头西一棒槌的，即使自己无所谓，也浪费广大网友的宝贵时间。不过话又说回来了，“存在即是合理”，您能给广大网友在繁忙工作之余找个乐子，斗个闷子，也算不错。不过在此提醒广大网友：“看戏有风险，时间须谨慎。”
4、您得空也歇歇，嘬口水，嘴里边总横着个东西也挺累的，再说也得喘喘气嘛，要不还不得热死…… -
看到閣下有關 "平等、人权和言论自由" 的論述感到十分惡心.
情況有如自己拍短片寄去CCTV要求全國廣播. 給人拒絕之後還惡人先告狀~
希望尊重InfoQ.com的編輯權以及其保障付出真金白銀的廣告客戶的權利, 以及對廣告及內容詮釋權利. -
请见：www.zhangxun.com/?sname=InfoQCIRoad
本案很有意思，值得进一步研究。我将继续提供有关本案的分析和评论，欢迎大家阅读、参与讨论。 -
作者 仝键 发布于 2008年9月18日 上午12时19分
在 AgileChina讨论组里，每隔一段时间总会有一个重复的问题——我应该从哪开始推行敏捷。答案往往都是“从持续集成开始”。可是实际做起来并不像说起来这么简单。这简单回答的后面是一条艰难的历程。
推行敏捷应该从哪开始，显然这是一个敏捷 FAQ。但为什么在 AgileChina 讨论组里，正如仝键的发现，答案往往都是“从持续集成开始”呢？
这是一个有趣的问题，我试着来解答：
很可能是因为你接触的大概都是像 Jeff Xiong 这样的 TW 员工，或者他们的追随者及其亲朋好友们吧。大家都围绕着 TW 的方法和产品来谈敏捷，自然容易得出这样一个印象了。
听说 AgileChina 是由几位 TW 员工在业余时间举办的，而“推行敏捷从持续集成开始”也是熊节（Jeff Xiong）所推荐的吧，InfoQ 上好像有相关的文章。
众所周知，CC 和 Cruise 等是 ThoughtWorks 公司著名的持续集成工具产品。无论是否有组织，TW 及其员工推销自己公司的理念、方法和工具产品，无可厚非，很正当。
关键一点：我们应该分清什么是市场宣传，什么是科学的结论。很多时候，市场宣传（如广告）合情合理，但不一定科学和客观。而“推行敏捷从持续集成开始”，在我看来更像是一种主观的市场宣传和劝导，而不是客观、科学的结论。
“推行敏捷从 Practices 开始”或者“推行敏捷从 CI 开始”，可能问题还不大，但如果有人把它们理解成“推行敏捷最好从 CI 开始”或者“推行敏捷一定要从 CI 开始”肯定是错误的。 -
那么，推行敏捷应该从哪里开始呢？
这个问题可能有许多种答案，“推行敏捷从理解敏捷开始”应该是其中一个比较正确和可靠的答案。推行敏捷时，如果连什么是真正的敏捷，实施敏捷到底意味着什么，都没有搞清楚，那么在错误理解敏捷的基础上推行敏捷还有可能成功吗？当然不可能（或者可能性很小）。这显然是每个人理应都明白的废话。
尽管“推行敏捷应该从理解敏捷开始”是废话，但是网络（包括 InfoQ）上公开出来的许多敏捷实施失败案例，导致失败的根本原因恰恰是因为敏捷的推行者、实施者（尤其管理者）错误理解了敏捷，有的做法甚至明显偏离了敏捷的基本目标和价值观，而他们依然自信满满地认为自己对什么是敏捷相当了解。这就是我们要始终不断地重复强调废话的原因。
推行敏捷从哪里开始？简单说，中式太极敏捷认为一种可行的、比较合理、符合逻辑的步骤（或阶段）是：
1、认清真正的敏捷
通过学习和调研，认清什么是真正的敏捷。如果一些基本初始概念就错了，那么在后续的推行中必然会差之毫厘、谬之千里，希望通过真正的敏捷实施提高开发效率和质量，比传统软件工程做得更好，也就无从谈起了。
2、预估推行敏捷的收益
在确认知道什么是真正敏捷的前提下，对自己团队、组织的现状、问题和薄弱环节进行评估，设定改进目标，并预估敏捷能否解决这些问题，带来哪些潜在的改进和收益。如果成功的把握小于 50% 或者现状已经足够好，就不要推行敏捷，何必劳民伤财，得不偿失呢。
3、采取具体措施推行敏捷
到了这个时候，才谈得上具体采用敏捷的哪种具体做法，从哪个点、薄弱环节切入进行改进，是敏捷需求，敏捷估算，敏捷计划，敏捷设计，敏捷测试，还是持续集成，或者其它 ... 敏捷 Practices 有几十种之多，CI 仅是其中的一种，而且从软件工程工艺的上下游关系看，CI 也不是应该优先考虑的敏捷实践。
如果问的是，推行敏捷做法从哪一种做法开始？可靠的答案是：不知道。不同的公司，不同的团队，遇到的实际问题和困难不尽相同，脱离具体环境，我们其实很难给出一个明确的答案，究竟推行敏捷从哪一种或哪几种做法开始，往往取决于对企业现状评估的结果。如果非要张恂给出一个首先项答案，我想一开始应该也不会包括 CI。
持续集成仅仅是推行敏捷起步的一个可选项，并非必须的。如果你们公司真的是因为软件集成频度不够出现了严重的问题，那么推行持续集成，大幅度提高集成频度，缩短集成周期至几小时以内，才有可能是合理的。
XP 是敏捷的，但敏捷不是 XP。认为一旦推行敏捷，就必须要做到 XP（或 XP 的某些做法），是一种常见的误解，受到了某些不恰当 marketing 的误导。推行敏捷方法、敏捷过程，其实有很多除 XP 及其措施之外的可选项和可行方案，包括 Scrum、Lean、AgileUP、中式太极敏捷以及各种自制的敏捷方法等等。
敏捷也不是某种具体的做法（practice），敏捷不是 TDD，不是 PP，也不是持续集成。在缺乏对敏捷和软件工程基本原理正确理解的情况下，盲目地推行某种敏捷甚至极限的具体做法，往往会导致幼稚的失败。
中西合璧的敏捷 OO 教练
www.zhangxun.com -
嗨，仝键，看了你的文章很受启发，再结合我曾经参与过的项目经验，写了一篇文章，试着探讨解决你的问题的途径。请你指教。
因为写的比较多，我也不知道怎么在InfoQ里发文，所以放在了一个了一个朋友的博客上面
blog.tianya.cn/blogger/post_show.asp?idWriter=8...
31 条回复
关注此讨论 回复