Scrum实施情况调查之案例分析

导读：
　　社区Agile主题敏捷实施,企业级敏捷标签Scrum作者李剑，在InfoQ中文站上发表了一篇"Scrum在中国——企业实施情况调查实录"。这份调查实录，分别调查了五个实施SCRUM的公司，其中三家公司实施成功，二家公司失败。我建议所有准备或者正在实施SCRUM 的人们都能来读一下。
　　在此，我们会对这篇文章中的案例分类进行分析、诊断。并探讨什么是敏捷开发方法、什么是SCRUM、使用敏捷方法需要什么条件、它可以解决什么问题以及如何在团队中合理的使用敏捷方法。
　　什么是敏捷开发方法？什么是SCRUM？有人在这个字面上下功夫，说敏捷就是反应要灵敏，动作要快捷；有人还在字面上进行延伸，说敏捷就是又好又快，或者就是多快好省；有人说敏捷就是光写代码不写文档；有人觉得敏捷就是没有制度，管理松散的工作方式；有人觉得只要敏捷了，就代表高软件交付水平。
　　那么，敏捷这个词到底由何而来呢？在九十世纪中期，涌现了一批软件行业的激进人士，他们反对那些以过程为本的重型软件开发方法（例如：传统的瀑布开发方 法）。在2001年，17位软件业界的专家们齐聚一堂，讨论正在兴起的轻量级开发方法（Lightweight methods）。专家们给这类轻量级的方法学起了一个新的名字叫做敏捷，并发布了敏捷开发者宣言。
　　敏捷方法强调以人为本，专注于交付对客户有价值的软件。在高度协作的开环境中，使用迭代式的方式进行增量开发，经常使用反馈进行思考、反省和总结，不停的进行自我调整和完善。
　　敏捷开发方法是这些轻量级方法的总称，它旗下有很多具体的开发过程和方法。主要的有：极限编程（XP）、特征驱动软件开发（FDD）、SCRUM开发方法 等等。SCRUM开发方法是由Jeff Sutherland在1993年创立，Jeff也是制定敏捷宣言的17位专家之一。SCRUM借用了橄榄球运动中的术语——一个团队拿球向前冲。
　　严格的说，SCRUM是遵循敏捷方法的一个软件开发框架。在SCRUM框架中，融入敏捷开发的精神和思想，就被称作SCRUM开发方法。SCRUM是一个 什么样的开发框架呢？简单说，它由三个角色（Role），三种会议（Ceremonie），三项工件（Artifact）组成。
　　角色（Role）：产品主管（Procuct Owner），他负责项目的商业价值；SCRUM师傅（ScrumMaster），他负责团队的运转和生产；以及自组织的团队。
　　会议（Ceremonie）：迭代计划会议，每日晨会（daily scrum meetings），迭代回顾会议。
　　工件（Artifact）：用来排列任务的优先级和跟踪任务。待开发任务列表（product backlog），迭代任务列表（the sprint backlog），进度图（burndown chart）
　　在敏捷刚出现的时候，极限编程（XP）一直是主流。但是，在敏捷方法开始在全世界流行的今天，为什么最红火的却是SCRUM？这是因为SCRUM更容易普 及和推广。其实极限编程包容了SCRUM方法。我们从工程学的角度，可以把软件开发分成两部分：过程（分解任务，排列优先级和迭代计划）和代码实现（高质 量的代码和自动化的代码保障体系）。其中最难的就是代码，最有直接商业价值的是过程。SCRUM则回避了最难的部分，加强和创新了最能直接体现商业价值的 过程部分。
　　这就是SCRUM！
　　现在，我们就开始对案例进行分析和诊断。
　　失败案例分析我们这里借用SCRUM实施调查中的两个词“成功”和“失败”。其实，我们很难定义成功和失败。在实施调查中，失败可以理解为使用SCRUM不当，没有到 达预先的期望，直至最后团队放弃了SCRUM。成功是意味着大家还在继续使用SCRUM，从某种程度上说，就是SCRUM达到了团队的预先期望，至少是可 以接受的期望。
　　我们先看第一失败案例：某知名大型互联网公司，被采访者是一个叫David的工程师。
　　他是这样总结失败的原因：“有些高层错误理解了Scrum和Agile，导致歪曲了某些东西，使得Agile变得形式化”
　　他们在项目中尝试使用了SCRUM中的一个实践：每日SCRUM会议。下面是David描述不了解SCRUM的项目经理，如何使用这个实践的：“项目经理发现这个东西挺好，就单独把Daily Scrum拿来进行推广；结果，这个经理并不理解什么是Scrum，他把Daily Scrum变成了Daily Report：每个员工都要在早上固定时间开Daily Scrum，然后把当天的任务告诉给他，让他来决定工作是不是饱满。而其他Scrum的精华部分都没有推广。”
　　有的网友分析，得出结论说失败是因为“这家大型互联网公司的制度和文化的问题”。当然，失败肯定是跟这有关系，但我觉得还没有直接上升到整个公司的制度和文化。
　　了解SCRUM的人，都会很清楚。他们对SCRUM的应用很初级，也只用了一个SCRUM中提到的晨会（其实，在其它很多的软件开发方法中都有这个实 践）。我们可以看出，他们的问题就是：项目经理根本不知道什么是SCRUM。也许连自己在开发中遇到了主要问题是什么都还不清楚？就四处寻药，甚至就给自 己下了一个处方。
　　我们就以每日晨会为例，在SCRUM中，明显的提到，在会议中每个人只可以说三件事情：
　　1. 我昨天做了什么
　　2. 我今天准备做什么
　　3. 我在工作中遇到了什么障碍。
　　每日晨会，目的有二点：
　　1. 加强团队交流和信息共享。互相了解彼此都在做什么工作，完成了什么任务。这样，每日的信息传递，可以让每个人可以更多的了解整个项目的业务和技术状况。并 且如果在工作中遇到障碍或问题，也可以在这时候提出来，请求大家的帮助（其实，一般在敏捷团队中，遇到问题，都会当场就提出来，或直接去找相关的同事，问 他们有没有处理过类似的问题，或者有没有一些建议）。
　　2. 促使每个人在早上做好一天的工作计划。这样，每个人一天的工作就会有明确具体的目标。这会直接提高一天的工作效率。
　　所以，上面的这个失败项目根本谈不上是在使用SCRUM。连基本的SCRUM框架还没有弄明白，就更谈不上敏捷的精神和思想了。
　　第二个失败案例是一个离岸开发的某创业型公司。虽然团队比较特殊（离岸开发团队），但这个失败案例却非常典型和普遍。“某一天，国外的PM突然发来几个链接，一看讲的是一个闻所未闻的词，就是Scrum了。好像就给了一两天的时间去看Scrum的介绍文档，然后就开Stand-up Meeting（站立会议）。”
　　和第一个案例相比，这个案例的团队是真真的在推行SCRUM。从表明看，大家也是在按照SCRUM框架的方式工作：有相应划分的角色，有具体的分解任务，有会议，也有迭代（Sprint）。那又怎么会失败呢？
　　显然，他们是在照搬照套了SCRUM的框架。他们是两个离岸的开发团队，因为地点、时区和语言的差异，很容易就会导致沟通和交流不畅，这时候再生硬的引入SCRUM，无异是火上浇油。
　　下面我们来看看他们是如何使用SCRUM。
　　1. 每日晨会
　　“其 实大家都知道沟通进度的重要性，但我们双方7、8个小时时差，那边一上班这边就快收拾东西走人了，就这样还要讲自己今天要做些啥，遇到啥困难，一点意思都 没有。很快Stand-up Meeting就成了形式。后来，我们又间歇性地在自己团队内部做Standup，但最后还是因为不能带给我们太大价值，流于形式，就放弃了。”其实，在敏捷的实践中，每日晨会是最容易做，也是最有效果的实践之一。那为什么最后会流于形式，而放弃了呢？
　　一、 会议的时间不好。中国团队快下班了，准备收拾回家。通过我们的实践，发现站立会议最佳的时间是早上。比如：9点上班，会议时间可以定在9：30。早上到公 司之后，大家收个邮件，处理一下个人的事务。到点了，按时的举行晨会，然后全身心的投入到一天的工作中。这样，很自然，开发节奏很畅快。
　　二、从上面的描述，明显可以看出来。大家对它是有抵触心理。或许是在抵触会议，或许是在抵触SCRUM，或许本来就已经上火，只是借此宣泄。
　　三、 这是最重要最重要的一点：团队的文化氛围。说具体一点，晨会不是每天的工作报告，更不是项目经理进行工作检查，甚至考核。项目经理有责任营造一个安全 （Safe）的会议氛围，让每个人都乐意说出真正发生的事情，就算是昨天遇到技术问题，没有任何的工作成果，也能得到谅解，而不是胆颤心惊。比如：我们在 每天早上做站立会议的时候，可以端杯饮料，很轻松的围成一圈，说说笑笑，然后会议结束，就开始一天的工作。
　　2. 迭代任务
　　
　　“在 第一次使用ScrumWorks的时候，好歹Product Owner还能来设置优先级，我们估算时间，最后决定哪些故事放到下一个Sprint里面。到后来就只要是人，就能往Scrumworks上扔任务，也不 知道哪些重要哪些不重要，我们自己开发人员看着办，最后剩下几百个小时完不成再扔到下一个Sprint里面去”显 然，大家的迭代过程很随意，松松散散，没有任何的约束。有的网友说这是公司制度的问题。那无疑是在“头痛医头，脚痛医脚”。如果，这时还拿制度说事，明显 是在和敏捷精神相悖。敏捷方法，表明看上去管理松散，没有规章制度。其实不然，它有很多的准则，要求每个人能够自觉遵守，养成工作习惯，成为一种职业素 质，最终目标是要形成一个自组织的团队。例如，谁可以往Scrumworks上扔任务？这明显是产品主管的职责。就算是开发人员想往上扔任务，也应该和产 品主管以及整个团队讨论，明确任务的价值和优先级之后，再决定是否可以把任务放到当前的Scrumworks上。这是最的基本要求，这是每个团队成员默认 遵守的原则，甚至可以认为这是一个开发者最起码的职业素质要求。
　　我们从上面的描述可以再次看出，大家是在对SCRUM有抵触的。如果，到现在，推广者到还不能让大家理解、认可和接受SCRUM方法。那么，引入SCRUM，也绝不可能获得成功，甚至会直接拖垮整个项目。
　　敏捷方法，需要有一个英明的领导（也许就是Scrum Master），以身作则，带领着团队向前冲锋，大家齐心协力，以项目的成功作为最高奋斗目标。只有这样，才能发挥敏捷方法的威力，只有这样项目才可能获得成功。
　　再回到迭代开发，它能给我们带来什么样的好处呢？
　　一、 明确的短期目标。如果让一个团队做半年的详细工作计划，一定非常困难，但如果是2周，那就完全不一样。假设，客户有100个东西要做，但团队在一个迭代 （一般是2周左右）中，只能完成20个东西。那么就明确的告诉客户，一个迭代的时间，我们只可以完成20个东西，那么我们先开发其中20个最有价值的东西 好吗？
　　二、如何知道团队在一个迭代可以完成多少任务呢？显然，迭代只有两周的时间，相对的计划会很准确，而且前面一个迭代的工作量，是这个迭代最好的参照。如果是第一个迭代，根据团队的经验做好一个合理的2周计划应该不难。
　　三、迭代结束之后，给客户演示工作成果，及早获得用户反馈。同时团队在一个迭代结束之后，也会对整个开发的状况进行思考和反省，举行一个回顾会议，客观的讨论前一段时间的工作，哪些地方做的好，哪些地方做得不够好，对不好的地方，要能讨论出具体可行的解决办法。
　　敏捷的团队就是用这种迭代的方式，增量的进行工作。小步前进，不停的思考、反省和总结，不停的进行自我调整和完善。让自己一步一步的变得优秀，走向卓越。
　　总而言之，如果只是学了SCRUM的形，却没有敏捷的意，没有掌握敏捷的思想和精神，那么再怎么使用SCRUM，仍然只是在东施效颦。
　　成功案例分析到此，也许你会吸取上面两个失败案例的教训，也认同文中的分析，觉得敏捷很实用、很有价值；也许此时，你却在紧缩双眉，因为敏捷的思想和精神，让你觉得有点理想化，不切实际。
　　是的，思想和精神只可意会不可言传。这些只可以在每天的工作和问题中去领悟、体会和沉淀。在学习敏捷方法的时候，我们 应该尽可能多和深入的学习，并融会贯通。在具体工作的时候，我们先要忘掉学到的条条框框。首先分析自己的上下文环境，找出最主要的矛盾，然后根据团队状 况，通过学到的经验和方法将这些问题进行平衡和解决。
　　下面我们看一下璎珞天色是如何在项目引入SCRUM的。他们路线是这样：“我们不是采用纯粹的Scrum，而是将Agile中的很多理念，包括XP的部分做法，然后结合现有的开发环境与要求，用Scrum的回顾不断地做改进， 从而趟出自己的一条路。如果这个Sprint我们回顾时觉得自己代码Review（审查）做的不好，下个Sprint就会引入新的代码Review机制。 这个Sprint觉得重复性的bug较多，下个Sprint就会引入缺陷预防机制。我们是自底向上，先做小范围试点，再全面推广，中间对过程进行不断改进”
　　他们的具体做法如下：“其实我们一开始并没有把Scrum这个说法拿出来。就是首先和业务一起商量什么时候上线，商量出来的结果是每个月定期上线。于是就有了一月一个项目的进 度（我们是线上服务，没有版本的概念，有一堆需求过来，对技术来说就是在这一个月以内完成这些需求，把这一个月以内的工作叫一个项目）。然后为了管理，我 们开始开晨会。然后为了改进，我们开始开项目总结会，把Product review和Team retrospective放在一起，既有产品经理介绍现状，也有大家讨论成绩，不足和挑战。后来总结会上觉得质量不好，我们加入了单元测试和代码 Review机制。至于计划会议，一开始我们就采用的Scrum的方法。项目小，MS Project太难调。我们就更换了Scrum的Excel计划表，后来又换了Xplanner。”
　　无独有偶，这些成功案例的团队，就是通过这样的方式进行一步一步推进，把SCRUM成功的引入到了各自的项目中。其中三个成功实施SCRUM的公司，无疑是璎珞天色的团队最能深入敏捷的精髓。
　　小结敏捷就是一个团队持续不断的自我改进过程，直到那些优秀的品质成为大家的一种职业习惯——一个自组织的团队。敏捷没有终点，我们一直在路上。
　　参考资料 * 《敏捷开发者修炼之道》
　　* "Scrum在中国——企业实施情况调查实录"
　　* http://www.scrumalliance.org 　　作者介绍
　　钱安川，ThoughtWorks公司－软件咨询师、敏捷过程教练、开发者。敏捷项目管理工具Mingle的团队成员之一。关注中国传统文化知识。
　　38条回复
　　Nice!发表人 Myhui Zhang 发表于 2008年5月7日 下午8时24分
　　Re: Nice!发表人 凉粉 小刀 发表于 2008年5月7日 下午11时0分
　　关于敏捷的基本含义 与 打破西式敏捷的话语垄断发表人 Charlie Zhang 发表于 2008年5月7日 下午9时21分
　　Re: 关于敏捷的基本含义 与 打破西式敏捷的话语垄断发表人 凉粉 小刀 发表于 2008年5月7日 下午9时55分
　　Re: 其实所有人都在盲人摸象发表人 Charlie Zhang 发表于 2008年5月7日 下午10时1分
　　Re: 关于敏捷的基本含义 与 打破西式敏捷的话语垄断发表人 乐 田 发表于 2008年5月7日 下午10时10分
　　Re: 熊节不是文青？发表人 Charlie Zhang 发表于 2008年5月7日 下午10时29分
　　Re: 熊节不是文青？发表人 乐 田 发表于 2008年5月7日 下午10时45分
　　Re: 熊节不是文青？发表人 凉粉 小刀 发表于 2008年5月7日 下午10时56分
　　Re: 关于敏捷的基本含义 与 打破西式敏捷的话语垄断发表人 qian anchuan 发表于 2008年5月7日 下午10时21分
　　Re: 关于敏捷的基本含义 与 打破西式敏捷的话语垄断发表人 Kaijin Lv 发表于 2008年5月7日 下午10时40分
　　Re: 关于敏捷的基本含义 与 打破西式敏捷的话语垄断发表人 ozzzzzz liu 发表于 2008年5月8日 上午12时39分
　　少了sprint review？发表人 Yi Xu 发表于 2008年5月7日 下午10时36分
　　Re: FAQ: 少了sprint review？发表人 Charlie Zhang 发表于 2008年5月7日 下午11时11分
　　质疑本文作者对 Scrum 的理解发表人 Charlie Zhang 发表于 2008年5月7日 下午11时1分
　　Re: 质疑本文作者对 Scrum 的理解发表人 柳 轻眉 发表于 2008年5月7日 下午11时6分
　　Re: 质疑本文作者对 Scrum 的理解发表人 柳 轻眉 发表于 2008年5月7日 下午11时9分
　　Re: 质疑本文作者对 Scrum 的理解发表人 qian anchuan 发表于 2008年5月8日 上午1时16分
　　哦，原来你也只是在字面上理解敏捷和 Scrum发表人 Charlie Zhang 发表于 2008年5月8日 下午11时3分
　　软件开发=过程+代码实现，荒唐，作者好像不懂软件工程？！发表人 Charlie Zhang 发表于 2008年5月8日 上午2时59分
　　Re: 软件开发=过程+代码实现，荒唐，作者好像不懂软件工程？！发表人 qian anchuan 发表于 2008年5月8日 上午4时17分
　　Re: 软件开发=过程+代码实现，荒唐，作者好像不懂软件工程？！发表人 YONG LIN 发表于 2008年5月8日 上午5时44分
　　Re: 软件开发=过程+代码实现，荒唐，作者好像不懂软件工程？！发表人 qian anchuan 发表于 2008年5月8日 上午6时36分
　　Re: 不用管作者的狡辩发表人 Charlie Zhang 发表于 2008年5月8日 上午6时44分
　　Re: 设计就是代码？发表人 Charlie Zhang 发表于 2008年5月8日 上午6时16分
　　Re: 设计就是代码？发表人 qian anchuan 发表于 2008年5月8日 上午7时10分
　　Re: 设计就是代码？发表人 凉粉 小刀 发表于 2008年5月8日 上午7时36分
　　支持！晒晒熊节的人身攻击，供大家参考发表人 Charlie Zhang 发表于 2008年5月9日 上午3时50分
　　Re: 支持！晒晒熊节的人身攻击，供大家参考发表人 li dapeng 发表于 2008年5月9日 上午4时32分
　　Re: 支持！晒晒熊节的人身攻击，供大家参考发表人 Charlie Zhang 发表于 2008年5月12日 上午4时33分
　　Re: 支持！晒晒熊节的人身攻击，供大家参考发表人 li dapeng 发表于 2008年5月14日 上午1时38分
　　Re: 支持！晒晒熊节的人身攻击，供大家参考发表人 凉粉 小刀 发表于 2008年5月9日 上午4时40分
　　你错了，任何人都有权评价你和其他 ThoughtWorks 咨询师发表人 Charlie Zhang 发表于 2008年5月8日 下午10时33分
　　Re: 你错了，任何人都有权评价你和其他 ThoughtWorks 咨询师发表人 qian anchuan 发表于 2008年5月8日 下午11时39分
　　眼前所见的喧哗难道就是百家争鸣！？发表人 li dapeng 发表于 2008年5月9日 上午1时20分
　　Re: 眼前所见的喧哗难道就是百家争鸣！？发表人 rick chen 发表于 2008年5月9日 上午2时33分
　　Re: 争吵不是张恂的本意发表人 Charlie Zhang 发表于 2008年5月9日 上午3时40分
　　Re: 眼前所见的喧哗难道就是百家争鸣！？发表人 sheng wang 发表于 2008年5月15日 上午4时35分
　　Nice!
　　2008年5月7日 下午8时24分 发表人 Myhui Zhang
　　最喜欢这句话敏捷没有终点，我们一直在路上。关注scrum的还可以参考一下这个mini book,非常好的实践总结。http://www.infoq.com/minibooks/scrum-xp-from-the-trenches
　　关于敏捷的基本含义 与 打破西式敏捷的话语垄断
　　2008年5月7日 下午9时21分 发表人 Charlie Zhang
　　作者 钱安川 发布于 2008年5月7日 下午7时29分：
　　有人在这个字面上下功夫，说敏捷就是反应要灵敏，动作要快捷；有人还在字面上进行延伸，说敏捷就是又好又快，或者就是多快好省
　　这个“有人”大概就是指张恂吧。没错，这些就是我们中式太极敏捷的主张，除了只“在字面上下功夫”。要真正理解敏捷，从基本概念、字面含义开始不啻为一种好方法。
　　“敏捷就是反应要灵敏，动作要快捷；敏捷就是又好又快，或者就是多快好省”，不但是我们中式敏捷的基本主张，也符合西式 Agile、light-weight 过程的基本含义。当然，Agile 的含义不止于迭代和轻载。
　　如果一种方法不具有英文单词 Agile 的基本含义，怎么会叫 Agile？难道西方的敏捷大师们也都是些文盲？不会吧。作为一名本土中国人，我也始终弄不明白，为什么一种方法不能做到起码的“敏”和“捷”，可以叫“敏捷”？作为知识分子、知识青年的我国程序员们，逻辑思维不能这样差吧。
　　当然，张恂的文章《Agile 与太极敏捷：到底啥是敏捷？》只是初初开了个头，从敏捷这个单词的基本含义讲起（实在看不惯国内一些文盲型的程序员老是在那里忽悠），敏捷的含义当然非常丰富，不仅如此。
　　张恂差不多有 8 年以上的敏捷实践经验，可能是国内最早采用敏捷实践的程序员之一（早于 2001 年），因此决不是在玩字面，比 ThoughtWorks 咨询师熊节（Jeff Xiong）那一派的弄文青年要好得多。
　　我觉得，在中国推广敏捷，首先要打破 ThoughtWorks 和西式敏捷的“话语垄断”（如果这种垄断存在的话），尤其要警惕某些人片面打着 ThoughtWorks 或者西方敏捷大师的旗号、话语来误导。
　　敏捷 OO 教练 张恂
　　www.zhangxun.com
　　Re: 关于敏捷的基本含义 与 打破西式敏捷的话语垄断
　　2008年5月7日 下午9时55分 发表人 凉粉 小刀
　　瞎子只摸到大象的尾巴，所以觉得大象跟蛇长得一样。
　　“敏捷就是反应要灵敏，动作要快捷；敏捷就是又好又快，或者就是多快好省”。这种说法跟盲人摸象有什么区别？
　　玩“窥一斑而知全豹”也没这么玩的啊
　　Re: 其实所有人都在盲人摸象
　　2008年5月7日 下午10时1分 发表人 Charlie Zhang
　　你说的很对，搞科学技术，其实所有人都在盲人摸象。
　　把大家的意见拼起来，就接近全豹了。
　　要不，你给我弄只全豹来看看 ...
　　2008年5月7日 下午9时55分 发表人 凉粉 小刀
　　瞎子只摸到大象的尾巴，所以觉得大象跟蛇长得一样。
　　“敏捷就是反应要灵敏，动作要快捷；敏捷就是又好又快，或者就是多快好省”。这种说法跟盲人摸象有什么区别？
　　玩“窥一斑而知全豹”也没这么玩的啊
　　Re: 关于敏捷的基本含义 与 打破西式敏捷的话语垄断
　　2008年5月7日 下午10时10分 发表人 乐 田
　　根本没有必要去攻击熊节，因为他不是文青，在引导大家接受敏捷的过程中他还贡献了不少开源项目，是实践与讲授相结合的。不写代码瞎白话那才是乱来。敏捷不分国界，没有必要有中外之分。敏捷是以团队为单位的实践，在使用的过程中是混合的。我觉得非要提出所谓太极敏捷这样一个口号，真的是无聊。敏捷开发者通过交流可以不断的改进自己使用的过程！所以说永远是在路上的。这个年代方法不应该分国界，开口闭口西方怎么样，中国怎么样，这才叫欺骗和利用民族感情而实现自己的不可告人的目的。
　　Re: 关于敏捷的基本含义 与 打破西式敏捷的话语垄断
　　2008年5月7日 下午10时21分 发表人 qian anchuan
　　这个“有人”大概就是指张恂吧。没错，这些就是我们中式太极敏捷的主张，除了只“在字面上下功夫”。要真正理解敏捷，从基本概念、字面含义开始不啻为一种好方法。 当然，这是贵教派的理解和教义，你有权利执意把敏捷理解为：敏捷就是反应要灵敏，动作要快捷；敏捷就是又好又快，或者就是多快好省但，这只是一些文字面的解释，并不是敏捷开发方法的真正内涵。别以为自己把‘敏捷’的中文含义弄明白了，就不是文盲了。
　　如果教主想讨论scrum，讨论敏捷，讨论软件技术；非常欢迎。别把话题扯那么远。文章发在社区，就是社区的声音。
　　Re: 熊节不是文青？
　　2008年5月7日 下午10时29分 发表人 Charlie Zhang
　　2008年5月7日 下午10时10分 发表人 乐 田
　　根本没有必要去攻击熊节，因为他不是文青 ...他不是文青？我看你太无知了，一点不了解历史。新来的？
　　熊节早在 2005 年之前就成为名家了，难得的 CSDN、《程序员》杂志高产技术作家，数一数二的以文笔著称的文青，麦克卢汉的忠实拥趸者 ...
　　而且，早在 2004 年就侮辱自己的批评者为裤腿追咬者，现在不但给 ThoughtWorks 丢脸，还给 InfoQ 的中文编辑团队丢脸。
　　你好像也是 TW 员工吧，熊节的同事？我看你的基本价值观也有问题。请告诉我什么是 ThoughtWorks values？您应该参加过新员工培训吧。
　　作为专业程序员，请你记住：没有调查，就没有发言权。
　　少了sprint review？
　　2008年5月7日 下午10时36分 发表人 Yi Xu
　　会议（Ceremonie）：迭代计划会议，每日晨会（daily scrum meetings），迭代回顾会议。是不是少了sprint review？
　　Re: 关于敏捷的基本含义 与 打破西式敏捷的话语垄断
　　2008年5月7日 下午10时40分 发表人 Kaijin Lv
　　中式敏捷是什么意思，敏捷分中外吗？还加上太极，搞得跟什么似的。前一阵，看到有人千里迢迢去清华学习所谓的“周易管理学”。那个所谓的“周易管理学”跟你的“中式太极敏捷”有异曲同工之妙啊！我说，最值得警惕的不是ThoughtWorks那帮人，而是像你这样，把别人的好东西拿来，加上点中国人自己发明的”糟粕“，然后自以为可以自成一派，挂羊头卖狗肉，到处忽悠钱财的人。
　　Re: 熊节不是文青？
　　2008年5月7日 下午10时45分 发表人 乐 田
　　我了解历史，我也了解你的事情，没有什么奇怪的。作为程序员你应该知道技术推动的价值！不要随便攻击别人写的东西。 InfoQ和ThoughtWorks都是我工作中的团队，我了解我的同事们。而且作为一个没事总是出来职责别人的人，我不知道你给社区贡献了什么呢？如果你坚信你的观点，请你来参加Beijing Open Party，欢迎和我们面对面的讨论问题，不要用你流畅的文笔来散布这种没有意义的言论。
　　Re: 熊节不是文青？
　　2008年5月7日 下午10时56分 发表人 凉粉 小刀
　　赞。
　　我们正在讨论在Beijing OpenParty中添加新的活动形式，包括pk挑战赛等。如果掌门愿意自降身价跟我们这些草莽见面的话，不妨过来玩玩
　　Re: Nice!
　　2008年5月7日 下午11时0分 发表人 凉粉 小刀
　　感谢关注，这本书即将翻译完成。中文版会很快跟大家见面的。
　　质疑本文作者对 Scrum 的理解
　　2008年5月7日 下午11时1分 发表人 Charlie Zhang
　　作者 钱安川 发布于 2008年5月7日 下午7时29分
　　严格的说，SCRUM是遵循敏捷方法的一个软件开发框架。在SCRUM框架中，融入敏捷开发的精神和思想，就被称作SCRUM开发方法。SCRUM是一个 什么样的开发框架呢？简单说，它由三个角色（Role），三种会议（Ceremonie），三项工件（Artifact）组成。
　　作者所谓的“严格的说”，一点儿不严格。
　　严格地说，Scrum 原本是一个敏捷、迭代的项目管理框架，并不是什么软件开发框架。management 与 development、engineering 的含义不同吧。
　　正是因为 Scrum 是一个灵活、轻量的项目管理框架，缺少了具体的工程做法（engineering practices），它才可以与其它许多更为具体的软件工程方法、开发框架互为补充，才会出现 Scrum + XP、Scrum + UP 等等集成/组合。
　　正是因为这个特点，Scrum 才有了比 XP 更为广泛的适用范围。实际上，Scrum 不但可用于软件工程的敏捷项目管理，还可以应用到其它领域的项目管理。
　　显然，作者并没有真正地理解、把握 Scrum 的本质。
　　敏捷 OO 教练 张恂
　　www.zhangxun.com
　　Re: 质疑本文作者对 Scrum 的理解
　　2008年5月7日 下午11时6分 发表人 柳 轻眉
　　终于看到不是嗷嗷的掐架的了……
　　Re: 质疑本文作者对 Scrum 的理解
　　2008年5月7日 下午11时9分 发表人 柳 轻眉
　　8过偶也粉赞同Charlie滴观点，把Scrum说是软件开发框架有点偏离鸟Scrum滴本质
　　Re: FAQ: 少了sprint review？
　　2008年5月7日 下午11时11分 发表人 Charlie Zhang
　　会议（Ceremonie）：迭代计划会议，每日晨会（daily scrum meetings），迭代回顾会议。 是不是少了sprint review？sprint = iteration
　　Re: 关于敏捷的基本含义 与 打破西式敏捷的话语垄断
　　2008年5月8日 上午12时39分 发表人 ozzzzzz liu
　　其实你可以去问问拉曼，看看当初是不是差点就把敏捷命名为轻型。是不是如果叫了轻型，就又如何如何了。而且你也知道Cockburn的水晶方法，是不是就真的水晶了。我觉得你这个人真的有得时候太那个了。当然你要说敏捷里面有随机应变，反应迅速的内涵，这个是正确的。但是你要是敏捷就是，如何如何，自然就有逻辑上的问题吧。其实对于敏捷究竟是什么最明确也是最统一的表述，就是敏捷宣言。其实我想你回到这个大背景下，未必不是一件好事情。而且既然你跟拉曼那么熟悉，你也可以去跟他们好好交流交流，把你的思想完全表达给他听听，看看你们是不是也可以达成共识。当然你希望在敏捷的基础上发展敏捷，造就有中国特色的敏捷方法，也是可以理解的。但是我觉得你应该光明正大的把你的观点全面亮出来，也就是你的这个敏捷是你自己发展出来的，同我们现在所说的敏捷不完全是一回事。而且你也别动不动就说你几年几年前就实施敏捷了，这样的话说出来，对你没啥好作用。你也是三十几岁，奔四十去的人了，这个道理不应该叫我给你讲。
　　Re: 质疑本文作者对 Scrum 的理解
　　2008年5月8日 上午1时16分 发表人 qian anchuan
　　严格地说，Scrum 原本是一个敏捷、迭代的项目管理框架，并不是什么软件开发框架。management 与 development、engineering 的含义不同吧
　　很明显软件开发，包括了软件的项目管理。建议您先去scrumalliance好好阅读一下，弄清楚SCRUM,再过来讨论
　　http://www.scrumalliance.org/pages/what_is_scrumA lean approach to software development
　　Scrum is an agile software development framework. Work is structured in cycles of work called sprints, iterations of work that are typically two to four weeks in duration. During each sprint, teams pull from a prioritized list of customer requirements, called user stories, so that the features that are developed first are of the highest value to the customer. At the end of each sprint, a potentially shippable product is delivered.
　　A simple framework
　　Scrum is made up of three roles, three ceremonies, and three artifacts.
　　Three roles: the Product Owner, who is responsible for the business value of the project; the ScrumMaster, who ensures that the team is functional and productive; and the self-organized team.
　　Three ceremonies: the sprint planning meeting, daily scrum meetings, and sprint review meetings.
　　Three artifacts for prioritizing and tracking tasks: the product backlog, the sprint backlog, and a burndown chart.
　　关于SCRUM和XP的关系。我认为，可以说XP就是SCRUM的高级阶段。当然，你也可以XP + SCRUM。但，这些并不重要。因为，敏捷方法学的核心都是不可生搬硬套的。最重要的是，如何通过敏捷的方式，改进你的团队和项目，提高项目的交付质量。
　　软件开发=过程+代码实现，荒唐，作者好像不懂软件工程？！
　　2008年5月8日 上午2时59分 发表人 Charlie Zhang
　　作者 钱安川 发布于 2008年5月7日 下午7时29分
　　我们从工程学的角度，可以把软件开发分成两部分：过程（分解任务，排列优先级和迭代计划）和代码实现（高质 量的代码和自动化的代码保障体系）。其中最难的就是代码，最有直接商业价值的是过程。SCRUM则回避了最难的部分，加强和创新了最能直接体现商业价值的 过程部分。这里明明说，软件开发 = 过程（分解任务，排列优先级和迭代计划） + 代码实现（XPer 的脑子里大概只有代码实现）
　　可是后面又说：2008年5月8日 上午1时16分 发表人 qian anchuan
　　... 很明显软件开发，包括了软件的项目管理 ...好了，怎么又冒出一个项目管理，那么请作者解释一下，你说的项目管理到底是属于过程，还是代码实现？你的软件工程等式有问题吧，真是一笔糊涂帐。
　　我想，作为一名职业软件工程师，通常的理解大概是这样的：
　　软件开发 = 需求 + 设计 + 实现 + 测试 + 过程 + 项目管理 ...
　　作者所说的过程（分解任务，排列优先级和迭代计划），其实通常属于软件项目管理范畴，而作者在这里把项目管理、过程混为一谈，而且大大缩减了软件开发的内涵。所以，绝不是作者所说的，软件开发只有两部分，过程和代码实现！而且还说什么，“其中最难的就是代码”。
　　作者分得清什么是 design 和 implementaion 吗？请到 Martin Fowler、Kent Beck 的著作里找找 design、implementation 这两个词的区别，看看设计有多么普遍。
　　设计是因，代码（实现）是果。好的软件是靠设计出来的，软件开发中，最难的部分当然是设计（包括算法设计、数据结构设计、软件架构设计等等）了。
　　我觉得这段文字，反映出来的完全是作者对于 XP 和软件工程内涵的弯曲、片面理解和错乱的逻辑，属于 XPer 的 bad smells。我都怀疑你有没有经过正规的 XP 培训，怎么到您这儿，软件开发就只剩过程和代码实现了？这种分类一点儿不科学。
　　敏捷 OO 教练 张恂
　　www.zhangxun.com
　　Re: 软件开发=过程+代码实现，荒唐，作者好像不懂软件工程？！
　　2008年5月8日 上午4时17分 发表人 qian anchuan
　　你说的项目管理到底是属于过程，还是代码实现？你的软件工程等式有问题吧，真是一笔糊涂帐。 我明确回答你，我的过程指的是除了程序技术之外的项目活动，包括了项目管理部分。比如：分解任务，排列优先级、迭代计划，还有相关的会议部分。
　　我们最后交付给客户的是什么？可运行的软件（当然，如果客户愿意花钱买文档也可以），那就是你的代码相关的部分，所有活动的目的都在此。如果有人觉得有了需求和设计，剩下编码就是一帮软件蓝领的活，那就脱离了一切讨论的前提。
　　设计是因，代码（实现）是果。好的软件是靠设计出来的，软件开发中，最难的部分当然是设计不好意思，在所有的敏捷开发方法中，从没有你这样的说法。相反，是反对单纯的设计，这很容易过渡设计，造成浪费，设计不合实际的东西。所以，为了消除以过程为主的软件开发方法带来的大量浪费，才发起了敏捷运动。所以，你说的设计，估计这又是你的中国特色，又是中国式敏捷了。
　　设计很重要。但更重要的是设计出来的东西必须是可以实现的（在允许的成本之内）。所以，最好的设计就是最好的代码，最好的代码，也就会是最好的设计。
　　软件开发 = 需求 + 设计 + 实现 + 测试 + 过程 + 项目管理这个公式，怎么我又面熟又陌生呢。原来：瀑布开发模型 ＝ 需求分析＋设计＋实现＋测试＋安装＋维护我都怀疑你有没有经过正规的 XP 培训请问，你经过正规的XP 培训了？哪个培训机构给你做的培训，又是哪一个讲师给你传授了XP。
　　Re: 软件开发=过程+代码实现，荒唐，作者好像不懂软件工程？！
　　2008年5月8日 上午5时44分 发表人 YONG LIN
　　设计很重要。但更重要的是设计出来的东西必须是可以实现的（在允许的成本之内）这句话100%赞同。 但是最好的设计就是最好的代码，最好的代码，也就会是最好的设计就不完全太苟同了。 在我们的开发团队中，“设计”至少包含两种：第一种是针对需求和业务做出的high-level design，比如业务上的流程设计，业务之间的接口设计等，这是需要对用户业务非常熟悉的分析师来做的（我们的分析师都是有多年编程经验，对用户业务非常熟悉的高级工程师慢慢培养出来的），这些设计是需要详细的文档的，必要时候，还需要和用户沟通；第二种是具体代码编写时候，对模块划分，类的设计，算法，逻辑控制的detail-level design，做这种design时，通常也会设计和编写unit test case，对这种design，一般就没有非常规格化的文档了，代码就是设计了。 这两种design，都会随着编码和开发的深入不断的review和修正，改进（代码一级可能就是重构了）。如果把代码直接理解为设计，我觉得有点太极端了。
　　Re: 设计就是代码？
　　2008年5月8日 上午6时16分 发表人 Charlie Zhang
　　2008年5月8日 上午4时17分 发表人 qian anchuan
　　设计很重要。但更重要的是设计出来的东西必须是可以实现的（在允许的成本之内）。所以，最好的设计就是最好的代码，最好的代码，也就会是最好的设计。第一句“设计很重要。但更重要的是设计出来的东西必须是可以实现的（在允许的成本之内）”，我同意，设计应该通过编码和测试的检验，但这并得不出后面的结论，或者可以在软件开发中把设计抹掉。
　　design 是 design，source codes 是 source codes；OOD 是 OOD，OOP 是 OOP。设计是代码的抽象（比代码高一层），代码是设计的具体实现，两者虽然有联系，但显然不是一码事，不能混为一谈。
　　算法设计当然是一种设计，模式设计也是一种设计。你能说算法就是代码？同样的设计、算法、模式、数据结构等抽象，可以有不同的代码实现。最好的设计未必有最好的实现（代码）。
　　软件工程大师、你们公司 ThoughtWorks 首席科学家 Martin Fowler 就是一位 OOAD 大师。如果你连什么是 OOA、OOD、OOP，什么是设计，什么是实现，什么是抽象和具象，都分不清，我觉得你没有什么脸面做 ThoughtWorks 咨询师。你所理解的 XP 是片面的。
　　我不知道，为什么到了你们这一批国内的 XPers 嘴里，design 就消失了，即便在 Kent Beck 那里 design 和 coding 也是分得清楚的吧（当然 XP 的设计可能更多是 implicit design activities，存于头脑中或白板上的轻便设计）。
　　2008年5月8日 上午4时17分 发表人 qian anchuan
　　我明确回答你，我的过程指的是除了程序技术之外的项目活动，包括了项目管理部分。比如：分解任务，排列优先级、迭代计划，还有相关的会议部分。Ok，你说的 process 包括“除了程序技术之外的项目活动”，而你的等式是软件开发 = 过程 + 代码实现，那么软件设计在哪里？因为代码比设计重要，所以就刻意抹掉设计？
　　你怎么自圆其说？发现我们之间完全是两个逻辑系统。
　　张恂
　　Re: 软件开发=过程+代码实现，荒唐，作者好像不懂软件工程？！
　　2008年5月8日 上午6时36分 发表人 qian anchuan
　　设计很重要。但更重要的是设计出来的东西必须是可以实现的（在允许的成本之内）这句话100%赞同。 但是最好的设计就是最好的代码，最好的代码，也就会是最好的设计就不完全太苟同了。 在我们的开发团队中，“设计”至少包含两种：第一种是针对需求和业务做出的high-level design。。。。。第二种是具体代码编写时候，对模块划分，类的设计，算法，逻辑控制的detail-level design，做这种design时，通常也会设计和编写unit test case，对这种design，一般就没有非常规格化的文档了，代码就是设计了。如果把代码直接理解为设计，我觉得有点太极端了。我觉得YONG LIN说的对。关于你说的，我和一些朋友也激烈讨论过。我的那句话，主要是对后面的一种情况完全成立。那句话是用来批判这个的：设计是因，代码（实现）是果。好的软件是靠设计出来的，软件开发中，最难的部分当然是设计
　　Re: 不用管作者的狡辩
　　2008年5月8日 上午6时44分 发表人 Charlie Zhang
　　大致同意，你们做得不错。
　　2008年5月8日 上午5时44分 发表人 YONG LIN
　　在我们的开发团队中，“设计”至少包含两种：第一种是针对需求和业务做出的high-level design，比如业务上的流程设计，业务之间的接口设计等，这是需要对用户业务非常熟悉的分析师来做的（我们的分析师都是有多年编程经验，对用户业务非常熟悉的高级工程师慢慢培养出来的），这些设计是需要详细的文档的，必要时候，还需要和用户沟通；第二种是具体代码编写时候，对模块划分，类的设计，算法，逻辑控制的detail-level design，做这种design时，通常也会设计和编写unit test case，对这种design，一般就没有非常规格化的文档了，代码就是设计了。 这两种design，都会随着编码和开发的深入不断的review和修正，改进（代码一级可能就是重构了）。 如果把代码直接理解为设计，我觉得有点太极端了。 即便在 detailed level design，代码仍然不是设计。代码只是设计的一种结果和表现，设计的内容要比代码多。
　　对于同一个复杂问题的 design，需要考虑各种 forces、constrains、alternative solutions 和 tradeoffs 等等，这些都能在代码上反映吗？不能吧，也就是说 design 的内容很可能要多于 implementaion，而且 design 和 codes 本来就不在一个抽象层次上。
　　作者分不清设计和代码实现，是一个软件工程基本功的问题。
　　OOAD*UML 专家 张恂
　　www.zhangxun.com
　　Re: 设计就是代码？
　　2008年5月8日 上午7时10分 发表人 qian anchuan
　　我觉得你没有什么脸面做 ThoughtWorks 咨询师我有没有脸面做 ThoughtWorks 咨询师，你张询有什么资格在这里评论？你就觉得，自己有脸面自封所谓的中国式太极敏捷的太极掌门人。
　　我严重申明:社区是用来讨论技术问题。可以有不同的意见和观点。我已经跟你说的很清楚了，我在社区发表的文章就代表了社区的声音。而且，文章中没有一个字提及和ThoughtWorks相关的字眼。希望你不要再有这样类似的句子出现。否则，我就有理由对你作为人的属性提出质疑。我不会也没有必要跟这样一个人进行任何的技术讨论。
　　我不知道，为什么到了你们这一批国内的 XPers 嘴里，design 就消失了别给我按个头衔之类的，我不是XPer，我也从没有这样自封过。软件开发 = 过程 + 代码你的这个等式是很不严格的。不是我的观点。我认为，后面两项是软件开发最主要的部分。关于代码和设计哪个重要，很显然它们不是你死我亡的关系。这是两个不同类的东西，而且设计是无形的，代码是有形的载体，是最终的产物，代码是验证一个设计好坏的最佳方式。我没有提及设计，并不表示就不要设计，当然，现在提及了也并不是说就一定要有单纯的设计。我同意上面YONG LIN的说法。
　　Re: 设计就是代码？
　　2008年5月8日 上午7时36分 发表人 凉粉 小刀
　　让我们在争论技术问题的时候，少一些人身攻击吧……
　　你错了，任何人都有权评价你和其他 ThoughtWorks 咨询师
　　2008年5月8日 下午10时33分 发表人 Charlie Zhang
　　2008年5月8日 上午7时10分 发表人 qian anchuan
　　我觉得你没有什么脸面做 ThoughtWorks 咨询师
　　我有没有脸面做 ThoughtWorks 咨询师，你张询有什么资格在这里评论？你就觉得，自己有脸面自封所谓的中国式太极敏捷的太极掌门人。
　　我严重申明:社区是用来讨论技术问题。 可以有不同的意见和观点。我已经跟你说的很清楚了，我在社区发表的文章就代表了社区的声音。而且，文章中没有一个字提及和ThoughtWorks相关的字眼。你在作者简介中写道：作者介绍
　　钱安川，ThoughtWorks公司－软件咨询师、敏捷过程教练、开发者。敏捷项目管理工具Mingle的团队成员之一。关注中国传统文化知识。我想，ThoughtWorks 公司这一点做得很好，在网站上公布了 ThoughtWorks Values 和行为准则，其中一个作用就是便于大家的监督。
　　希望你和其他 ThoughtWorks 咨询师都应该明白，不要以为带了 ThoughtWorks 咨询师的头衔，获得的只有风光和利益。如果你们的言行不符合 ThoughtWorks 员工的行为规范，达不到职业软件工程师该有的水准，就会遭到大家的批评。
　　此外，我的原话是：软件工程大师、你们公司 ThoughtWorks 首席科学家 Martin Fowler 就是一位 OOAD 大师。如果你连什么是 OOA、OOD、OOP，什么是设计，什么是实现，什么是抽象和具象，都分不清，我觉得你没有什么脸面做 ThoughtWorks 咨询师。我说的是假设，是有前提的，希望你不要误解和误导。有没有脸面做，应该由你本人作出判断。断章取义是很拙劣的辩论技巧。
　　关于太极敏捷派的“掌门”之称谓，只是我的一句玩笑话，既然引发了这么多人的不安、焦躁和红眼，那么以后我不叫就是了。
　　张恂
　　哦，原来你也只是在字面上理解敏捷和 Scrum
　　2008年5月8日 下午11时3分 发表人 Charlie Zhang
　　作者 钱安川 发布于 2008年5月7日 下午7时29分
　　严格的说，SCRUM是遵循敏捷方法的一个软件开发框架。ScrumAlliance：“Scrum is an agile software development framework.”
　　并不是一种严格的说法，请注意，关键词在“严格”。如果让“开发”包含了“项目管理”，那么说 Scrum 是开发框架，也算 ok，不是什么大错，但并不严格。
　　作为开发框架，Scrum 与 RUP、XP 显然有明显的区别，因为 Scrum 中并不包含如何做需求，如何做设计、编码，如何做测试 ... 的指导，需要填补其它的开发方法（工程实践）。Scrum is made up of three roles, three ceremonies, and three artifacts.
　　Three roles: the Product Owner, who is responsible for the business value of the project; the ScrumMaster, who ensures that the team is functional and productive; and the self-organized team.
　　Three ceremonies: the sprint planning meeting, daily scrum meetings, and sprint review meetings.
　　Three artifacts for prioritizing and tracking tasks: the product backlog, the sprint backlog, and a burndown chart. 看了 ScrumAlliance 定义的内容就知道，本质上，Scrum 就是一个简约的敏捷、迭代项目管理框架，它不但适用于软件开发、软件工程，还可以用在其它管理领域，显然这是更为准确和严格的说法。
　　如果 Scrum 只是一个软件开发框架的话，那么原案例中的：张汉东：我们整个公司现在采用Scrum式的管理，如开发部门，销售部门及HR部都会遵守Scrum规则。因为我们也是初次尝试使用Scrum，所以大家都严格遵守规则。有新人进来的时候，也没有立即给新人讲解Scrum的概念，只是让他在日常的工作中，慢慢习惯Scrum规则。公司暂时完成了两个Sprint尝试，收益不敢说有多大，起码让我们每个人每天的工作都很有目标感，让我们在客户所规定的期限里完成了那个迭代。我们正在准备启动下一个Scrum开发项目。总的来说，一句话，我们也是在Scrum的尝试中。怎么解释？销售、HR 不会也属于“软件开发”吧？
　　显然，我觉得张汉东及其同事们比你更懂 Scrum，他们领会了 Scrum 作为迭代式管理框架的精髓。
　　敏捷 OO 教练 张恂
　　www.zhangxun.com
　　Re: 你错了，任何人都有权评价你和其他 ThoughtWorks 咨询师
　　2008年5月8日 下午11时39分 发表人 qian anchuan
　　你在作者简介中写道： 作者介绍 钱安川，ThoughtWorks公司－软件咨询师、敏捷过程教练、开发者。敏捷项目管理工具Mingle的团队成员之一。关注中国传统文化知识。 我是只文章的内容中没有提及ThoughtWorks，这是作者介绍。是InfoQ要求我提供的。你发表一篇文章，然后杂志社让你提供作者介绍，对这个教主也有非议。我真不明白，我作为一个ThoughtWorker已经几年了，现在发表一篇文章，有个署名，就让某些人心理这么不安吗？而且，在公司我只是一个普通的员工，一个普通的咨询师，一个普通的敏捷过程教练，一个普通的开发者。不要以为带了 ThoughtWorks 咨询师的头衔，获得的只有风光和利益如果你非要说风光和利益。那就告诉你，我以作为一个ThoughtWorker而自豪；我以同很多优秀的人一起共事而自豪；我以交付高质量的项目和产品而自豪；我以有机会能把国外先进的技术和开发方法带到中国而自豪。我得到的利益，就是每天可以开心的工作，做自己喜欢的事情，并把我所学传授给别人！
　　眼前所见的喧哗难道就是百家争鸣！？
　　2008年5月9日 上午1时20分 发表人 li dapeng
　　回复中最多出现的竟然是：教主、熊节、TW。
　　不知道大家是喜欢敏捷还是PK的感觉！？
　　Re: 眼前所见的喧哗难道就是百家争鸣！？
　　2008年5月9日 上午2时33分 发表人 rick chen
　　有张恂的地方就会有争吵，而且这么多年了一直让人觉得厌烦，你累不累啊。
　　Re: 争吵不是张恂的本意
　　2008年5月9日 上午3时40分 发表人 Charlie Zhang
　　首先真理不辩不明，我的本意并非和谁争吵。
　　可能很多 80 后、90 后不知道，我们国内的（民用）软件工程与美欧相比，在许多地方其实还相当落后，主要是因为讲科学、有科学信仰的科学家、工程师出来讲话的人太少，而市面上混混、逢迎拍马、投机取巧之类的业余草莽太多，这是大的背景。
　　所以，只要媒体上、舆论圈里还活跃着这些伪专家、错误的观点和言论，只要在张恂的本职工作力所能及范围之内，我会坚持批评下去（当然，也欢迎大家对我的批评），不管花多少年，我把这个当成终生的事业，因为我有科学的信仰，所以不会累的。
　　张恂
　　支持！晒晒熊节的人身攻击，供大家参考
　　2008年5月9日 上午3时50分 发表人 Charlie Zhang
　　2008年5月8日 上午7时36分 发表人 凉粉 小刀
　　让我们在争论技术问题的时候，少一些人身攻击吧……支持！晒晒熊节（Jeff Xiong）的人身攻击，供大家参考，引以为戒。档次最高的裤腿追咬者
　　http://gigix.blogdriver.com/gigix/199515.html
　　所谓“裤腿追咬者”，是指“不以实用或审美为目的，专为驳倒某个特定对手的辩论者”。拥有裤腿追咬者是件值得骄傲的事情，因为裤腿追咬者的逻辑总是“扳倒了xxx就证明我很NB”，既然如此，这个“被扳倒”的对象无疑已经在裤腿追咬者眼中具有崇高地位了。曾经有一次和Jacques聊起，就像胶片和照片的关系一样，裤腿追咬者和搞偶像崇拜的fans其实是同一回事。所以，拥有一位迄今为止档次最高的裤腿追咬者，我的虚荣心得到了极大的满足。
　　http://www.iturls.com/~xzhang/reviews/scrafts.htm
　　虚荣心满足一下就好。还是Kent Beck那句话：“我要去写程序了。”前一阵没啥好玩的，随手写了点文字；最近又找到了好玩的东东，让这位裤腿追咬者自己玩去吧，不陪他了。
　　作者： gigix 2004年06月14日, 星期一 15:30
　　Re: 支持！晒晒熊节的人身攻击，供大家参考
　　2008年5月9日 上午4时32分 发表人 li dapeng
　　真心祝愿两位可以早日握手言和，一起来推动我国软件工程发展！
　　Re: 支持！晒晒熊节的人身攻击，供大家参考
　　2008年5月9日 上午4时40分 发表人 凉粉 小刀
　　大家的过往恩怨，希望可以不要在InfoQ上中文站继续。无论从前的事情在何时何地发生，大家都可以到事件发生的地点继续做想做的事情，没有必要满地开花。
　　最近一段时间在敏捷社区上发生的讨论，已经远远超出了技术话题争论的范畴。正如前面一位读者所说，难道这样的喧嚣就是百家争鸣么？
　　希望每个人都可以保持一点冷静，这是对读者的尊重，也是对自己的尊重！多谢！
　　Re: 支持！晒晒熊节的人身攻击，供大家参考
　　2008年5月12日 上午4时33分 发表人 Charlie Zhang
　　2008年5月9日 上午4时32分 发表人 li dapeng
　　真心祝愿两位可以早日握手言和，一起来推动我国软件工程发展！Dapeng，谢谢你的理解和好意！
　　不过在 Jeff Xiong 正式地向我公开书面道歉之前，我想，谈和解还为时过早。
　　Re: 支持！晒晒熊节的人身攻击，供大家参考
　　2008年5月14日 上午1时38分 发表人 li dapeng
　　世界上最宽阔的是海洋，比海洋更宽阔的是天空，比天空更宽阔的是人的胸怀。
　　不责人小过，不发人阴私，不念人旧恶。三者可养德，亦可以远害。
　　以上两句与君共勉！！！
　　Re: 眼前所见的喧哗难道就是百家争鸣！？
　　2008年5月15日 上午4时35分 发表人 sheng wang
　　有张恂的地方就会有争吵，而且这么多年了一直让人觉得厌烦，你累不累啊。不同意你这样不分青红皂白的说法，作为一个程序员，逻辑和客观是很重要的两个思考特性。有争吵不假，但要看争吵是怎么来的。就学术角度来说，我同意张洵的观点。只是我建议张洵表达自己的观点时应该注意方式方法，注意自己的口气，毕竟文人都是自尊心很强的，激烈的言辞容易导致反感和对立。

本文转自
http://www.infoq.com/cn/articles/scrum_investigation_case_study