今天继续，聊聊极限编程12最佳实践的流程圈
流程圈 （Process Circle）
流程圈包括 每周40小时工作制（40-Hour Week），系统愿景（System Metaphor）,小型发布（Short Releases），简单设计（Simple Design）。
图一 流程圈 （Process Circle）每周40小时工作制（40-Hour Week）
指的是每周工作的时长不要超过40小时，因为工作时间太长会让人容易犯错误，团队成员应该高效的工作，而不是幸苦的工作。所以极限编程是不提倡死亡行军的。
图二 每周40小时工作制（40-Hour Week）系统愿景（System Metaphor）
通过描述系统如何运作、新的功能以何种方式加入到系统。它通常包含了一些可以参照和比较的类和设计模式。极限编程不需要事先进行详细的架构设计。极限编程在系统实现初期不需要进行详细的架构设计，而是在迭代周期中不断的细化架构。
图三 系统愿景（System Metaphor）小型发布（Short Releases）
在段时间内进行新版本的迭代，这样很容易控制版本的节奏，风险和进度。同时也能得到各方的持续反馈。类似于敏捷管理中的sprint。小型发布突出体现了敏捷方法的优点。如果能够保证测试先行、代码重构、持续集成等最佳实践，实现小型发布也不是一件困难的事情，在有条件的组织可以考虑使用。
图四 小型发布（Short Releases）简单设计（Simple Design）
这也是产品设计中经常提及的“少即是多 less is more”，回到代码设计这块，代码的设计应该尽可能的简单，只要满足当前功能的要求，不多也不少。我们在设计的过程中，需要充分考虑模块化设计，可以复用。
传统的软件开发过程，对于设计是自顶而下的，强调设计先行，在代码开始编写之前，要有一个完美的设计模型。它的前提是需求不变化，或者很少变化；而XP认为需求是会经常变化的，因此设计不能一蹴而就，而应该是一项持续进行的过程。
图五 简单设计（Simple Design）
其他文章：
22.【Kevin聊敏捷】XP极限编程之12最佳实践（二）
21.【Kevin聊敏捷】XP极限编程之12最佳实践（一）
20.【Kevin聊敏捷】XP极限编程之5个价值
19.【Kevin聊敏捷】XP极限编程之概述
18.【Kevin聊敏捷】敏捷项目管理之Sprint Retrospective 迭代回顾会
17.【Kevin聊敏捷】敏捷项目管理之Sprint Review 迭代评审会
16.【Kevin聊敏捷】敏捷项目管理之Daily Scrum 每日站立会
15.【Kevin聊敏捷】敏捷项目管理之Sprint Planning 迭代规划会
14.【Kevin聊敏捷】敏捷项目管理之Scrum Events 敏捷活动
13.【Kevin聊敏捷】敏捷项目管理之Scrum Master 敏捷教练
12.【Kevin聊敏捷】敏捷项目管理之Development Team 开发团队
11.【Kevin聊敏捷】敏捷项目管理之Product Owner 产品负责人（二）
10.【Kevin聊敏捷】敏捷项目管理之Product Owner 产品负责人（一）
09.【Kevin聊敏捷】敏捷项目管理之Scrum三大支柱
08.【Kevin聊敏捷】敏捷项目管理之Scrum价值
07.【Kevin聊敏捷】敏捷项目管理之Scrum
06.【Kevin聊敏捷】项目生命周期之敏捷型生命周期
05.【Kevin聊敏捷】项目生命周期之增量型生命周期
04.【Kevin聊敏捷】项目生命周期之迭代型生命周期
03.【Kevin聊敏捷】项目生命周期之预测型生命周期
02.【Kevin聊敏捷】项目管理的四种生命周期
01.【Kevin聊敏捷】传统项目管理VS敏捷项目管理对比-各模式的发展历程
