本文是第四部分，主要讨论方法论和方法设计的一些基本规则，已经如何清晰地定制和应用这些规则。
构建发布软件的生态系统
方法论的目的在于使用所有可行的手段来保证我们可以发布预期的软件，并且这样的方法是可以确定持续进行的。方法学本身即使社交行为的创建过程。方法本身是一个关于职位描述，过程，团队中每个人需要遵守的传统的集合。
每一个组织都有自己的方法论，这些方法就是他们怎样做商业的方式。一种方法论可以说是你的组织同意采取的一种传统；这些过程可能在大部分公司并没有很正式的打印出来或者写下来。这种一致同意的传统需要我们不时得重新审视，持续的构建。
方法论概念
方法论是关于一些方法的固化和规则定义，其对过程的约束是它不同于方法本身的地方 – 你可以在不同的时候采用不同的方法；然而在一系列开发过程中，方法论代表着一直认可的基本规则和约定。
集合一群聪明人又想获得成功，我们就必须做好协调/合作和协调，离开这些手段，最聪明的人组合的团队也会变得杂乱无章，从而很难取得成功。
结构性术语
方法学有如下几个结构性要素
- 角色：明确的角色分工至关重要，什么样的角色需要什么样的职责和技能等
- 技能：角色需要的技能和专长
- 团队：不同的情况之下工作于一起的一种集体角色
- 技术：赖以完成具体工作的技术技能，关于怎样完成某种特定工作的一些知识
- 活动：人们怎样完成某些特定工作的过程，譬如计划，编码，测试等
- 过程：各种各样的活动如何连接在一起
- 工作产品： 可以是中间过程的产出，如CRC卡或者故事卡片等
- 里程碑：一些关键的时间节点，往往是关于整体进度的一个节点
- 标准：关于一些工具/类库/方法的一些传统/约束等
- 质量：关于活动和工作产物的质量属性
- 团队价值：什么样的价值被大家普遍认可
不同的方法论在上述的要素上有很多各不相同之处。
依据上述的结构性要素，常见的方法类可以划分为以下类型：
- Normative方法，强调采用的步骤或者解决方案是完全遵守已有的工作记录。
- Rational方法，基于工具和方法来构建
- Participative方法，基于利益相关方和客户参与的方面
- Heuristic方法，基于已经学习得到的经验，启发式进行
很多情况下，随着人们经验的基积累，方法论可能沿着Heuristics的方法慢慢固化下来，慢慢演进到Normative方法；譬如在计算机编程领域，算法设计方面就达到了标准化的地步；而关于将人们放在开放的办公区还是私有的办公室的方面却没有。
大部分的软件开发货活动还处于Heuristic方法就足够适用的阶段。
范围
一种方法论的范围涵盖了关于它要关注的角色范围和相关的一些活动。早期的面向对象方法论被认为是设计师作为核心的角色，活动主要是讨论技术工具和描述对应标准图形的活动；然而这样的描述不够宽泛的同时，又显得限制太多。
方法论的范围可以被概括为如下几个方面：
- 生命周期的覆盖，什么时间开始，什么时候结束
- 角色覆盖，什么样的角色参与什么样的活动
- 活动覆盖，什么样的活动在什么样的情况下开展
从这样的角度看，早起的面向对象方法仅仅局限于讨论一个很狭窄的领域，只有设计师参与，仅仅关系到项目设计阶段，从而导致经验丰富的面相对象设计师认为他们不适合参与项目的整个生命周期。从这些因素来考虑，有助于我们更好的理解怎样的方法论在怎样的场景下是更合适的。
概念性要素
为了更好的设计和定制方法论，我们需得考虑如下一些要素：
- 方法论本身的规模大小，有多少标准，活动，质量度量物，技术描述等
- 正规性，多大的精度控制和什么程度的过程控制是需要的，是否需要更严格的控制和错误容忍率
- 方法论的重度，控制元素的个数，流程/活动的数目
- 问题域大小，需要多少问题去解决，内部复杂性如何
- 项目本身的大小，多少个人需要协调
- 系统重要性，如果发生了错误，造成的损害如何，是仅仅损失钱财还是造成人命有关的灾难
- 精确度如何，譬如设计的粒度如何，高层设计到什么样的程度为好
- 准确度，怎样更接近真是精确度，如何算好
- 相关性，什么样的讨论是不相关的
- 错误容忍度
- 可见行 – 外部怎么知道某种方法论是否被很好遵循，是否需要审计等
- 扩展性
- 稳定性 – 多大程度上它可能发生变化
发布一种方法论
发布方法论需要发布两种组件，一时可视的形象化视图，一是文本本身。形象化的视图可能无法显示实践/标准和其它一些对组织很重要的协作方式描述。这些信息很难作出一个形象化的视图来呈现，这时候我们必须用文本来列出来。
发布出来的方法论文本需要描述技术/活动/会议/质量度量/工作角色的指责标准这样的东西。方法论的文本可能变得异常庞大，即使一个很细微的方法论，譬如只有4种角色，每种角色只有4种产出，每个产出只有4个里程碑，最终也会产生出68=4+16+48个互锁的子部分需要描述清楚。即使是以轻量级著称的XP方法论，最初只有200页那么多，现在已经达到了1000页才可以描述清楚。
但是很多时候，公司组织并不会将这些东西打印出来，因为
- 理解这些比文档本身重要 – Jim Highsmith
- 组织的需求总是在变化的，固定下来的文本很容易过时也没有实用性
组织需要不断的演进既有的方法论，变更不合适的部分，在组织内部的不同团队之间传递好的习惯和实践。有很多中方法来减少这些方法论文本的厚度:
- 提供工作产出物的范本
- 移除技术操作指南，让人们用更自然的方式协作
- 根据角色来组织方法论文本，某种产出物按照不同的角色给出简单的描述
- 做些关于流程的小实践，通过小的练习实践这些方法，然后再用于具体的工作
方法论设计原则
方法论的设计和普通的软件/硬件设计有所不同，需要考虑如下一些原则：
- 人是可变的因素，而其它设计很少考虑这一方面
- 不同的项目之间可能有很大不同，某个项目适合的方法论到了一个不同的项目可能完全不适合
- 调试周期很长，测试和调试时间可能需要以月甚至年计
- 技术在不断发生变化，因此方法论也需得随着跟进
常见的设计错误
没有太多方法论设计经验的新手很容易犯如下通用的错误:
- 试图找到对所有项目普适的方法，然而很多时候我们需要去剪裁和定制
- 缺乏容忍 – 你可能认为你有所有关于这个方法论的所有真理而每个方面都需要人们去严格遵守，这样很少能直接行得通。人们更愿意接受微笑的变化，一次改变一点点儿就是，无需超过必须要求的严谨限度
- 过于重量级 – 很多组织会认为更为厚重的方法论可能是更加安全的，这种想法可能来源于项目管理人员不能直接读懂代码而导致的失去控制的恐惧感，然而更好的做法是努力做大信任团队的成员；项目管理的艺术在于知道何时选择相信你的团队和人，合适选择不信任，同时需要意识到什么时候添加更多的限制可能带来更多的负担而非安全感
- 过多的依赖于不必要的规则/实践/方法，这些东西有时候反而带来更多的负担
- 仅仅限于空洞的理论但是从来没有经过验证 – 没有验证的空头理论很可能脱离实际太远，很多看来可以工作的方法论实际可能根本不工作。不管怎样的理论，至少得现有一次实践的结论可以拿来分析
- 仅仅使用过一次的方法论 – 有一个项目采用过这样的方法论取得了成功就马上宣布这些方法是通用的同样很危险。譬如一个方法实现一个成功的项目之后，主要人员被开除的方法论就没有什么参考意义
成功的方法论项目
Cockburn的研究表明成功的方法论项目具有如下三个核心特征：
- 项目被成功发布出去。不管是否超出预算或者延期，产品最后必须被递交给客户
- 领导层没有因为这个项目的实施被扫地出门
- 工作在该项目的人愿意继续尝试同样的方法,尤其是倡导该方法的发起人离开这个组织之后，其他人是否仍然愿意尝试？
目前位置有三种方法被Cockburn认为是严格满足最后一条的： – Responsibility design driven(1990) – Extreme Programming(1999) – Crystal Clear(2005)
作者敏感度
方法论作者工作的方法和其他人一样，他的独特背景/历史经验对他的视角和结论有很大的影响，因此我们应该关注幕后的东西。Kent Beck说，所有的方法论都来自于恐惧。方法论作者往往基于对他以往经验中的失败的地方的恐惧展开：
- 担忧程序员容易犯太多小错误？做代码评审吧
- 担忧用户不知他们真正想要的是什么？做个原型吧
- 担心设计师中途辞职？让他们在项目事实中多写文档也许是个选择
有时候人们愿意去选择信任团队中的人，然而他们却不时会犯一些小错误。有些事很选择相信人很重要，有时候却需要找到一种方法来判断人们在某些方面是否是值得信任的。警惕方法论作者的个人哲学和背景，因为这些东西很可能决定了这些方法论是基于怎样的经验作出的。
七大准则
如下7条准则是作者认为在设计和评估方法论时很重要的：
- 交互式的，面对面的沟通方式对于交换信息是最廉价和最快的通道
- 过度厚重的方法论可能代价不菲
- 更大的团队可能需要更为厚重的方法论
- 影响更为关键的项目可能需要更庄重正式的方法论
- 增加反馈和沟通可以大大减少所需要的中间交付物
- 自律/技巧/理解重于流程/文档，理解远远终于写在纸面上的文字
- 非瓶颈项目上的效率是可以适度牺牲的 – 如果需要1个人做DB但是有5个程序员，那么可以选择一部份程序员做一些DB的工作，即使这些程序员的DB能力不是太强
审视XP
XP自诞生以来就引起诸多热捧和争议。在它使用的范围内，它有着极高的效率，然而一旦XP需要扩展到比较大的团队，很多地方就需要认真的修正。也许是鉴于外界对XP的争议和批评，Kent Beck于2005年修正了他的想法，改变了很多第一版中的做法，将XP的很多强制性要求做了更为宽松的解释，使它不再想一种虔诚的宗教；使用它提供的很多实践可以极大提高你的组织的效率，然而并不是说你必须做到所有的一切。
XP 概要
XP强调了如下这些要素：
- 3～10个程序员
- 安排一个或者多个现场客户
- 所有人在一个大的办公区域工作
- 尽量让工作站集中于办公区中间，显示器排列成一个圆形
- 用3个星期的迭代，每个迭代必须产生可以运行的经过客户验收测试的代码
- 需求收集的单元是用户故事，每个故事必须在一次迭代完成,每次迭代，程序员估计需要的时间，然后客户分解范围，根据价值大小排列优先级
- 程序员结对编程
- 遵循严格的编码规范
- 每次提交代码做严格的100%单元测试
- 每次提交用15分钟乃至一个小时，一天可能集成很多次
- 程序员编码的时候，客户可以为程序员澄清问题，写验收测试，为下一个迭代挑选用户故事
- 团队每天一起沟通，采用每日站会互相报告进度
XP遵循四条基本的价值，简单，沟通，测试，勇气。勇气以为着容许任何时候将系统往前推进，作出改进。团队中，需要有一个人担当coach的角色，保证基本的价值观被遵守和执行。
XP 剖析
XP极大得应用了Osmotic Communication，面对面沟通，信息对流和放置于墙壁上的信息辐射器。持续在场的现场专家保证了问题提出到得到解答的时间极大的缩短，找到某个问题的根源和得到某个想要的信息的时间/经历花费极大得减小，然而信息分散的几率也会升高。
沟通和反馈更加快捷；现场客户保证了任何需求的澄清都得到即使的反馈。人们互相沟通的长处得到直接的应用，结对编程弥补了人们容易犯错的缺点。
XP需要很高的自律和严格遵守编码规范，集体代码所有权使得所有的信息每个程序员都可以公开获取。单元测试和持续集成保证了代码的质量，重构确保设计在保持初始简单的同时能够不断演进；结对编程在第一时间发现潜在的错误，降低后期修正的成本。Coach的角色保证这些纪律得到实践和执行。
XP这些特点决定了它更适合物理上在一起的小团队，在保持团队小而精的同时，通过上述的纪律获取更高的质量和生产率。
调整XP
XP的两个方面经常被人诟病：
缺乏文档 XP将可以工作的软件作为首要的文档，其它的文档都是相对次要的。团队成员通过口头的沟通和交流来开发软件，一些简单的卡片不过是为了便于沟通或者唤起人们短期的记忆。人们相互之间共享的知识和记忆对下一个项目的开发是宝贵的经验。然而有时候，上层老板可能希望在软件发布的同时看到一些操作的文档或者进度中的状态报告。即使客户不需要产品使用手册，决策层也可能需要实时监控项目的进度情况，调整投资决策。团队成员的离职也可能造成共享知识的弱化或者丢失 – 因为总有一些信息和知识不是任何一个人都清楚。
仅仅对小团队适用 十个人的团队用XP来做事可能是非常高效的，而三十个人的团队在将团队拆分为小的团队的时候，需要仔细的处理好接口/文档之间的关系，确保现场客户的角色在每个团队里边都持续存在。这些听起来是相当困难的，但是并非完全不可行。
究竟为何需要方法论
方法论本身讨论的是，我们怎样在一起工作的问题。它可以服务于如下目的：
- 为团队中新人提供工作流程介绍 – 每个信任都很关心我们怎么融入这个环境，了解整个团队的工作模式
- 人员更替 – 有些时候这是不可避免的，虽然人并不是可插拔的物品
- 明晰职责 – XP的现场客户需要负责优先级，而程序员需要负责用户故事的工作量估计
- 给项目赞助者提供信息 – 一些厚重的方法学在这方面显出其优势，尤其是项目出资人需要了解进度和投资回报等因素
- 呈现可以看到的项目进度信息
- 提供教育和培训 – 完整定制的方法学可以帮助人们更快的统一过程，帮助他们学习和提高工作技巧
没有一种方法学是开箱即用的 – 我们必须根据具体的团队项目人员情况，适当的作出调整和剪裁，才能找到合适的方法论。