昨天的评审会上，作为被评审者，与几个大佬在观点上发生了激烈的交锋。
由于敏捷开发内容看起来大多属于管理过程的，这几位大佬都认为自己比较清楚，不再像前面的一些如知识图谱、大数据等内容，发言那么谦虚谨慎。
会后情绪还久久不能平复，觉得如果再多给我些时间，一定要把他们按在地上摩擦。经过一晚上的冷却，意识到自己是被情绪控制了，并没有从问题本身出发。如果当时更冷静、平和一些，对一些问题展开真诚的探讨而不是陷入想驳倒对方的思维里去，应该能取得略好一些的效果。要做到这样，对我来说确实不易——正说明我的修行还不够，因为他们中的一两位透露着一种傲慢和偏见，平时就时刻在体现着自己的了不起。当然，他们有自己厉害的地方，但并不是每个领域都了不起。尤其是一些人经常会说，别看我现在不写软件，以前我也是写过代码的，云云。他们可能30年前写过几行代码的，还在说着foxpro的故事，用那个时候的程序开发模式和思维来想象现在应该有的样子。
但我忘记了高效能沟通的原则，只想着反驳他们。现在将认识上的一些不同冷静的探讨一下。
敏捷就是“快”：
这个认识有部分是对的，因为通过迭代的手段，让可工作的软件得以尽早的与用户见面，最直观的感受是快了。但不是“就是快”。因为根据提问者后面的问题里，知道他认为敏捷不保证质量。恰恰，敏捷是一直在强调质量的。只是保证质量的手段比他们所认知的一定要通过独立的测试这种手段要丰富多了。敏捷的质量是“内建”的。“快”的获得，是通过团队持续的过程能力提升、技术能力提升来做到的。当一个团队不停的自我进化，最后必然会快了。其实这个道理很简单，就是找到一只价值股票，长期持有，利用复利的威力获得巨大回报。团队的持续进化就会有复利。
敏捷在我们这里不适合：
这个论断也有部分是对的。一方面，放在组织级敏捷、业务级敏捷这个层次来看，确实，外部一些大的环境导致我们难以独自做出改变；另一方面，如果一个组织的第一推动力认为某种方法在这里不合适，那这个方法就一定是不合适的，不管方法对路不，因为首先就没法推进下去；再就是，组织中的绝大多数已功成名就的人有自己习惯的思维模式和工作模式，一定会抗拒改变的，敏捷所倡导的价值观与这些既有的模式严重冲突。 不过，从执行层面、团队层面、技术层面来观察，敏捷的那么多具体实践中，总能找到一些可以推进、起到效果的东西做起来。这个具体在后面来谈。
GJB5000A是国家标准，为什么我们不执行：（国家标准一定是好的，既然都是国家层面的标准了，执行起来一定就好了）
XX所，他们执行了这个标准，软件开发就不能随意搞。
关于这个问题，我曾经也是这样以为的，所以对搞CMMI曾经抱了很大热情。对GJB5000A目前没有详细的了解，但据说这个标准基本上就是CMMI 1.x的一个翻版。因此，以我对CMMI1.x的了解，谈下不成熟的看法。CMMI在国内搞了20来年，起到的效果确实不怎么样，以致于有人公开的宣称国内搞CMMI的都是骗子。这个话题姑且不谈，单从我们自身做CMMI 3级的经历来看，如果现在我们老老实实的把需求梳理好，版本规划好，老老实实跑迭代，认真的开需求梳理会，迭代计划会，每日站会，迭代评审会，迭代回顾会，满足CMMI 3级里关于软件开发的5个过程域的要求应该是没什么问题的。至于其他的16个核心过程域， 是需要整个组织付出巨大的投资才能做到的事情，这也正是CMMI一直以来“两张皮”的原因：付出巨大的投资，见效慢，在做赚快钱和修炼内功的选择上，赚快钱的诱惑巨大。
对于GJB5000A的运行情况，我也听到了来自做GJB5000A咨询和认证人员的声音。据说某典型的单位，过了2级，过了3级，要过4级。过的时候是一个样子，过两年再回去看，原来该怎么干还是怎么干。这也就和我们过CMMI 3级没啥大的区别。
开发软件的有两种企业，一种是抖音这样的，开发一个功能就发布出来，让大家用，提意见，快速修改（快速发布，边用边改），一种是微软做windows那样的（好长时间做一个庞然大物出来，质量很稳定，瀑布模式）：
抖音的这种模式确实是2C的一种“范式”了，但这里面值得注意的是恰恰是他们并没有牺牲需求分析，牺牲质量，而要能做到这样正是他们的需求分析能力和质量控制能力已经达到了很高水平。他们的任何一个功能的发布都是有十分明确的用户定位的，只不过他们对这个快速变化的世界更敏感，面临的市场竞争更充分，所以不得不快速的响应。
而微软，百度一下，《微软欲变身敏捷开发典范》是2008年的文章。可知微软早已经不是那个印象中的微软了。早在2002年，微软的一批华人专家出过一本书，叫《软件开发的科学与艺术》，其中很多内容，“主人翁精神和团队精神”、“从错误中学习”、“基于用户情景的设计”，都是现在的敏捷开发里所强调的。
其实在一些具体的技术实践方面，敏捷模式和瀑布模式并不是对立关系。持续集成、自动化测试、结对编程、每日站会等等，大家都可以用的。
敏捷里由开发人员自己做测试不靠谱：
这个想法可以理解。
但敏捷里对测试的要求是贯穿全过程的，当然我们在实践中很多还做不到。而敏捷里也并没有说所有的测试工作都由开发人员自己做。只是强调，质量是整个团队负责，而不是依赖于测试人员把关。
要求测试人员在需求梳理阶段便介入，与项目负责人、开发人员三方就每个具体功能的验收标准要达成一致理解。要求开发人员按照验收标准展开自测。测试人员可以将更多的精力放在如何提高自动化测试水平，编写一些辅助测试工具，开展一些探索性的测试等方面，测试人员的成绩不是体现在那个记录了长长的包含了各种功能不符合预期的bug列表上。
在外面互联网公司传递出来的趋势来看，团队里确实不再需要那么多专职的测试人员了。
最后，再谈下哪些敏捷实践可以在我们这个环境做起来的问题。
我尝试从要解决的问题出发，来探讨下。
有关产品规划的问题。
在前面其他项目的审查过程中，有专家就提到了几个担心，“起个大早，赶个晚集”，“要一个功能模块一个功能模块的上，不要都做完了再上”，还有项目负责人提到要“开发一代，预研一代”。其实这些说法、担心，在敏捷方法里都有答案。
产品的发布时机是根据市场来规划的。因此就一定要对产品进行需求优先级识别，划分出MVP版本，为了配合市场做出若干的版本规划，而且要根据市场的反应动态的进行版本规划的调整。而我们现在的产品研发方式，年初定个策划，年底来审查结果，是明显的不符合市场的节奏了。在去年曾经在某些场合向主管部门提过，但没什么效果。不知道今年这个问题能否有所改变。
有关项目质量的问题。
专家提到，有些项目在用户现场现改（质量不好）。这个现象背后的原因可能是多方面的，需求分析环节是如何做的，做到什么程度了？需求和开发之间的衔接怎么样？开发本身的质量怎么样？
关于需求分析是可以通过一些具体的技术手段、方法，第一是提高分析人员的能力，第二是建立需求与用户之间“有效”的沟通与确认机制，这都是敏捷方法里致力于解决的问题，例如用户故事，原型，其他一些可视化需求分析方法等。
关于需求与开发的衔接，也是敏捷里致力于解决的问题，如：需求梳理会，验收标准，每日站会，迭代评审会，等等实践。
关于开发人员本身的质量问题，验收标准的多方确认，测试驱动开发，持续集成与测试，规范的代码版本管理，等等。
写完了，给负责这个专业的大佬看，给出的反馈也放这：
非常认同文中提出的思考意见，我的观点和你的是一致的。你已经是所内敏捷实践的顶级专家了，谈不上指导，交流一些意见和信息：
1.我在德国培训了一天的敏捷实践课程，期间问了一下老师是否可以将敏捷方法理解为一系列协同的小瀑布方法，老师说不行，因为瀑布方法不能回溯闭环到需求原点进行需求改进，继续问是否可以理解为一系列协同的受约束和改进的小瀑布方法,老师说可以,但那已经就不是瀑布方法了
2.关于敏捷方法和ISO、CMMI、GJB的关系，当然有很多维度，但我觉得主要的区别是ISO和GJB的关注点是审核过程要素的符合性，CMMI感觉是在符合性基础上还从解决软件危机的角度给出了具体过程方法的指导，但他们都没考虑随着市场竞争的加剧从需求到交付的进度质量成本要求越来越高的要求和对人的人性化关注，从方法指导上已经不够了，敏捷就诞生了，他们之间不冲突，符合CMMI和GJB同时可以做敏捷方法，敏捷把CMMI和GJB的两张皮问题解决给出了系统性的实操方法。
3.任何一个方法论体系都是庞大的，敏捷方法包括设计思维、SCRUM、商业模式和精益创业四大部分，每一部分又有很多内容。 敏捷方法的运用从所领导层肯定更关注系统性的全局应用，而不是在SCRUM框架中的一部分应用，你的敏捷工作室后面大有可为。
4.昨天坐对面的都没实操过，真真假假培训研究了解过一些信息，虽然提出了意见，重要的是先听取，不用急于辩解，事后可以消化吸收总能找到用于改进敏捷实践的点，包括表达、方法、衔接等各方面，如果实在没有就一笑置之了
5.敏捷方法总体上我觉得就像打造汽车的流水线一样打造软件生产的流水线，随着实际的深入在精细化、标准化、工业化方面的积累，综合运用人工智能大数据技术，必然在某些业务领域某些流程阶段实现软件的智能化生产，就像目前很多智能工厂一样
受益匪浅。比我的思考系统很多。
1.我一直觉得不应该到处提“敏捷”这个词，因为这个自然而然的会受到有成见的人的反对，但很多具体的实践，假设前面不冠以一个敏捷的名头的话，他们反倒可能容易接受。只是一直找不到这么一个合适的表达。
2.领导们关注系统性的解决方案是能够理解的，但这个恰恰又是特别难以找到合适的解决方案的，可以参考华为的，得需要付出巨大的代价和特别强的执行力。其制约瓶颈可能在执行力上。所以我就想先做力所能及的小事。
3.cmmi 1.3中已经在拥抱敏捷了，在新的cmmi 2.0中应该融入得更充分，但没看到过具体的材料，所以不知道。
4.一直以来也有个担心，如果系统层面没有改变，团队级其实是很脆弱的，绩效考核、随便一个行政领导的几句话，等等，都可以把一个实践团队坚持下去的动力在短时间内摧毁掉。