清玄的敏捷（Allen0805）

楼主的文笔不错！个别的观点我也赞同。

但整篇文章显然过于艺术化、简单化和理想化了，和实际的软件工程差距很大。现实中的软件开发要复杂、困难得多。

清玄的敏捷没什么用。

敏捷软件工程是非常务实和实用的，在国外已经有 15 年以上的发展历史。敏捷必须要能解决实际问题才有用。

副总经理是所有项目的发起人吗？




虚拟的项目经理。

不知业务部门的部长一般同时担任几个项目的 PM？







我的几个问题：

好像你们是一家甲方企业，能否告知所在行业？

你们公司是否有统领信息化建设全局的 CIO？

你们公司是否有一个独立的业务（流程）规划部门？

公司内外（业务部门、乙方、IT 人员等）对你们目前的项目管理现状有何意见和评价？

你们的项目是否都外包给乙方，是否有内部的软件开发部门？

itpub: ScrumWorks 让 Scrum 更敏捷

by 王立杰

一篇不错的介绍和分析 Scrum 工具的文章。

网友 ncut_honghan 有几个疑问：




这些观点和问题非常好，其中有些是正确的，有些是常见的误解。我逐一分析如下：

1）世上没有万能的东西，只有适合和不适合，我不相信只要采用敏捷开发的项目就一定能成功。

对。

世上没有万灵丹/万灵药，这是条公理。

软件开发具有不确定性。现有的敏捷方法不可能适合天下所有的项目，也不是天下所有的项目只要采用现有的敏捷方法都能成功。


2）敏捷开发非常强调个人的能力，有能力就肯定有个性，那么人与人之间的磨合沟通就很重要，一方面这要求实施敏捷开发的团队一定要有默契，知根知底，惺惺相惜，我相信这是先决条件，然而要组建这样的团队并不容易；另一方面，有能力的人毕竟不多，LZ在工作中一定遇到过偏执于技术，不懂沟通，或者只会夸夸奇谈，却什么都不会做的项目成员。

对。

敏捷注重提升个人的能力，同时也强调建设优秀的团队，尤其人与人之间的磨合与沟通。正是因为不容易，所以只有真正优秀的团队才能做到敏捷，这正是大家努力的方向和目标。

敏捷在团队建设、沟通等方面有很多好的、值得大家学习的实践做法。

正是因为有能力的人不多，所以我们要提倡建设敏捷团队，促进沟通，提升大家的能力。

你所说的这类成员，我也的确遇到过。这类成员是不受敏捷团队欢迎的，如果他不能改变或者不愿接受改变，接纳优秀的团队文化，那么就会被敏捷团队所淘汰或抛弃。


3）敏捷开发强调持续提供给客户交付品，然而我们国内的客户往往都不成熟，需求变更非常频繁，那么如果产品架构扩展性不够的话，对项目会造成非常大的影响。

敏捷方法的一个特点或特长就是能够有效地针对需求变更频繁的项目，而且非常强调产品架构设计的扩展性、灵活性。很多敏捷专家本身就是产品架构设计方面的专家。

敏捷项目需要客户的积极参与和配合。客户不成熟，确实是一个难点，需要开发商和团队去积极地引导客户。

与传统方法相比，敏捷方法可以显著地降低项目风险。


4）项目经理在敏捷开发过程中对项目的不可控性，或者无法预见结果，对项目要有准确的预测，那么反馈和收集的数据一定要准确，如果敏捷开发都通过代码来反映，总感觉不踏实。

错。

与传统方法相比，敏捷项目经理对项目具有更好的可控性，更好的预见，更准确的预测，以及更准确的反馈和收集数据。

敏捷开发的效果并不是仅仅通过“源代码”来反映的，关键是看实际可运行的代码通过了多少测试，是否满足了用户的实际需求，同时还可以有一系列的反馈和进度指标，传统有的敏捷也可以有。这种反馈效果要远比传统方法踏实得多。


* LZ口中的瀑布开发我认为是对项目流程管理的一种统称，我认为如果好的流程，可以解决或辅助上面提到的问题，当然敏捷开发肯定有自己的优越性，但是要根据项目来决定。

错。

waterfall 是一个专有名词，有特指。40 年的软件工程实践证明，瀑布流程是一种很差的流程，取而代之的是 IID。无论敏捷过程，还是 CMMI 过程，当今成熟的过程模型大都采用 IID。

根据实际项目的特点来决定是否采用敏捷过程，这是对的。


* 我对敏捷开发认识还不够，希望跟LZ能有更多的交流。但是对那种明明是无序无章程的开发，却美名其曰为敏捷开发是不能容忍的。

对。

敏捷过程是有序和有章可循的，和传统过程一样，在许多方面也有严格的纪律要求。和传统的区别在于，传统过程往往是 heavyweight，而敏捷通常是 lightweight。

InfoQ 新闻：你的敏捷组织应该关心什么？

对！Mike 说出了敏捷的核心

Scrum、XP 的 practices 只是表象，如果不顾实际条件，盲目地照搬就成了教条。真正重要的是这些做法背后的 why，为什么 Scrum、XP ... 等等敏捷方法要这么做，有哪些前提条件。只有理解了 why（敏捷软件工程的基本原理），才能灵活地运用。

从守，到破，再到离，这是人们认识敏捷的一个必然过程。Mike 大概已经到了破和离的阶段。





Carl，能否分享一下你们的那次“惨痛敏捷经历”？我想可能很多人会和我一样对此感兴趣。

你说的这几点都很重要，包括本地化，实践的含义，关键在人，词汇（概念）手册等等。我很赞同。

道理往往很简单而浅显，一点就破，但要让更多的人明白这些简单的道理却往往是不简单的。

这是一个 FAQ。

关于敏捷开发方法（cnyining）



大体上整理的不错，5 和 6 有点问题。

敏捷方法和传统方法比较，还有其它一些显著的差别，比方计划性与适应性、计划驱动与风险/价值/反馈驱动等。



不对。

敏捷方法的类型和内容是很丰富的，既有着眼于项目管理的，比如 Scrum、Agile Project Managment 等，也有着眼于具体的“实施过程”的，比如 XP、AgileUP、FDD、Crystal 等等。

RUP 是一个比较全面的过程框架，其中既有项目管理的内容，也有具体的“实施过程”。

所以以上这句话，并没有道出 RUP 与敏捷方法、敏捷过程的真正不同之处，理解是错误的。

InfoQ 新闻（中文）：

Software Craftsmanship Manifesto: A Call to Arms

Craftsmanship 不是工艺，应该译成匠艺、技艺或技能
2009年3月12日 下午10时39分 发表人 Charlie Zhang（张恂）

Craftsman + ship 强调的是工匠个人精湛的技艺和能力，应该译成匠艺、技艺或技能。把 Craftsmanship 译成工艺，对初级程序员、业余程序员会形成误导。

所以 Software Craftsmanship Manifesto 是《软件匠艺宣言》，或者《软件技艺宣言》。

不懂“工艺”在软件工程里是啥意思，估计是外行吧。几年前，熊节（Jeff Xiong）翻译的 Pete McBreen 的《软件工艺》这本书，已经被张恂批评过。

听说敏捷首席李剑是北航的软件工程硕士，我想应该懂什么是工程，什么是工艺。偏要这么翻，我估计因为是熊节的坚定饭丝。当然，这是他的自由，而我们也有批评的自由。

立山头、树大旗，这很正常
2009年3月12日 下午10时20分 发表人 Charlie Zhang（张恂）

如果仔细研究，可以发现在 XP 大师里面，Uncle Bob 和 Martin Fowler 的观点与 Kent Beck、Ron Jeffries 的相比是有些微差别的，相对比较全面，走的是温和的中间路线，我比较认同。

由于所持观点、价值观的差异，软件大师流派、阵营的分分合合、此消彼长是常态。于是前段时间，我们看到了继 Agile Alliance 之后又出现了更火爆的 Scrum Alliance。

现在有人敢于质疑《敏捷宣言》，提出它还不够好，于是提出用《软件匠艺宣言》来弥补、改进，我觉得是件好事。

Enigneership over Craftsmanship

恢复手工业时代的称谓，软件工匠，真的比软件工程师更潮吗？我举两个反例。

如果要论真正的软件工匠，咱中国恐怕没有几个。我想首屈一指的，当代应属王选老师。毕升是名工匠，王选老师和他率领的团队用光和电取代了铅与火，其成就和影响可以说超过了毕升，称王选老师为水平最高的软件工匠肯定是没问题的。然而，王选老师仅仅是一个匠么？是不是有点低估了？其实，王选老师最合适的身份就是科学家（兼工程师），一位伟大的、实干的科学家。

还有，我们很自豪，世界首富是一名程序员，他退居二线后的头衔是 Chief Engineer。此外，我们熟悉的 n 多位软件工程大师、敏捷大师的头衔也都是 Chief Scientist。

事实上在西方很多国家，受到崇尚科学文化的影响，人们都很尊重各行各业的科学家和工程师，有的科学家、工程师的身份甚至还是由皇家授予、奖励的，地位尊贵。

这些说明了什么？说明 Scientist、Engineer 的地位显然比旧时代的工匠高（至少不低于），受到了人们的普遍尊重。从历史的、发展的角度看，工程师一定有超过工匠的地方。软件工程师、科学家的个人能力难道一定就比工匠差，代码写得不如工匠好？不对吧。

所以我觉得，既然历史上没发生过，现在也没必要倒退回去，提倡工匠的文化，“软件工匠”不过是一个有点不合时宜的比喻而已。咱中国还是多提倡软件科学、软件工程，高水平的软件工程师的文化更好。

无论是《敏捷宣言》、《软件匠艺宣言》，好像都缺少几个关键词：

科学、辩证、系统、智慧 ...

等。这些我会在太极敏捷（宣言）中作补充。所以，我肯定不会加入什么《软件工匠宣言》，《软件工程师宣言》倒是可以考虑。Engineership 比 Craftsmanship 更好！

InfoQ 新闻（中文）：

Adopting The Whole Enchilada

企图面面俱到，无所不包，这种想法本身就是不敏捷的，也是不现实的。

我想 Scrum 之所以流行，可能和它的创始人从一开始，就只专注于、聚焦在找到一个最小的迭代式项目管理框架，注重敏捷的计划、跟踪和管理，而没有把它强行绑定在某一种具体的工程技术和做法之上有关，这大概是 Scrum 非常聪明的地方。既然没有明确限定和约束，那么就代表着开放，可以适用于不同类型、不同环境下的项目。

当然，任何事物都是有利有弊。Scrum 的这种开放性，也带来了实施上的一点难度，你需要 bind 具体的工程技术和做法，Scrum + XP，Scrum + UP 等等都是可选项。这时如果实施者对敏捷的本质理解和掌握程度不够，结果就可能事与愿违。

这也是为什么 Scrum 会招致非议的地方。你看 Scrum 这么流行，好像抢了 XP 的风头，有些 XP 的强烈支持者就不干了。对于 Scrum 和 XP 阵营之间的竞争也好，融合也好，张恂相信的还是好猫理论，没必要人为地分出一个绝对的高低。最终会如何演变，还是看事实和数据，让实践来检验吧。

大象的敏捷，与猴子的敏捷，必然是有所区别的，这是两种不同级别（重量级）的敏捷。我们不可能要求大象也像猴子一样能上树（来一段踢踏舞是有可能的）。所以，我们也不可能要求所有的敏捷项目都 XP，颁布诏令说不用 TDD、PP、CI 就不能叫敏捷。这显然是错误的。

敏捷不是某一个具体的做法，是不是敏捷，也不能用是否采用了某种具体的做法来判断，这是敏捷 FAQ 和常识。诸如持续集成、测试驱动开发、结对编程等等，其实都有相对应的替代做法，比方张恂提出的每日集成、UDD、PPoD 等，这方面国外的大师和专家也有不少创造。

当然，如果一个项目真的非常适合采用 XP，全部 XP 做法都能上，那自然很好，我们也没必要犹豫，坚决地用呗。

同时，我觉得也应该允许大家讨论，除 XP 做法之外的，其他可能更有效、更富有创意的敏捷实践。

敏捷实施的成功，关键在于是否真正理解了敏捷软件工程的基本价值观、原则和基本原理（为什么要这么做，不那么做...）。掌握了这些基本原理，就能够有选择、有头脑地采用某些具体的敏捷做法，甚至根据实际情况，创造出自己的敏捷实践方法（进入自主创新的阶段）。从守，到破，再到离，这是一种更高境界的切换，也是敏捷改进的必然之路。

不知道我的太极敏捷辩证思维，有没有把以上这个略显复杂的敏捷改进的方向和关系问题讲明白。

太极敏捷（CMT 推论）：

只有拥有先进文化的团队、企业和组织才能真正做到敏捷，实现敏捷变革的收益。

InfoQ 新闻：

12月27日QClub深圳活动要点速报

2008 年 12 月 27 日华为公司软件工程部经理周代兵和腾讯公司 R&D 研发总监王速瑜在 QClub 深圳活动中分别介绍了两家公司的敏捷改进和实施情况。

当华为和腾讯，我国通信和互联网行业的翘楚、领导企业已经在探讨、尝试着进行敏捷变革，这意味着什么？显然，有很多值得我们深入研读的东西。首先，我觉得这是一个拐点信号，两家公司的敏捷改进具有风向标的作用。

两位介绍的内容都有很高的价值。下面先谈谈我对华为敏捷的观感。

（以下引用内容基于编辑的记录，未必是原话）

华为的敏捷

周形容华为的敏捷：“一夜的引入，长时间的改变”

周代兵的介绍令人印象深刻，可以说非常好。我赞成其中的绝大部分内容和观点，很多地方与我所倡导的基于辩证法和矛盾论的中式太极敏捷观点是一致的。不是说周代兵或张恂或任何其他人的观点就一定正确，而是说辩证法、矛盾论本身就是科学的。

我想周的介绍，大部分内容应该不只是他个人的想法，很大程度上也代表了华为软件工程部或华为的敏捷推行者们经过深思熟虑之后得出的想法。下面我从太极敏捷的角度谈谈为什么赞同或支持他们的想法。

敏捷改进尝试的效果如何？



他提到了华为的 IPD+CMM/CMMI、RUP、Scrum、XP 以及敏捷方法、精益思维在各个发展阶段的作用。

传统的价值



传统的缺陷



他对于华为传统和现状的理解、敏捷的理解以及敏捷与传统关系的理解是非常准确、到位和务实的，同时我还看到了华为的敏捷推行者一种非常 open、flexible 的成熟思维、心态和智慧，可谓 pragmatic and practical。

“软件开发不同于生产线上的重复劳动，是创造性的工作。”

“他们利用精益思维去发现需要改进的地方，有选择地采纳一些XP实践，并以Scrum去补足XP在管理上的弱点。”

华为敏捷的一些具体做法：



充分发挥了研发人员和团队的主动性。

敏捷与传统的关系

“在转变的过程中，他们并非全盘放弃传统做法，而是将IPD移到上层用在决定投资决策方面。然后用敏捷团队逐渐代替CMM团队。”

敏捷与企业文化的关系

对大中型企业敏捷实施和转变的困难性和复杂性也有充分的认识。最重要的是，对企业文化、团队文化影响的重视。



认识到敏捷转变最终将涉及到组织变革和文化变革，利益的调整，并主动为此作好应对准备，这样的改进失败的可能性很小。

有创意的做法



关于敏捷是一把手工程



太极敏捷认为：最有效率的敏捷改进是自上而下的推行，同时把自上而下、自下而上结合起来。

这里“不打旗号”也可以反映出推行者的智慧。

关于度量，我所赞成的敏捷度量、measurement on demand：



太极敏捷：

敏捷变革、实施和改进最大的难点在于思维的转变，尤其是各级管理者思维（mindset）的转变。

良好的开端是成功的一半。我预计华为将来会有很高的敏捷成熟度，而且一定会出现“华为式的敏捷”or Huawei Way。

InfoQ（中文）：

Brian Marick: What's missing from the Agile Manifesto

Brian 提出了 4 个新的价值观：

技能

纪律

轻松

快乐