Agile software development - the cooperative game - 笔记 - 4

本文是第四部分，主要讨论方法论和方法设计的一些基本规则，已经如何清晰地定制和应用这些规则。

• 第一部分。
• 第二部分。
• 第三部分。

构建发布软件的生态系统

方法论的目的在于使用所有可行的手段来保证我们可以发布预期的软件，并且这样的方法是可以确定持续进行的。方法学本身即使社交行为的创建过程。方法本身是一个关于职位描述，过程，团队中每个人需要遵守的传统的集合。

每一个组织都有自己的方法论，这些方法就是他们怎样做商业的方式。一种方法论可以说是你的组织同意采取的一种传统；这些过程可能在大部分公司并没有很正式的打印出来或者写下来。这种一致同意的传统需要我们不时得重新审视，持续的构建。

方法论概念

方法论是关于一些方法的固化和规则定义，其对过程的约束是它不同于方法本身的地方 - 你可以在不同的时候采用不同的方法；然而在一系列开发过程中，方法论代表着一直认可的基本规则和约定。

集合一群聪明人又想获得成功，我们就必须做好协调/合作和协调，离开这些手段，最聪明的人组合的团队也会变得杂乱无章，从而很难取得成功。

结构性术语

方法学有如下几个结构性要素

• 角色：明确的角色分工至关重要，什么样的角色需要什么样的职责和技能等
• 技能：角色需要的技能和专长
• 团队：不同的情况之下工作于一起的一种集体角色
• 技术：赖以完成具体工作的技术技能，关于怎样完成某种特定工作的一些知识
• 活动：人们怎样完成某些特定工作的过程，譬如计划，编码，测试等
• 过程：各种各样的活动如何连接在一起
• 工作产品： 可以是中间过程的产出，如CRC卡或者故事卡片等
• 里程碑：一些关键的时间节点，往往是关于整体进度的一个节点
• 标准：关于一些工具/类库/方法的一些传统/约束等
• 质量：关于活动和工作产物的质量属性
• 团队价值：什么样的价值被大家普遍认可

不同的方法论在上述的要素上有很多各不相同之处。

依据上述的结构性要素，常见的方法类可以划分为以下类型：

1. Normative方法，强调采用的步骤或者解决方案是完全遵守已有的工作记录。
2. Rational方法，基于工具和方法来构建
3. Participative方法，基于利益相关方和客户参与的方面
4. Heuristic方法，基于已经学习得到的经验，启发式进行

很多情况下，随着人们经验的基积累，方法论可能沿着Heuristics的方法慢慢固化下来，慢慢演进到Normative方法；譬如在计算机编程领域，算法设计方面就达到了标准化的地步；而关于将人们放在开放的办公区还是私有的办公室的方面却没有。

大部分的软件开发货活动还处于Heuristic方法就足够适用的阶段。

范围

一种方法论的范围涵盖了关于它要关注的角色范围和相关的一些活动。早期的面向对象方法论被认为是设计师作为核心的角色，活动主要是讨论技术工具和描述对应标准图形的活动；然而这样的描述不够宽泛的同时，又显得限制太多。

方法论的范围可以被概括为如下几个方面：

• 生命周期的覆盖，什么时间开始，什么时候结束
• 角色覆盖，什么样的角色参与什么样的活动
• 活动覆盖，什么样的活动在什么样的情况下开展

从这样的角度看，早起的面向对象方法仅仅局限于讨论一个很狭窄的领域，只有设计师参与，仅仅关系到项目设计阶段，从而导致经验丰富的面相对象设计师认为他们不适合参与项目的整个生命周期。从这些因素来考虑，有助于我们更好的理解怎样的方法论在怎样的场景下是更合适的。

概念性要素

为了更好的设计和定制方法论，我们需得考虑如下一些要素：

1. 方法论本身的规模大小，有多少标准，活动，质量度量物，技术描述等
2. 正规性，多大的精度控制和什么程度的过程控制是需要的，是否需要更严格的控制和错误容忍率
3. 方法论的重度，控制元素的个数，流程/活动的数目
4. 问题域大小，需要多少问题去解决，内部复杂性如何
5. 项目本身的大小，多少个人需要协调
6. 系统重要性，如果发生了错误，造成的损害如何，是仅仅损失钱财还是造成人命有关的灾难
7. 精确度如何，譬如设计的粒度如何，高层设计到什么样的程度为好
8. 准确度，怎样更接近真是精确度，如何算好
9. 相关性，什么样的讨论是不相关的
10. 错误容忍度
11. 可见行 - 外部怎么知道某种方法论是否被很好遵循，是否需要审计等
12. 扩展性
13. 稳定性 - 多大程度上它可能发生变化

发布一种方法论

发布方法论需要发布两种组件，一时可视的形象化视图，一是文本本身。形象化的视图可能无法显示实践/标准和其它一些对组织很重要的协作方式描述。这些信息很难作出一个形象化的视图来呈现，这时候我们必须用文本来列出来。

发布出来的方法论文本需要描述技术/活动/会议/质量度量/工作角色的指责标准这样的东西。方法论的文本可能变得异常庞大，即使一个很细微的方法论，譬如只有4种角色，每种角色只有4种产出，每个产出只有4个里程碑，最终也会产生出68=4+16+48个互锁的子部分需要描述清楚。即使是以轻量级著称的XP方法论，最初只有200页那么多，现在已经达到了1000页才可以描述清楚。

但是很多时候，公司组织并不会将这些东西打印出来，因为

1. 理解这些比文档本身重要 - Jim Highsmith
2. 组织的需求总是在变化的，固定下来的文本很容易过时也没有实用性

组织需要不断的演进既有的方法论，变更不合适的部分，在组织内部的不同团队之间传递好的习惯和实践。有很多中方法来减少这些方法论文本的厚度:

1. 提供工作产出物的范本
2. 移除技术操作指南，让人们用更自然的方式协作
3. 根据角色来组织方法论文本，某种产出物按照不同的角色给出简单的描述
4. 做些关于流程的小实践，通过小的练习实践这些方法，然后再用于具体的工作

方法论设计原则

常见的设计错误

成功的方法论项目

作者敏感度

七大准则

审视XP

究竟为何需要方法论