活用XP:发挥过程和人的力量
过程
前一段时间,书店中很畅销的书大多数都和6σ相关。6σ是全面质量管理理论的发展。其中一个很重要,和软件开发非常类似的思路是,过程的每一个步骤,都会对产品最后的质量产生影响,要提高质量,降低成本,提升客户的满意度,最关键的是要对过程进行研究和分析,发现对产品影响较大的步骤,并制定改进的措施。
| 一家专门提供外卖的公司,常常被客户投诉说送货的时间太慢了。于是他们加强了送货的力量,包括使用更好的工具,雇佣更多的送货人员。但是成本增加了,客户的投诉依然不断。问题出在了哪里?在对整个流程进行了量化评估之后,他们发现,送货的时间对整个的时间影响很小,而更多的时间是花费在了制作外卖的过程中。所以,原先投入对送货流程改进的投资,算是白费了。 |
做任何一件事情,都需要经历一个过程。从外卖店接到客户的订货电话开始,一个过程就已经启动了。记录客户的地址、地址特征、菜名,给厨房下单,分配外送人员,将地址信息传递给外送人员,送货,寻找目的地,交付外卖并收款,后续过程忽略。一个似乎平常的生活活动,其背后都包含了复杂的过程。对软件开发而言也是一样的。从客户提出软件的构想,一直到客户真正开始使用软件,其间的过程非常的复杂,充满了各种各样的不可预测的因素。
送外卖的过程,每一步都会对最终的质量(客户满意度)产生影响。对客户来说,从打电话到收到外卖的时间,外卖的好吃程度,这些都是属于满意度的组成成分。接到电话后,可能客户的口音较重,记录员听错了地址,导致后续过程全部白费,除非客户等的不耐烦,打电话来重新记录一次地址。下单给厨房之后,可能厨房的电风扇会将单子吹到了地上,客户的要求就被忽略了。记录员把客户的地址描述信息写的很潦草,送货人员可能看不懂,这时候他需要打电话回来问,这就担搁了送货时间。送货人员可能对客户所在不熟悉,找到地址花费了很多的时间。好不容易送到了客户手上,客户已经等的不耐烦了,更糟的是,由于时间太长,外卖已经凉了。客户决定,下一次更换一家外卖店。虽然每一个环节出错的概率都不是很大,但是各个环节组合起来之后,出错的概率就大的惊人。在分析了这样一个流程之后,我们的感慨往往是,居然能够送到,真是不容易!软件开发的过程难道不是这样吗?每一个环节都有可能出问题,需求未必就代表了客户的需要,设计不能够很好的代表需求,反而对编码增加了一些不稳定的因素,由于进度较紧,编码的工作也比较马虎。这样的过程,我们能够开发出客户满意的软件,那么只有一个解释,以前客户接触的软件开发人员,比我们还要烂。
好吧,我们如何改善这一情况呢?对了,对过程进行改进。既然记录员可能会和客户之间出现错配的情况,那我们就要求记录员在听完客户的要求之后,重复一遍。既然,菜单可能会遗失,我们就在厨房中专门设计一个位置,按先进先出的顺序排列这些菜单,而且保证菜单不会被遗失。既然送货员可能会看不懂记录员的字,那么就让送货员和记录员花费一些时间沟通,要么送货员能够习惯记录员的字,要么记录员写出送货员能够理解的字。既然送货员可能未必认识路,那么就对送货员划片,有专门送A区的,有专门送B区的,每个人熟悉的范围减小了,熟悉的程度自然就上升了。好吧,有了这样的思想,我们也准备对软件过程进行改进了。不过,并不是现在,本文的剩余部分将会围绕着这一点来进行。
过程中的人
除了过程的重要性,我们还需要考虑人的因素,过程是要依靠人去推动的,没有人,过程就没有任何意义。对软件开发更是如此,开发过程的每一个环节都需要人的参与。从来没有一个方法论象XP这样充分的强调人的作用。因此,在XP的全过程中,人的因素是始终处于首位的。而XP的实践也是根据人的优点和弱点进行精心的设计。我们这里做一些简单的讨论:
计划游戏:我们常常挂在嘴边的一句话是计划赶不上变化。计划,往往都是很多软件组织的一块心病。所有人都知道计划的重要性,可是计划又是最难做的。没有计划,软件过程无从遵循;有了计划,软件过程又常常偏离计划。在变化越来越频繁的现在,计划更是难上加难。对待捉摸不定的计划,XP的态度是:与其在一开始就费时耗力地制定一堆不切实际的计划,倒不如花费少量的精力做一个简单的计划,然后在随后的软件过程中不断的进行调整。
这就好像我们骑自行车,设定一个500米外的目标,然后我们把车把固定住,选取好起点,并预先制定好角度和标准路线,然后骑着车子,严格的按照原定路线前进。车子能到终点吗?可能性不大,设定好的标准路线上可能会有障碍物,这是你原先没有想到的;由于无法调节方向来保持平衡,车子可能会摔倒。
车子,应该这样骑。看看远处的目标,估算距离和时间,得出一个粗糙的速度,然后我们就上路了。在前进的过程中,我们不断的目测目标,察看时间,并调整速度和方向。目标越来越接近,我们的调整越来越熟练,最后,我们成功的抵达的目标点。
传统的计划方法和第一种骑车方法一样不切实际,花费大量的时间思考几个月后发生的事情是很难的。只有根据变化不断的调整,才是正确的态度。
注意,不把时间花费在计划上,并不等于不重视计划。计划仍然是软件开发的核心。你必须有一个当前的迭代计划,当前的周计划,甚至当前的计划。只有保证每一个小计划的严谨性,才能够保证整个项目计划的成功。
XP对计划的态度是:你不需要把计划做的多么精密,但是你必须去做计划。计划赶不上变化,这句话说的一点都没错,我们不需要逃避变化,花大力气进行精确的计划既浪费,又没有意义。但是这并不是说不做计划。凡事预则立,我们需要简单明了的计划,然后在软件开发的过程中,不断的修正并完善计划。
学习变化:XP最适合那些需求容易发生变化的过程,在现实中,我们发现这种情况实在是太多了。可能软件的目标市场发生了变化,要求软件同步变化;可能客户对需求没有充分的了解,导致需求的变化;可能客户的组织或业务流程发生了改变,要求软件变化。种种的可能性表示,在一个一成不变的环境下开发软件已经称为一种奢望。在这样一个残酷的环境中,我们不得不去学习变化。
变化包括两个方面:软件过程如何适应变化,以及软件设计如何适应变化。传统的软件过程往往要求上游的软件阶段确定之后,才能够进行下一个软件阶段。但是变化的需要要求软件过程在多个软件阶段之间切换。
由于变化的残酷性,XP建议开发人员必须建立变化的意识。你必须去改变你的心态,接受变化,变化是合理的,一成不变的东西压根就不存在。
这里插一句题外话。强烈建议在XP的项目中使用面向对象技术。虽然面向对象并没有对软件过程或是软件管理提出任何的要求。但是,一个使用面向对象的团队(注意,是使用面向对象技术,而不是使用面向对象语言,这么说是因为有着大量的开发人员使用面向对象的编程语言编码面向过程式的代码),其管理过程也会随之变化。用户参与、迭代开发、重用、使用框架。这些都是在使用了面向对象技术之后自然而然出现的变化。使用面向对象技术,能够和XP方法进行更加紧密的衔接。
除了上面讨论的两个简单的思路,本文的其它部分都会针对XP中过程和人两方面的因素进行讨论。