书评--规划极致软件制程(Planning Extreme Programming)
＠小标：补鞋匠的孩子没鞋穿
英谚有云：补鞋匠的孩子没鞋穿(Cobbler’s children go shoeless)，用在软件从业人员身上还真贴切J。我们专门帮各行各业自动化，提升工作质量，增加项目效率。但自身如何建构一个可控管，有效率、高质量的软件开发流程却一直是个令人头大的问题。
由于软件项目的重复性较低，不管是客户需求、使用技术、团队成员养成、项目成本等面向，在两个案子间都存在着极大差异。一般在其它工程界，如制造、建筑等，行之有年而较成熟的项目管理理论拿到软件界来，通常都难以适用。
软件工程的大师们一直在找寻着能降低软件项目不确定性的方法。例如分析设计上的结构化、对象导向，软件生命周期的瀑布模型或漩涡式开发，乃至于整体流程的CMMI 或 Agile。然而，我们大多数依然活在经费超支、时程延宕、软件质量不稳，功能不足的梦靥中。
就笔者观察，在周遭的工作环境中存在一个有趣的现象，非软件相关科系的从业人员多过正规教育出身的人。不知其它工程，例如建筑、制造、塑化、生技…等领域是否也如此。但就自身的感觉，我们这些黑手出身的，在进入到工作岗位上，一开始想的都是如何写程序帮使用者立刻解决眼前的问题。不会深思所写出来的东西是否经得起时间锤炼，我们不会长考成员们如何合作，仅以最会写程序的人当意见领袖。总要项目陷入困顿后，才抬起头来找寻出路。
笔者游走于各大企业，与各产业内的工程师交换着黑手技术的经验，这些跨国大企业，大金融集团，通讯、制造、医疗…等龙头，它们的事业都是如此的成功，但其内的 IT 状况却是差不多的。这种存在既合理的实质现象，总让笔者迷惑。仅针对企业体内的软件开发团队与使用者而言，「能用」的弹性真大。
＠小标：敏捷开发与极致软件制程
就笔者自身的感觉，当下最负盛名，也较适合企业内项目开发的精神是敏捷开发(Agile)[1]。
它的发展史如下：2001年2月，在美国犹他州的一个滑雪场，17位软件开发方法论的专家，包括Kent Beck、Martine Fowler (其方法论为 Extreme Programming)、Alistair Cockburn(其方法论为 Crystal Methodologies)、Jim Highsmith(其方法论为 Adaptive Software Development)…等等，共同发布了「敏捷开发宣言The Manifesto for Agile Software Development」。你可以在 http://www.agilemanifesto.org/ 网站上看到宣言的全文，笔者妄加翻译如下：
l 开发者以及彼此的互动重于流程和工具(Individuals and interactions over processes and tools)
l 做软件重于细致文件(Working software over comprehensive documentation)
l 客户参与开发重于订约(Customer collaboration over contract negotiation)
l 应变重于墨守成规(Responding to change over following a plan)
在上述敏捷开发宣言下，有着诸多的方法论，其中极致软件制程 XP(Extreme Programming)最为著名且完整，其核心强调四大价值：沟通(communication)，简单(simplicity)，回馈(feedback)和勇气(courage)。并针对软件生命周期中的设计、测试、开发、上线等环节提出十多种做法建议(practice)。
XP 的特色在于由下而上(value up)快速循环，一般建议以两周左右为一个单位，迅速做一次设计、测试、开发、达交的动作，而后检讨修正，再开始下一个进度单位。在客户与使用者的参与下，一次次地修正，直到达目的地为止。
与其它 Agile 精神下的方法论相比，XP较强调测试的重要性，每个开发人员不仅要写程序代码，同时也必须写相应的测试案例(test case)程序代码。经由持续的构建和集成(Continuous Build & Integration)。并在一次次的递归周期中，完成局部的产品功能。每次周期结束时，搭配重构(Refactoring)的规则，修正不好的程序代码，再通过先前累积的测试案例后，进入下一阶段递归，以此为下一步的开发提供了较稳定的基础。
如同 Martin Fowler在其文章“The New Methodology”中强调：「敏捷强调修正，而非预测。重量级方法花费大量的人力物力，试图制订详细计划来指导长期的工作。而一旦发生变化，计划就不再适用。因此本质上，重量级方法是抵制变化的。而敏捷方法则强调适应变化。其次，敏捷方法以人为中心，而非以流程为中心。敏捷方法强调顺乎本性(work with people’s nature)，软件开发应带来乐趣。」
在此介绍一本关于 XP 的好书：规划极致软件制程(Planning Extreme Programming)，此书两位作者在软件开发流程的方法论界极富盛名，也就是前面提到的 Agile 宣言发起者 Kent Beck 和 Martin Fowler。在本书中，他们风趣幽默地将理念纳于短文中。书虽小，但富含智慧。笔者在此列举书中一些有趣的观点：
l 我们将开发软件比喻为开车，开车并非让车子朝向一个方向前进并保持它即可，开车必须进行许多微小的路线修正[2]。
l 在软件开发计划中，业务决定结案日期(dates)、功能范围(scopes)以及优先级(priority)。技术人员估算(estimates)[3]。
l 顾客必须是开发团队的一部份，这个角色太重要而不能是局外人，假如顾客无法参与，任何 XP 项目将失败…当顾客水平不够，就算拥有世界上最佳的才能、技术与程序，仍终将失败。
l 对顾客而言，XP 最棘手的就是习惯规律的交付(delivery)…顾客必须时时刻刻问自己：「下次拥有什么功能是最有价值的？」
l 加班不是一个好主意...即使程序设计人员愿意加班，也不是一个好主意。长时间的工作会令人感到疲累，疲累的人容易犯错，而错误需要花更长的时间来找寻与修正。
l 软件项目的四个变量中：成本(cost)、质量(quality)、时间(time)和规模(scope)，时间和规模是较好控制的...必须让时间成为可见的。
l 假设明天所能做的，将会和今天实际上已完成的一样多。
l 每日需要简洁的会议...整个会议过程中，每个人都必须站立着，以提醒简短发言。
l 每次递归完成某项功能后，由顾客操作示范与解说，并由顾客将墙上待完成表内之该项目划掉。
l 可信赖的业务或顾客，其人格特质需要：经验(experience)、交际(contacts)、远见(vision)、勇气(courage)。
l 顾客必须做决策，但不必忠于决策，改变心意是他们的权力，但是决策必须由某个基于企业观点的人产生。
＠小标：自己炒得菜，再难吃，自己也会捧场
最近，笔者碰到一个开发模式局部采用 XP 的案子，开发团队 5 人，产出的系统有 600 人使用，共花了 5 个月的时间完成。
开发期间，主事者以一周为单位，当作循环周期。经历了初期的练习后，小组团队较能切割一个星期能达交的工作内容。由于达交时间短，让开发者不能松懈。因为即便两次都展示同样的半成品，也总得交代时间花在什么地方J。
在开发初期，一个星期的递归时间在遇到比较难的技术问题时，可能根本看不到成果，主事者因此取消过一、两次的项目会议，可是团队就松懈下来了。这也验证了本书两位作者强调递归时间固定的重要性。
另外，由于一个星期内，大家专注开发同一功能，因此开发团队的成员可以弹性调度支持。不会有两三个月，大家各自开发专属功能的模块，而其后将无法互相支持的窘境。
过程中，使用者每个星期都参与成果测试，并分析下一个递归的需求。等于使用者本身就是分析、测试人员，由这样的会议交谈，让整个团队对领域知识了解更深刻。也由于参与度足够，且因为开发时间短，所以需要相对修正的内容也会比较少。又因为有多少就给使用者测多少，可以在早期发现错误，就算全部推翻重写，也不过推翻了一、两星期的时间。这次的尝试虽比预估时间晚了一个月才完成系统，但最令人兴奋的是，上线后少有人抱怨。
主事者目前觉得有问题的是时程掌控不易，这不是开发者的问题，而是一直在修正。因为如果有完美主义者参与，他们老觉得这里要加一点那里要加一点L
＠小标：阅读建议
本书轻薄短小，很有敏捷风J，章节很多(27 章)，文字很少。读来轻快有成就感。所以，建议你就一口气读完吧。
@小标：相关阅读
原典与精神总是值得参详的，Kent 和 Martin 各有巨著，本书的作者简介有表列。另外，建议你到以下的网址逛逛：
l http://www.agilemanifesto.org/
l http://www.agilealliance.com/
本书未谈论搭配软件开发实做的产品，笔者就微软 Visual Studio Team System 在此方面的相关资源稍做建议：
l Software Engineering with Microsoft Visual Studio Team System 出版社 Addison Wesley 作者 Sam Guckenheimer。这依然是一本解释 Visual Studio Team System 所为何来的书，因为作者在 Team System 团队中就代表使用者。书中并没有如何操作的步骤，但可让你了解为何 Team System 要实做这些功能。
l MSDN：http://msdn.microsoft.com/vstudio/teamsystem/。当然，微软技术的大本营不可不去J
[1] 就个人感觉，针对系统整合、软件外包，以及百人开发的大型软件产品等领域，Agile 尚需给我们更明确的指引。
[2] 将软件开发比喻成开车是 XP 很传神的论述，但就笔者与开发团队讨论到此点时，会觉得这似乎隐含了软件规模，若软件项目规模如汽车，则转向容易，大家可以约略知道目的地后，就一路修正驶往目的地之方向。
但若规模大到如火车，则似乎需先定好各站的进程规划，一发车后，就很难调整，因为笨重的身躯若随意转向，可能伤害就大了。
[3] 就笔者参与项目的经验，作者所列由业务或企划所决定的三件事，在软件开发中争执已久，不过由 XP 开宗明义的「客户导向」，一切就显得理所当然。否则，若由技术人员决定日期、范围、和顺序，整个软件开发就变成「制造导向」了。