书评--规划极致软件制程(Planning Extreme Programming)
Posted on 2007-12-17 10:16 csdnexpert 阅读(161) 评论(0) 编辑 收藏 举报@小标:补鞋匠的孩子没鞋穿
英谚有云:补鞋匠的孩子没鞋穿(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 开宗明义的「客户导向」,一切就显得理所当然。否则,若由技术人员决定日期、范围、和顺序,整个软件开发就变成「制造导向」了。
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1001009