1 - 敏捷问题解决方式

敏捷是什么？这是我一直在思考的一个问题，同时也在敏捷之旅2010成都站提出。这似乎是一个不值得推敲的问题，敏捷就是“敏捷”。但为何某些实践可以称为敏捷实践？方法学可以称为敏捷方法学？是不是存在一根看不见的线把这一切关联起来？

这让我如此着迷，没有什么能够比寻找答案更让人着迷了。下面就是我的尝试，肯定不完善，但即使是小小的帮助也是一个进步。

作为问题解决方式的敏捷

“敏捷”是一种问题解决方式，是在问题本身或问题解决能力不能确定的情况下取得尽可能好的结果（近优解或更优解）的问题解决方式。

基本做法

1. -->角色划分

在敏捷问题解决方式中，问题提出者的作用得到强调。问题被按照问题提出者可理解、可检验的方式进行分解，问题提出者负责对分解后的单位问题进行检验。而问题解决者需要与问题提出者密切配合，共同进行问题分解和检验适应。

2. -->迭代

敏捷问题解决方式强调问题分解后的多次完成与反复验证。迭代是敏捷问题解决方式的基础要素，也是对问题提出者合适的时间周期。在一个迭代的单位时间内至少完成一个由原问题分解而成的单位问题。

3. -->问题分解与检验

敏捷问题解决方式是以问题分解与检验为中心进行推进的。在问题分解阶段，以问题提出者为中心进行问题分解，包括优先级设定，确保单位问题符合客户理解与期望，不会破坏问题完整性。在单位时间末尾，问题提出者和问题解决者对问题完整性进行检查，能够得到问题反馈和问题解决能力反馈，双方均可以在下一个单位时间内进行改进。

4. -->单位问题解决

敏捷问题解决方式重视单位时间内的“完成”。敏捷问题解决方式力图保证将大部分时间用于解决单位问题。

复杂问题

敏捷问题解决方式针对复杂问题采用层层分解，逐级反馈。

1. 角色划分

在面对复杂问题时，敏捷问题解决方式将角色划分为多层次的问题提出者与问题解决者。这些多层次的问题提出者与问题解决者需紧密沟通与协作，共同解决问题。

2. 问题分解与检验

a) 在每一层次

依然是问题提出者与问题解决者的协作关系。依然是问题分解、问题解决和检验适应3个步骤。

b) 在层次之间

上一层次的问题解决者成为了下一层次的问题提出者。下一层次的整个过程成为上一层次的问题解决步骤。

特点

1. 人

敏捷问题解决方式是以人为中心的问题解决方式。问题的解决与否依赖于人的检验。问题解决的过程依赖于人与人的沟通与协作。

2. 专注

在单位时间内，作为问题解决者的个人是不可分解的最小单位。

3. 沟通与协作

问题的解决依赖于问题提出者与问题解决者的沟通与协作。

4. 行动派

严格的时间盒控制，保证大部分时间应该放在问题解决上。

5. 检验适应

敏捷问题解决方式是以反馈为基础的问题解决方式。在单位时间结束后，创造有效反馈。推进问题的解决，加深对问题的认识和增强问题解决能力。

敏捷问题解决方式与敏捷宣言

软件开发是问题本身和问题解决能力不确定的一种典型情况。而敏捷问题解决方式与敏捷宣言是相适应的，下面以敏捷问题解决方式来解读敏捷宣言。

《敏捷宣言》中的4条价值观：

1. 个体与交互 重于 过程和工具

在敏捷问题解决方式中，问题的解决取决于问题提出者和问题解决者的能力和他们之间的相互协作，过程和工具是相对次要的，只有在满足前者的基础上才有作用。

2. 可用的软件 重于 完备的文档

问题解决的结果重于中间产物，敏捷问题解决方式不鼓励将时间大量投入到文档的完备化，而应该投入到问题解决上。

3. 客户协作 重于 合同谈判

软件开发是客户与软件开发商共同解决问题的过程。客户作为最关键的问题提出者，与问题解决者的协作是解决问题的关键。

4. 响应变化 重于 遵循计划

所有的预测都仅仅是预测，通过敏捷问题解决方式，我们可以适应变化并快速学习。

《敏捷宣言》背后的12准则：

1. 我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。

为客户解决问题是软件开发的最重要的目标。

2. 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。

问题可能随时会变化，软件开发是以问题提出者为中心解决问题提出者的问题，因此重要的是解决问题而不是限制变化。

3. 要不断交付可用的软件，周期从几周到几个月不等，且越短越好。

检验适应是敏捷问题解决方式的核心方式，不断以客户可检验的方式交付可用的软件。

4. 项目过程中，业务人员与开发人员必须在一起工作。

业务人员作为软件开发的问题提出者，需要与软件开发团队（问题解决者）密切配合，促进问题解决。

5. 要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。

问题解决取决于人的投入程度与状态，激励项目人员，为他们创造环境和条件，能够有助于问题的解决。

6. 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。

敏捷问题解决方式推荐进行面对面的沟通与交流，这是人与人合作解决问题的最好沟通方式。

7. 可用的软件是衡量进度的主要指标。

只以单位问题的解决结果也就是完成作为进度衡量的指标。

8. 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。

在敏捷问题解决方式中，良好设计的迭代与稳定的迭代进度是最有效的和最可预测的问题解决方式。

9. 对技术的精益求精以及对设计的不断完善将提升敏捷性。

不断追求更高效的解决问题，技术与设计是解决软件问题的重要手段。

10. 要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。

问题的解决不取决于解决方案的复杂性，而是源自于对问题提出者和问题本身的深刻理解。当然，问题解决方式本身也是重要的。

11. 最佳的架构、需求和设计出自于自组织的团队。

问题提出者与问题解决者所组成的团队是解决问题的最佳组合，发挥团队的力量解决问题远胜于不明情况的指手划脚。

12. 团队要定期反省如何能够做到更有效，并相应地调整团队的行为。

检验适应是敏捷问题解决方式的核心。

2 - 敏捷软件开发概述

如同前文所述，可以把敏捷看做一种问题解决方式。下面我们就从敏捷问题解决方式的角度解读敏捷软件开发。

敏捷软件开发

软件开发是问题本身和问题解决能力不确定的一种典型情况。软件项目起源于人的构想，随着时间不断变化。项目团队对项目的认识随时间不断加深，成员能力不断提升，工作方式和过程改变导致团队开发能力不断变化。

敏捷软件开发分为3个层次。

产品层

1. 问题与问题参与者

问题是产品构想。问题提出者是客户（业务负责人），问题解决者是特性团队。

2. 问题分解与检验

a) 问题分解

将问题从产品构想分解到业务特性。业务特性是问题提出者客户可检验的单位问题。

b) 问题检验

在可工作的软件中检验完成的业务特性。可工作的软件是客户检验问题完整性的基础。

3. 迭代

迭代的大小从1周到4周不等，这是一个客户可接受的频率（节奏）。

业务特性层

1. 问题与问题参与者

问题是业务特性。问题提出者是特性团队，问题解决者是特性团队或负责业务特性的相关人员。

2. 问题分解与检验

a) 问题分解

将问题从业务特性分解到单元。单元是特性团队可检验的单位问题。

b) 问题检验

在可工作的业务特性中检验单元的完成情况。

3. 迭代

迭代的大小从小时到天，这是一个特性团队可接受的频率（节奏）。

单元层

1. 问题与问题参与者

问题是单元。问题提出者是开发人员，问题解决者是开发人员自身或另一个开发人员（结对编程）。

2. 问题分解与检验

a) 问题分解

将问题从单元分解到单元职责。

b) 问题检验

在预期的单元测试中检验单元职责的完成情况。

3. 迭代

迭代的大小从分到小时，这是一个开发人员可接受的频率（节奏）。

常见敏捷软件开发方法学

Scrum

Scrum和敏捷软件卡发有很多共同点。而对比敏捷软件开发，可以看到Scrum的敏捷实践侧重于高层，而缺乏低层的敏捷实践。

极限编程XP

XP与敏捷软件开发的吻合度更高。它是由一系列简单却互相依赖的实践组成，这些实践结合在一起形成了一个胜于部分结合的整体。

3 - 我心中的敏捷

“敏捷是什么”，这个问题长期以来一直困扰着我。前段时间提出了敏捷问题解决方式，算是从做法（做事的方法）上对敏捷进行了一个简单的总结。最近一直在清理，这就试图描述一下我心中的敏捷。因为个人一直从事软件开发工作，所以文中的主体部分有一些与软件开发相关的经验，不能做到完全的通用化。

我心中的敏捷

从信仰、理论到实践与方法学，这就是我心目中完整的敏捷知识体系。

敏捷信仰

主要内容

敏捷信仰，也可以被称为敏捷世界观，源于经验主义或逻辑实证主义。其主要内容包括：

1. 世界是复杂的和不断变化的，人是导致复杂和变化的主要原因

敏捷对此使用的词汇是我们不能预测未来。这看似不可知论，但其实这句话的意思是我们无法准确预测变化的影响。

敏捷软件开发是复杂和不断变化的典型，客户、开发团队都处于不断变化中。参考彼得德鲁克的“知识工人”理论，《第五项修炼》等。

2. 经验主义，小步前进，持续改善

逻辑实证主义强调经验的获取是建立在实践的基础上。因此在逻辑实证主义看来，经验主义，小步前进，持续改善是应对复杂和变化的最佳方式，也是敏捷的核心。这就是“Kaizen”，持续改善文化的来源。

对比描述

敏捷信仰导致了敏捷与其他方式的不同，为方便理解，现进行对比。

1. 科学主义或唯科学主义Scientism

科学主义是一种主张以自然科学技术为整个哲学的基础，并确信它能解决一切问题的哲学观点。其主要特点是在尊重科学经验与事实的名义下，推行不可知论和主观经验主义。科学主义的流行导致了事实与价值、科学与人文的分离和对立。

科学主义影响深远，对于计算机是工程学还是科学，现在仍在争论中，但我们在计算机发展的过程中处处均可发现科学主义的身影。科学主义极大的影响了软件开发的发展历程。

当我们陷于优劣争论，忙于证明某种方式比其他方式更加科学的时候，已经落入了科学主义的陷阱。

2. 非理论派与不可知论

在问题解决过程中，还存在这种纯实践派，他们反对任何形式的理论，主张实践出真知。认为复杂问题是不可预知的，从而没有预知的必要。这是典型的两分法，在实践理论失败后反对一切理论。

3. 中庸与太极

敏捷看上去与中国传统的中庸和太极是如此的相似。但是敏捷本质上将没有最佳做法的含义，也不代表混沌。

敏捷拥有严肃、完整和科学的做事方式，比我们见过的任何一种方法更加的严格。

4. 精益思想

精益思想的两大支柱是尊重他人和持续改善，这一点与敏捷惊人的一致，其根源在于他们都源于同样的哲学-逻辑实证主义。

敏捷理论

根据个人的理解，敏捷的理论根源主要源于下述理论和更多的实践证明，因为敏捷本身就是实践的结果。

1. 复杂系统和混沌理论

敏捷中常见的提法包括系统思考、局部优化等。

传统软件开发中以分工为基础，更强调分解，不同角色应对分解后的简单问题。敏捷软件开发中强调系统，每个参与者都有机会获取对整个系统的认识，同时“可工作的软件”即分解后的集成在敏捷软件开发中是重中之重。

2. 博弈论/运筹学/排队论

敏捷大量应用了博弈论的研究，典型是将软件开发比喻成一种合作博弈。软件开发涉及的利益相关者众多，是一种典型的博弈应用，如何取得多赢，敏捷软件开发对此进行了深入的思考，并对传统软件开发的许多工作方式提出了质疑。

3. 认知科学/知识工人理论

敏捷应用了许多对人本身的认知、心智的研究成果。

a) 人类擅长比较而不是量化

敏捷软件开发中大量应用比较和趋势，取消了很多无效和成本过高的量化指标。用价值作为软件交付的结果，用计划扑克实践进行基于比较的估算与计划。“尽快交付更高的价值Deliver higher value faster”成为敏捷的目标。

b) 人类对重复和节奏的偏爱

c) 反馈对人类的重要作用

敏捷价值观

1. 承诺

2. 专注

3. 开放

4. 尊重

5. 勇气

敏捷问题解决方式

敏捷问题解决方式是对敏捷工作方法的总结。敏捷不仅仅是信仰，它还提供了具体的、有效的工作方式。

1. 保持系统性

a) 敏捷问题解决方式并未预测问题解决的最佳答案，而只是提出了一种方法框架方便经验获取。

b) 问题经分解后仍然是问题（单位问题），保持了问题解决的系统性。

c) 问题的检验注重问题本身的完整性和问题解决方法的系统性。

d) 敏捷问题解决方式以产出为基准进行回顾和优化，原因在于以投入为基准进行的优化对于复杂系统（非线性）效果不佳。

2. 沟通与合作的博弈

a) 敏捷问题解决方式强调问题提出者的参与，增强了问题提出者与问题解决者的沟通合作。

b) 敏捷问题解决方式通过问题分解模式的转换，对单位问题进行转移视角分解成另一类单位问题并解决，实现问题解决者内部的沟通合作。

3. 强调人的作用

a) 问题的解决与否基于问题提出者的主观判断，而非某种客观依据。

b) 问题的分解基于问题提出者与问题解决者的沟通合作，而非某种预知的科学方式。

c) 以问题的检验为导向，验证工作方法、问题分解方式的有效性。

敏捷实践

敏捷实践是敏捷信仰与敏捷问题解决方式应用于实践的结果。存在大量的敏捷实践，这里就不一一列举。唯一需要强调的是，单独强调某一敏捷实践的作用容易忽视系统性，应该在敏捷信仰、敏捷理论、敏捷价值观和敏捷问题解决方式的指导下，系统的应用敏捷实践。

敏捷方法学

敏捷方法学由一系列敏捷实践组成，但是借用XP中的一句话，这些实践结合在一起形成了一个胜于部分结合的整体。

1. Scrum

2. XP

敏捷应用

敏捷适用于解决以人为中心的问题，因此可以广泛应用于上述范围。