敏捷开发般若敏捷系列之1-13
敏捷开发
敏捷建模者应当脚踏实地他们的精力都集中在满足用户的需求上，他们不会在模型上画蛇添足，即便那双足 是多么的好看。他们满足于提供可能的方案中最简单的一种，当然，前提是要能够完成工作。
敏捷建模者乐衷于研究问题，解决问题。 凡事都问个为什么 敏捷建模者看问题从不会至于表面，而是会打破沙锅问到底。他们从不会就想当然的认为一个产品或一项技 术和它们的广告上说的那样，他们会自己试一试。
敏捷开发
计算机名词
01 原则
03 工具 05 名词详解
目录
02 成功 04 实践 06 建模者的个性
07 建模误区
09 遵循原则 011 分布式
目录
08 开发宣言 010 团队原则 012 的原则
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在 构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之， 就是把一个大项目分为多个相互，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
敏捷开发◆逐渐应用模式高效的建模者会学习通用的架构模式、设计模式和分析模式，并适当的把它们应用 在模型之中。然而，就像Martin Fowler在Is Design Dead中指出的那样，开发人员应当轻松的使用模式，逐渐 的应用模式。这反映了简单的价值观。换言之，如果你猜测一个模式可能适用，你应当以这样的方式建模：先实 现目前你需要的最小的范围，但你要为日后的重构留下伏笔。这样，你就以一种可能的最简单的方式实现了一个 羽翼丰满的模式了。就是说，不要超出你的模型。举一个例子，在你的设计中，你发现有个地方适合使用GoF的 Strategy模式，但这时候你只有两个算法要实现。
敏捷开发方法教程
敏捷开发方法教程敏捷开发（Agile Development）是一种以人为核心、快速迭代、灵活应变的软件开发方法。
它强调团队协作、持续交付和快速反馈，可帮助开发团队更好地应对需求的变化，提高项目的成功率。
本教程将介绍敏捷开发的基本原则、常用方法和最佳实践，帮助读者全面了解敏捷开发的精髓。
一、敏捷开发简介敏捷开发起源于1990年代的极限编程（Extreme Programming）方法，在过去几十年中不断演化和发展。
与传统的瀑布模型相比，敏捷开发注重快速迭代和用户参与，能够更好地应对需求变化和项目风险。
二、敏捷开发原则敏捷开发遵循以下核心原则：1. 个体和互动高于流程和工具：注重团队协作和沟通，激发创造力和创新。
2. 可以工作的软件高于详尽的文档：通过快速迭代交付价值，提供及时的产品演示和用户反馈。
3. 客户合作高于合同谈判：与客户积极合作，灵活应对需求变化和优先级调整。
4. 响应变化高于遵循计划：在需求变化时调整方向，保持高度灵活性和可调整性。
三、敏捷开发方法敏捷开发有多种方法和框架，下面介绍几种常用的方法：1. 极限编程（Extreme Programming，简称XP）：强调团队合作、持续集成和测试驱动开发（TDD）等实践，推崇简单和高质量的设计。
2. Scrum：通过定义角色、仪式和工件等，实现实时掌控项目进度和风险。
将项目拆分为若干个迭代周期（Sprint），每个迭代周期都可以交付部分功能。
3. 敏捷建模（Agile Modeling）：强调可视化和简化的建模技术，帮助团队更好地理解问题和需求。
4. 结对编程（Pair Programming）：两位开发者合作完成一个编码任务，提高代码质量和团队协作效率。
四、敏捷开发实践实践是敏捷开发成功的关键，以下是几个重要的实践建议：1. 迭代开发：将开发工作划分为若干个迭代周期，每个迭代都能交付可工作的软件。
每次迭代结束后，团队根据反馈进行优化和调整。
给设计师看的“敏捷开发”入门方法论
给设计师看的“敏捷开发”入门方法论Agile （敏捷）对于没有参与过软件开发的设计师们来说是个有点诡异的专有名词。
雇主和招聘者们频频用到这个词，那么Agile到底是什么？以我作为业内人士的视角，以下是我觉得设计师们在此领域应该了解的知识。
这并不是一份关于“敏捷开发”（agile）或称“并行开发”（scrum)的完全指南，但如果你正打算去一家以产品或者软件开发为主的公司应聘，这篇文章或许可以给你提个醒。
我会聊聊它是什么，它是如何运作的，包括其它一些术语，比如“产品需求待办列表”（product backlog)、一次迭代待办列表“（sprint backlog）、每日例会，以及潜在的可输出产品增额的概念(potential shippable product increments)。
What-我们到底在聊什么？“Agile 起源于2022年，当时一小群软件开发者认为他们需要一种新的工作流程。
他们构想出12条准则，并总结成一份宣言。
它描述了一种流程，一套方法论。
以下图表展示了一个典型的敏捷开发流程，包含了一系列小的迭代周期。
在“敏捷开发”的定义范畴中有一些更精确的分支，其中一种（也许是最受欢迎的一种）就是“scrum (译者注：本义为英式橄榄球中的并列争球行为）。
想要了解更多关于Scrum的详情，可以访问.不论哪种，“敏捷开发”必然包含了迭代的、不断增进的周期型工作。
理解它的最好方法就是先看看与之反向对应的瀑布流式（Waterfall)协作方法。
“瀑布流”是产品开发领域里一种相对传统的协作模式。
它是按照次序逐一执行的，无疑也相对僵化和低效一些。
敏捷开发有许多优点（相较于瀑布流式开发方式），比如它的最终成品可以更早地投向市场，更适于团队协作，需要不断增加投资。
从另一方面来说，它灵活的特点也让利益相关者们更加紧张。
这也是常被误解的一点。
How-“敏捷开发”是怎么运作的？Let’s see how an agile workflow looks in a practical design situation. 让我们来看看在实际的设计工作中敏捷开发工作流是什么样子的。
敏捷开发十二原则 项目管理方案 pmp
敏捷开发十二原则项目管理方案pmp摘要：1.敏捷开发十二原则简介2.项目管理方案概述3.PMP 认证与敏捷开发4.结合敏捷开发十二原则的项目管理方案正文：1.敏捷开发十二原则简介敏捷开发是一种软件开发的迭代和增量方法，其目的是解决传统软件开发过程中需求变更难以应对的问题。
敏捷开发十二原则是敏捷软件开发方法论的核心，它包括：1）满足客户需求；2）敏捷适应变化；3）团队协作；4）有效沟通；5）持续集成；6）持续交付；7）团队自我调整；8）可预测进度；9）高质量软件；10）简单设计；11）测试驱动开发；12）持续改进。
2.项目管理方案概述项目管理方案是为了实现项目目标，对项目的资源、时间、成本、质量、风险等方面进行全面规划和控制的过程。
项目管理方案主要包括：项目目标与范围、项目组织结构、项目资源计划、项目进度计划、项目成本计划、项目质量计划、项目风险管理计划等。
3.PMP 认证与敏捷开发PMP（Project Management Professional）认证是项目管理专业领域的一种国际认证，它证明了持证者在项目管理方面的专业能力和经验。
虽然PMP 认证主要针对传统的项目管理方法，但其中的很多原则和方法在敏捷开发中仍然具有很高的参考价值。
例如，PMP 中的项目管理知识体系、项目管理过程组、输入输出工具等，都可以与敏捷开发相结合，为项目管理提供有力支持。
4.结合敏捷开发十二原则的项目管理方案在实际项目管理中，可以将敏捷开发十二原则与PMP 认证相结合，形成一种适应需求变更、提高项目效率的方法。
具体操作可以从以下几个方面入手：（1）在项目启动阶段，明确项目目标和范围，并将其分解为可操作的任务。
（2）在项目执行阶段，采用敏捷开发方法，进行迭代开发，快速响应需求变更。
（3）在项目监控和控制阶段，利用PMP 认证中的项目管理工具和技术，对项目进度、成本、质量等方面进行全面监控，确保项目按计划进行。
（4）在项目收尾阶段，采用敏捷开发的持续交付和持续改进原则，确保项目交付高质量的产品，并总结经验教训，为未来项目提供借鉴。
敏捷开发流程详解
敏捷开发流程详解敏捷开发流程详解敏捷开发是一种以人为核心、迭代、循序渐进的软件开发方法。
它强调团队合作、客户需求和适应变化。
敏捷开发流程包括许多不同的方法和框架，例如Scrum、极限编程（XP）和精益开发（Lean Development）等。
本篇文章将详细介绍敏捷开发的核心原则、方法和实践。
一、敏捷开发的核心原则1.以人为本：敏捷开发强调人的重要性，包括开发人员、测试人员、产品负责人和客户。
它认为只有当人们能够有效地协作和沟通时，才能实现最大的效益。
2.可持续的开发：敏捷开发追求可持续的开发速度，保持长期稳定的工作节奏。
这需要避免突击和过度工作，以保持团队成员的积极性和效率。
3.适应变化：敏捷开发能够灵活地适应需求变化，因为客户和业务环境的变化是不可避免的。
敏捷团队应该能够快速响应这些变化，以满足客户需求。
4.快速反馈：敏捷开发通过频繁的反馈循环来优化开发过程。
团队成员应该能够及时获得反馈，以便对产品进行持续改进。
5.质量保证：敏捷开发注重质量保证，通过持续测试和代码审查来确保软件质量。
团队成员应该对代码质量负责，并采用自动化工具来提高效率。
二、敏捷开发方法1.Scrum：Scrum是一种流行的敏捷开发框架，它采用迭代式开发方法，将大型项目分解为小的可交付成果。
Scrum团队由产品负责人、开发人员、测试人员和利益相关者组成，他们共同协作完成产品目标。
2.极限编程（XP）：XP是一种以实践为基础的敏捷开发方法，它强调高效率和高质量的软件开发。
XP的核心原则包括简单性、沟通、反馈、勇气和尊重。
XP实践包括测试驱动开发（TDD）、持续集成（CI）和重构等。
3.精益开发（Lean Development）：精益开发是一种旨在消除浪费和提高生产率的开发方法。
它强调价值流分析、持续改进和客户需求，以最小化成本和最大化价值为目标。
精益开发框架包括价值流映射、5S管理、看板管理等。
4.Kanban：Kanban是一种可视化工作流管理方法，它通过可视化板和卡片来跟踪工作进度。
敏捷开发之12条敏捷原则
8.敏捷过程提可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
很多人都认为软件开发中加班是很正常的，不加班反而不正常，我对此有点不理解，这个可能是国情所致吧。敏捷过程希望能够可持续的进行开发，开发速度不会随着迭代的任务不同而不同，不欣赏所谓的拼一拼也能完成的态度，开发工作不应该是突击行为。我们不能指望说突击这个项目后就可以轻松了，因为完成一个项目后会接踵而来下一个项目，而只要还是拼拼的态度，下一个项目依旧会让你的组员再次突击。这时不知道有人会不会说，那我们就一直加班，也是“持续的开发速度”啊，这时可要注意了，持续加班智慧导致人疲劳、厌倦，保持长期恒定的速度也只是一种理想而已。
7.工作的软件是首要进度度量标准。
一般的工作都比较容易衡量任务进展，比如让你去搬运1吨的石头，我只要去称一下你已经搬运的石头重量就知道你完成多少了。而对于软件来说，在软件没有编码、测试完成之前，我们都不能因为代码编写了多少行，测试用例跑了多少个就去度量这个功能是否完成了。衡量这个功能是否完成的首要标准就是这个功能可以工作了，对用户来说已经可以应用了。
6.在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
在十几或者二十几个人组成的大团队中，文档是一种比较合适的传递知识和交流的途径。而敏捷团队一般不会很多人（大团队实施敏捷时也会分成多个小的敏捷团队），所以大量的文档交流其实并不是很经济的做法。此时面对面的交谈反而更快速有效。
9.不断地关注优秀的技能和好的设计会增强敏捷能力。
敏捷过程有很多好的技术实践可以加强产品敏捷能力，很多原则、模式和实践也可以增强敏捷开发能力。 《敏捷软件开发－原则、模式与实践》一书中介绍了很多设计，感兴趣的可以去仔细看看。
敏捷开发流程
敏捷开发流程敏捷开发是一种迭代、循序渐进的软件开发方法，它强调灵活性、合作和客户满意度。
在敏捷开发中，团队通过不断地反馈和调整，以适应变化的需求和市场。
敏捷开发流程通常包括以下几个关键步骤：需求分析和规划。
在敏捷开发中，需求分析和规划是非常重要的一步。
团队需要与客户充分沟通，了解客户的需求和期望，然后将这些需求转化为可执行的任务和计划。
在这个阶段，团队需要制定一个详细的项目计划，并确定每个迭代的目标和里程碑。
迭代开发。
敏捷开发流程是通过一系列的迭代来完成项目的。
每个迭代通常持续2到4周，团队在每个迭代中都会完成一部分功能，并进行测试和验证。
这种迭代的方式可以让团队更快地响应变化，同时也可以让客户更早地看到产品的部分成果。
持续集成和自动化测试。
在敏捷开发中，持续集成和自动化测试是非常重要的一环。
团队需要不断地将代码集成到主干分支中，并通过自动化测试来验证代码的质量。
这样可以确保团队在开发过程中能够及时发现和解决问题，同时也可以提高开发效率和质量。
客户反馈和调整。
在敏捷开发中，客户的反馈是非常重要的。
团队需要及时向客户展示产品的成果，并听取客户的意见和建议。
通过客户的反馈，团队可以及时调整产品的方向和功能，以确保产品能够满足客户的需求和期望。
持续优化和改进。
敏捷开发是一个持续优化和改进的过程。
团队需要不断地反思和总结，找出问题和不足，并采取措施进行改进。
通过持续的优化和改进，团队可以不断提高开发效率和产品质量，以更好地满足客户的需求。
总结。
敏捷开发流程强调灵活性、合作和客户满意度，通过迭代开发、持续集成和自动化测试、客户反馈和持续优化来实现项目的成功。
在实际应用中，团队需要充分理解敏捷开发的原则和方法，灵活运用这些方法来适应不断变化的需求和市场，以实现项目的成功和客户的满意。
迭代开发思维、敏捷宣言和 13 条敏捷原则对于项目工程工作的应用 -回复
迭代开发思维、敏捷宣言和13 条敏捷原则对于项目工程工作的应用-回复迭代开发思维、敏捷宣言和13 条敏捷原则是软件开发领域中常用的方法和理念，它们也逐渐在项目工程工作中应用起来。
下文将一步一步回答中括号内的主题，解释如何将这些敏捷的方法和理念应用到项目工程工作中，并分析其影响。
1. 迭代开发思维在项目工程工作中的应用迭代开发思维是将项目划分为多个迭代周期完成的软件开发方法。
在项目工程工作中，迭代开发思维可以帮助团队更好地规划工作，并增加透明度和可预测性。
首先，团队可以将项目分解为多个迭代周期。
每个迭代周期都有一个明确的目标和可衡量的交付物。
这样一来，团队可以更好地掌控项目进展，并及时调整工作重心。
其次，每个迭代周期都包含需求澄清、设计、开发、测试和交付等环节。
团队可以根据不同的项目特点，将迭代周期的长度定为几周或更短的时间段。
这样一来，开发过程更加可控，团队能够更快地反馈并修正问题。
最后，通过每个迭代周期的交付物，团队能够获得实时的反馈和评估。
这有助于团队发现问题，并及时进行调整和改进。
同时，客户也能够提前看到项目的部分成果，对项目进展有更清晰的认识。
2. 敏捷宣言在项目工程工作中的应用敏捷宣言是一组价值观和原则，强调个体和交互作为以及响应变化。
在项目工程工作中，敏捷宣言帮助团队建立起一种灵活、务实的工作方式，从而提高项目交付的质量和价值。
敏捷宣言的四个价值观是：个体和交互作为胜过流程和工具，可工作的软件胜过详尽的文档，客户合作胜过合同谈判，响应变化胜过遵循计划。
团队在项目工程工作中可以通过以下方式应用敏捷宣言：首先，强调个体和交互作为。
鼓励团队成员之间的合作和沟通，倾听每个人的观点和贡献。
团队成员可以参与项目决策的制定，共同制定工作计划，并根据需要进行调整。
其次，将可工作的软件置于更高的重要性。
保持代码的可部署性和可测试性，确保每个迭代周期都有可演示的软件交付。
通过及时交付可工作的软件，团队能够快速获得反馈，并及时进行改进。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
敏捷开发般若敏捷系列之一：序言作为预热，之前的智慧敏捷系列中提到，多数情况下敏捷实践应该如何，都要“看着办”而无有定法，但每次思考又有“避免浪费”等相对确定的思维方向，总是徘徊在虚实之间，难以把握。
智慧受到因缘（内因，外缘）所限，所以每次答案都各有不同；而各有不同背后的更高层的相对永恒的东西，则是“大智慧，妙智慧”，就是般若（佛教语，音“波惹”）。
缘起本系列将尝试解决几个终极问题：1. 什么是敏捷？2. 怎样知道我是否敏捷了？3. 应该怎样推广敏捷？4. 我是否适合敏捷？5. 敏捷未来会怎样？简单地说，若在解决这些问题前附加上前提条件，要“看着办”，则只能算是智慧敏捷；若没有前提条件得出的答案，则是般若敏捷。
伏笔本系列会引用、解说一些IT之外的理论、经典，不过会尝试从敏捷开发的角度来看待。
为了写这个系列时不发生太大偏差，曾经阅读了几十万字的文字、书籍，以及近百个网页，意识到真理并没有“原意是什么”，而只能在解决具体问题的时候，看到其中一个侧面。
因此本系列中对一些概念所做的“曲解”，其实是角度不同所看到的“侧面”，请懂行的读者以此处之。
若有关于原意的讨论，或许会在本系列的最后增加一篇。
答案尝试过用更容易懂的语言描述这些答案，但都失败了。
就像“床前明月光，疑是地上霜”可以解释，但是结果了然无趣，还记不住，无法达成共识。
如果有了同样概括还易懂的描述，请在评论中提出来。
1. 什么是敏捷？无我无住，即是敏捷。
2. 怎样知道我是否敏捷了？伪命题。
（以后说）3. 应该怎样推广敏捷？以无我之心，行无住之法。
4. 我是否适合敏捷？适合。
5. 敏捷未来会怎样？正法，像法，灭法。
答案很短，甚至短过问题。
不好懂，但是也没有替代语言，本系列会一一解释。
文中的多数内容，略作变化，就可以用于敏捷之外的事物，乃至于几乎任何事物。
就像稻盛和夫的管理思想，除了能开创两个世界500强，还能再挽救第三个世界500强，而三者各自处于不同的行业。
这种超越因缘限制的智慧，就是般若。
敏捷开发般若敏捷系列之二：什么是敏捷（上）（无住，不住于法，破法执）所谓无住，包括两个含义：不住于法，不住于空。
前者比较好理解，后者会在下篇详述。
不住于法，就是不执着于具体方法的意思，就是所使用的方法应该基于实际情况作出判断，而不是认为世界上有最好的方法，必须遵守。
法执对法的执着，称为法执。
典型的法执，是很多企业使用CMMI的方法。
本人曾经做过10多家企业的CMMI培训、咨询，所需工作日从41天～43天不等。
你能想象这么多企业，起点不同，终点不同，人员不同，行业不同，能用相同的咨询工作量完成CMMI改进吗？我和我所在的公司都不是不负责任的公司，我们因此而丢失了几乎所有的要求41天之下的咨询单子，这实际上是一个下限日期，但所有企业都义无反顾地选择了它。
后来我去了欧洲的咨询公司DNV，因为这家公司告诉我他们在欧洲的咨询是150天×2年=1个CMMI 级别，在欧洲本部与国外咨询师们交流时真相也是如此，因此充满了新的希望。
但结果是我们的咨询业务在国内举步维艰，因为这样做的费用太高了，时间太长了。
41～43的精确性，表明即使用户不只是想要一纸证书，也幻想一定有一种大致统一的方法让企业得以改进。
从98年开始的“言必称MOTO”，到后来的学联想，学华为，到后来不知道该学什么了，请直接给我套模板吧，都是法执的体现。
敏捷法执敏捷破掉了旧法，但也立了新法。
何以见得？“怎么知道我们敏捷了呢？”“我们这样做，算是敏捷吗？”这些问题，都表明敏捷是有法可依的，否则这些问题就无从说起。
而若破除法执，这些问题也就成了伪命题，没有答案也不用回答。
之后细讲“敏捷的未来如何”的时候，会讲到“敏捷开发无论本意如何好，在推广的时候都一定会被掺杂商业利益，从而变坏。
”（上次聚会一个专家的话，大家齐点头）其实在敏捷界早有纷争，各说各的流派好。
这些都是因为大家在推广不同的法，自然就会出现纷争。
而实际上，诸法平等无有高下，只有因缘（内因，外缘）的差别，导致不同场景应该使用不同的方法，甚至什么方法都不用而用自创的新的方法。
这个在智慧敏捷系列中已有描述。
所以下面这些问题，作为敏捷语境的交流可以，但作为立意的出发点，就有问题：1. “我们每日立会还开不起来，下个月想推一下”2. “现在的自动化测试覆盖率是80%，争取做到90%”3. “我们现在的迭代周期是2周，争取做到一周”……把法当作达到目的的方法，而不是目的，是破除法执的关键。
而所谓无住，就是破除了法执，不执着地停留在固有之法上。
破除法执之后，很容易落入空执，就是认为不存在绝对最好的方法，因此无需追寻，甘于现状。
平衡空与有非常困难，这是下篇的内容。
敏捷开发般若敏捷系列之三：什么是敏捷（下）（无住，不住于空，破空执，非法，非非法）破除法执之后，很容易落入空执，就是认为不存在绝对最好的方法，因此无需追寻，甘于现状。
平衡空与有非常困难，这是本篇的内容。
法与空法与空的对立统一由来已久。
吴伯凡老师举了个例子：“一切事物都是相对的”这句话有什么问题？这句话看似相当辩证，无懈可击，但它本身就“非常绝对”，有一种内在的矛盾。
软件界的法与空是否经常听到程序员说这种话：“世界上没有完美的软件，我的代码缺陷是多，但是要让我编写没有缺陷的软件，也是不现实的。
”“你说你的方法好，但我觉得我的方法也不错的。
方法本身没有好坏，我们就别争了。
”“世界上没有完美的流程和模板，要我看还是每次现场讨论最实用。
”……这些话从逻辑上讲没有问题，但若真实发生的时候，就会发现他们并不是在谈逻辑问题，而是为自己安于现状找借口。
或者说，看似不执着于追求完美的人中，很多人正执着于安于现状。
执着于空，也是一种执着；空执，是法执的一种。
法与空的转换诸法受限于因缘的限制，因此无法永远正确，到处正确。
但反之，若与因缘结合，则般若也能从虚空中现身，成为可操作的法。
通俗地讲，就是当前（今年，这月，今天……），这里（我们行业，我们公司……），我们（我们公司，我们部门，我们项目，我们小组）……的条件下，某些法胜于另外一些法，值得追求。
若是今年，我们公司……下聚合，多半会得到流程与模板，若是今天，我们项目/小组……下聚合，多半会得到某个具体的文档或做法。
这些特点的环境中，不能执着于空，而是要求追求好的方法。
这样已经大致可以给出一个轮廓：何为敏捷？不住于法，不住于空；非法，非非法；不认为有普适的最佳方法，也不认为没有好方法，就是敏捷。
（还不完整）但这样理解敏捷，比较容易陷入困惑，因为已经破掉了很多东西，却没有立起新的东西。
下两篇“无我”，将指出敏捷开发的出发点是什么。
心（心法，出发点）与法（技法）的结合，才能产生出完整的可持续的敏捷开发方法。
敏捷开发般若敏捷系列之四：如何推广敏捷（上）（无我，无人，无众生）敏捷开发中有几个地方相当创新，或者说尽管之前的方法中可能也有涉及，但却从来没有像敏捷开发这样提升为“根本大法”来对待。
一个是“拥抱客户价值，拥抱变化”，一个是TDD/结对编程/自动化测试为代表的开发与测试的融合，一个是“团队协作/结对编程/共同估算/代码共同所有制等自组织团队实践”，还有一个则是认为协作重于流程，沟通胜于文档。
传统开发的困局在敏捷开发之前，尽管没有成文的说法，但客户与开发人员整体是个博弈的关系，双方要小心谨慎相处。
比如需求要签字确认才能开发，计划要提前敲定并监督完成；而变更要走严格的变更流程……开发人员与测试人员也基本上是两类人，有一个经典的考核方法足以让这两类人水火不容：“测试人员每发现一个Bug，开发人员扣N元，测试人员得N元”，这个对立的，零和的考核方法让这两个团队不可能坐在一起，讨论如何共同提高绩效。
传统的考核往往是考核个人，因而常常出现忙的忙死闲的闲死，键盘之声相闻，老死不相往来，一人离职，全队泡汤的情景；而敏捷开发倡导整个团队一起工作，以集体智慧共同解决问题，并以此获得生产力的提升。
敏捷破局敏捷开发的这种破局，本人并不认为是对整个管理作出深刻反思的结果，相反是忽略一切没用的制度，全心全意“逐利”的自然结果。
需求开发和变更过程，无非是想通过向客户交付价值获得回报；开发或测试无非是想提高产品质量；考核无非是想提高生产率。
繁杂的文档让客户迟迟不敢签字，或把宝贵的时间精力花费在评估和抵制客户的变更上，并不能获得回报；开发人员与测试人员的博弈，无非是最终让开发人员开发出测试人员测试不出来的Bug留给客户发现；而针对个人的考核，反而导致实际团队总生产率的下降。
敏捷开发团队发现，若能突破我们（就是开发人员，敏捷开发的发明者），测试人员，开发/测试团队，乃至突破企业/客户的界限，将大家的利益统一考虑，效果不可思量。
这也就能看出为何敏捷开发认为协作胜于流程，沟通胜于文档。
流程与文档的很大目的，就是在于跨人/跨部门工作的时候，交接完整，责任明晰。
而协作与沟通则抛弃了交接、责任这些“多余的中间产物”，令责任始终同时处于大家一起负担的状态。
无我，无人，无众生所谓无我，就是不能执着地认为自己的利益和绩效是要独立考虑的，可以独自提升。
所谓无人，就是不能把别人的利益与自己对立起来，而是要统一考虑统一提高。
所谓无众生，就是不能执着地考虑小团队的利益，也要不断扩展团队的概念；为谁考虑，谁就会积极回应，而大家的利益就可能共同提高。
这三者的基础是先要做到无我，所以这里把淡化自己、其他团队成员、团队乃至客户之间界限，将其共同利益作为出发点的心法，通称为无我。
这种无我不是形式上的，比如某些敏捷开发的程序员口口声声为客户价值负责，却不能为测试人员、产品经理的利益负责，就是只学到形式上的无我。
回报与不执着于回报无我与不考虑自己的利益是两码事，而是说若能综合考虑全体的利益，自己的利益才能得到根本保证。
但若考虑全体的利益时，执着于自身得到回报，则是另一种我执（即执着于我）。
下一篇，还将谈到回报与不执着于回报间的辩证，尤其是那些“在本公司都无法得到回报”的情况。
敏捷开发般若敏捷系列之五：如何推广敏捷（中）（无寿者，回报，破我执）除了上篇开头中提到的四个问题（“拥抱客户价值，拥抱变化”，开发与测试的融合，团队合作，协作重于流程），其实敏捷开发中还有很多实践，都是从模糊利益和绩效界限的角度出发得到的，比如持续集成和自动化测试，两者甚至模糊了长期和短期利益的边界。
依然如前文所说，这里指的不是敏捷开发发明了两者，而是说敏捷开发将两者当作根本大法来对待。
无轮回观的享乐主义在无信仰而人口众多的国家，很容易滋生享乐主义。
人们因而很难理解有信仰的国家，为什么会有人把巨额资产裸捐，而保持过着简朴的生活，以换取“天堂的生活”或“来生的幸福”。
这种情况在程序员中其实也存在。
早在2002年的时候，我有一个堪称老师的领导，他给我们描述这样一种程序员（仔细看，很常见）：“很多程序员不写文档，并不是认为所写的文档是无用的，而是认为所写的文档是对自己无用的，是花自己的时间为后来人栽树；这些人编写的代码也是混乱的，这是因为他们认为再乱，自己也能看懂，日后有没有人看得懂，是别人的事情。