Java开发网 - 揭开极端编程的神秘面纱：如何成为 XP 客户

Java开发网

您没有登录

» Java开发网 » 技术文章库

打印话题 寄给朋友 订阅主题

作者

揭开极端编程的神秘面纱：如何成为 XP 客户

palatum

CJSDN高级会员

发贴: 451
积分: 80

于 2003-04-15 17:00

揭开极端编程的神秘面纱：如何成为 XP 客户

了解驱动软件项目意味着什么
级别：初级

Roy W. Miller（rmiller@rolemodelsoft.com）
软件开发人员，RoleModel Software, Inc.
2003 年 4 月

在上次的专栏文章中，您了解了让 XP 发挥作用所需要的心态。团队的每个人都必须改变他们的思维方式。本文探讨了为什么客户（业务决策制定者）似乎要在这一转变中经历最困难的时期。除非他们改变思维方式并参与到软件项目中，否则最终结果永远不会令人满意。
Roy 欢迎您提出要讨论的主题或 XP 领域内的其它任何事情。请在关于本文的论坛中与作者和其他读者分享您的想法（您也可以单击本文顶部或底部的“讨论”来访问论坛）。

XP 需要业务人员的思维方式有一个深刻的转变。在过去 30 年的时间里，软件开发方法学已经使企业中非技术人员习惯于按某些方式思考和行动。遗憾的是，传统方法学是错的，因为它们并不总是产生这些人想要的结果：在项目结束时满足其需要的软件、有较长有用期的软件和及时交付的软件。

讨论的是一个很苛刻的要求。令人遗憾的事实是传统软件开发始终不能及时交付。其中的一个主要原因人们可能根本不会想到：客户没有做他们的工作。在我进行说明之前，您需要理解 XP 项目的“客户”有哪些特征。

不可能实现的梦想？
XP 描述了一个美好的情形。客户（或达成一致的一组人）告诉程序员编写什么样的软件。客户标识某种特性并给出为什么这很有必要的理由。理想情况下，客户会量化该特性 — 它的最低要求是什么？尽管量化一种特性并非总是可能的，但却始终是值得一试的目标。如果它是不可能的，不要让这一点阻止您生产优秀的软件，但不要假定它始终都是不可能的。试试看。

软件应该由业务需求来驱动，但通常的情况却是技术人员领导项目。他们构建他们想构建的东西，这通常是因为客户在项目一开始时就擅离职守，或者是程序员在某些时刻放弃与业务人员交谈。为什么会这样？软件开发的历史已经使所有参与的人都习惯以某些方式思考和行动。太多的情况下，结果是失望、窘迫和挫折。

深陷于泰勒制
Frederick W. Taylor（请参阅 10 月份专栏文章的侧栏）在 19 世纪 80 年代是一家机械工厂的工长，在此后超过三十年的时间里他一直在研究工厂生产。他注意到一个最重要的特征：低效。他开始通过寻找做任何工作的“唯一最佳方法”，以及告诉管理人员如何为他们操作的每一环节找到最佳方法的系统，来消除低效。到 20 世纪 50 年代为止，泰勒制（Taylorism）是主要的管理哲学。企业的软件开发在那个十年里首次登场，经营企业的人作出了一个看似不错的假定。他们假定适用于其它生产类型的相同管理原则 — 考虑工作的相同方式 — 也适用于软件。

考虑一下汽车装配线。零件和原料从这一头进去，装配好的汽车从另一头出来。您最不想看到的事是：装配线上的每个人聚在一起决定改为造自行车。装配线上没有机会进行创造。您真正想要的是可预见性 — 您希望装配线每次运行都完全相同。在这一领域，问题与解决方案始终是相同的，而您可以有效地优化该过程。当然，一旦您把事情优化并使其平稳运行，那么“变化”就变成了敌人。即使环境在底层是动态的，人们也会费尽心力地使它看上去可预见。

“效率”的这种模型根本不适合软件。对于软件，问题始终是不同的。它可能类似于您以前看到过的，但决不是相同的。这就意味着解决方案不可能相同。不可能只遵守手册就能获得正确的答案。如果问题不同而且解决方案不同，那么您不必考虑优化。它根本就不存在。变化是不断的。

在某种程度上，您可以说软件开发团队（对于内部或外部用户）受困于装配线式的思维方式。泰勒制给企业文化打下了深深的烙印。担当软件项目客户的人通常是管理用户群的人，或者本身就是用户。如果他们管理用户，那他们就是经理。如果他们本身就是用户，那他们就处于由经理们控制的环境中。无论哪种情况，装配线式思维方式都是标准。

参与软件开发的业务人员已经开始相信他们的角色主要是前端的：他们在开发周期的早期为程序员指定一组详尽且不变的需求，然后停下来等待结果。当然，他们应该有对过程的控制权。毕竟，他们正为它付出努力，他们正为它提供需求，而且完成的产品必须使他们满意。但业务极少驱动软件。技术人员很快会告诉业务人员软件是“软”的，但同样是这些技术人员却抵制变化，因为变化是痛苦的和代价很高的。程序员不希望没等到软件变得完美就发布它，而业务人员则不希望新软件给用户造成过多破坏，因此双方共同使得发行不及时 — 有时是在项目开始的数年之后才发行。

在这一周期结束时最终得到的并不是企业需要的软件 — 它是企业在项目开始时认为它所需要的。大多数客户都没有兴趣购买这样的“陈年”软件，但这却是他们所得到的。技术人员不希望交付这样的软件，但他们认为自己别无选择。每个人都感到挫折、疲倦、愤怒和上当受骗。

参与创作软件的每个人在这一过程的某些环节都妥协过。或许是为了保住饭碗或使冲突减到最小。或许是因为宿命论悄然涌上心头并在您毫无察觉的情况下影响了您。或许是因为懒惰。无论是什么，每个人都做了一个糟糕的决定。每个人都觉得使事情保持现状好过尝试使事情有所不同。遗憾的是，只有改变才能使事情做得更好。我们需要回到那条路上。出发的最佳地点之一就是客户行为。

学会驱动
软件开发在过去三十年里已经是非常一致。当然，在其发展过程中有过一些改进，但基本主题是相同的：

用户并不真正知道他们想要什么，所以开发人员必须告诉他们以便生产软件。

变化有害，所以应不惜一切代价来禁止它。

禁止变化的方法是在一开始把所有的事情写在纸上，找些人在上面签字核准，然后照这个计划执行。

在一开始就定义所有需求的唯一方法是让业务人员提出一组需求，在末期试用完成的产品以确认每样事情都和这些需求一致，而在中期则置身事外。
结果是大多数软件项目生产（如果它们确实生产了某些东西）的是某个人在开始时认为他想要的软件，而不是软件用户在末期最终想要的。我们最终得到的是我们根本不想要的东西，但似乎没有办法能走出这个怪圈。管理人员不能只是规定变化。这在过去从未奏效，将来也不会。为什么我们会深陷于此，我们该做些什么？

首先，身为 XP 客户的人需要起到客户的作用。什么人能成为客户？通常是具有足够领域和最终用户知识、能对特性的优先级作出困难决定的人。他可能是了解用户真正需要的超级用户。他可能是了解市场需求和竞争对手情况的市场销售人员。他一般不会是顺理成章就获得这一职位的经理，尽管这也许总比没有客户要好。必须有人接受该职位并承诺做好这项工作。

第二，任何接受客户职位的人都必须把自己当作团队的一份子。他必须愿意花必要的时间和团队其他成员一起生产正确的软件。客户不能预先说明需求后就离开，若软件失败则依靠难以自圆其说的推诿伎俩来为自己掩护。客户不能在团队其他人叫他离开叫他不要制造麻烦时勉强同意。他不是在制造麻烦；他是在为团队指明方向。

第三，客户必须暂时把怀疑放到一旁，尽力表现得好象让团队探索生产最终产品的方法会比预先规定每一项事情取得更好的结果。这对于程序员和客户都很难。程序员希望不被方法的每一步所困扰就能生产出优秀的软件。他们认为预先说明每项事情并且不背离规范就能确保这一点。客户也担心。他们希望写进每一个可能的需求（包括他们并不真正需要的需求），以便在不得不放弃时给自己留有更多商议的余地。这些观点没有一条有助于团队生产优秀软件。客户需要说明软件真正需要什么，什么是最重要的。然后，他们必须相信程序员（是的，很难做到的一件事）会朝着那个目标坚持不懈地工作。当然，程序员必须通过言出必行来赢得更多信任。这对每个人都有风险，但却是做事的典型方法。采用 XP，风险是显而易见的，而不是被成堆的纸张和承诺所隐藏。

第四，客户必须改变他们考虑软件的方式。如何才能知道真正需要什么软件？我只知道两种方法：猜测并指望猜对，或者一点一点地交付软件并在更好地理解了客户的真正需要时对软件进行调整。花大量时间让人们讨论他们需要的软件而不实际使用软件只是第一种方法的翻版。人就是人。让他们使用计算机并不能改变这一点。真正理解需求的唯一方法是有一个运行的示例，两方的团队成员都可以用它找到共同点：“这里，看到这个了吗？那根本就不是我想要的。那个东西的位置真是糟透了，非常碍事！那里可以更好些。不过这个，这个真是太好了。”反馈是非常重要的，所以团队应及早且经常地发表反馈。坐等软件变得“完美”只会推迟您猜错的坏消息。

如果这就是客户所要做的全部，那有什么问题？事情不止那么简单。事实上，它太难了，以至于大多数人都不愿做它。即使他们愿意做，也不能做。大多数组织在建立时都不允许这样的过程发生。使用 XP 制作软件会遇到强大的抵制，因为一些有权利的人对于这是否明智有正统的考虑 — 并且因为一些有权利的人很顽固。

组织可能成为问题
如果 XP 客户所在的组织不同意使用 XP，那么他不能做他的工作。这意味着两件事情：

必须存在 XP 团队以便将客户包括在内。
客户的上司必须让客户成为该团队的一部分。
团队必须在 XP 客户能够做他的工作之前就在使用 XP。如果团队在假装使用 XP，或限制客户充当那一角色的能力，则 XP 不会起作用。遗憾的是，大多数组织的建立机制与 XP 是对立的，这种对立或是有意识的或是自然形成的。除非组织中至少有一小部分愿意尝试 XP，否则它不会起作用。但您可以从小做起。一位客户，几个开发人员和一个小小的应用程序就是您需要的全部。如果那个团队生产出优秀的产品，则有可能其他团队将采取一些那样的行为。

如果 XP 团队需要某位客户，而该预期客户的上司却不允许他在该团队上花任何时间，那会怎么样？那样的话，这个项目从一开始就注定要失败。如果团队需要客户参与计划会议或试用最新的应用程序，但该客户却始终忙于填写 A-324-XYZ 报告以应付即将到来的每两周一次的形势通告会，那么该团队将不能交付他们所承诺的东西。没有某位相似领域的专家，您就无法有效地研究，而那位专家就是客户。组织中控制客户时间的人必须放弃部分要求。

大多数组织的建立机制使这几乎不可能。那么我们就永远深陷下去吗？也许，但我不认为我们必须如此。改变这种情形只需要勇气。

进行改变的勇气
坦率地讲，我认为有三个原因共同促使公司的 IT 人员陷入这个怪圈：

习惯
懦弱
缺乏远见
打破习惯是很难的。您甚至没有考虑过这么做。习惯是您生活中很自然的一部分，即使某些清醒的情况下您知道不应那样行事。这就是为什么人们会抽烟、暴食或对着他们的孩子大喊大叫。一旦您有了某种习惯，打破它就需要有意识的努力。大多数公司生产软件的方法直接来源于该公司各成员的习惯。

有些公司的很多人都没有胆量。当事情真正有麻烦，并且他们真正意识到组织走向了错误方向时，他们要么屈服要么走人。此刻，如果留在某个组织中的日子确实很糟糕，而且您尽了最大努力也无法改善它，那就可能是离开的时候了，对于这种情况，我将第一个赞成。但一看到阻力就逃跑并不是解决问题的办法。您是在逃避必然性。您跑到别的某个地方，在那里相似的问题突然再次出现，而您又会离开那个新地方。组织不会改变有什么奇怪呢？每个人都跑开而使它们支离破碎。

我们需要的是新一代的公司领导（既有技术型也有非技术型），他们将站起来说真话 — 即使要面对传统和习惯。缓和与退却的战略根本不起作用。非技术型领导必须担当 XP 团队的客户，并且如有必要应该用全部时间参与。技术型领导必须愿意放弃控制规范的权利，并探索制作优秀软件的方法。

我们需要更多勇敢的人，但光有勇气没有远见也不能成事。对理想的状况有远见并有勇气尝试达到那一状况，我们需要的是这样的人。在真正的 XP 方式中，这种远见在我们朝向它前进时会改变，但我们必须前进。

软件开发让人痛苦而产品成为垃圾，这是因为您我允许它这样。这是我们的过失。责备“那些人”或“那个组织”起不了任何作用，只会无限期延长这一循环。我们需要痛定思痛，要求变革，并首先自己做好表率。做到那一点非常困难。最后，一言以蔽之：您是希望混日子领工资，还是希望改变世界？

作者

Demystifying Extreme Programming: How to be an XP customer [Re:palatum]

palatum

CJSDN高级会员

发贴: 451
积分: 80

于 2003-04-15 17:01

Demystifying Extreme Programming: How to be an XP customer

Learning what it means to drive a software project
Level: Introductory

Roy W. Miller (rmiller@rolemodelsoft.com)
Software Developer, RoleModel Software, Inc.
December 2002

Last month, you learned about the mindset required for XP to work. Everyone on the team must change the way they think. This article explores why customers (the business decision-makers) seem to have the most difficult time with this shift. Until they change the way they think about and participate in software projects, the end result will never be a satisfactory one.
Roy welcomes your input on topics to cover or anything else within the realm of XP. Share your thoughts with him and other readers in the discussion forum on this article. (You can also click Discuss at the top or bottom of the article to access the forum.)

XP requires a profound shift in the way business people think. Over the past 30 years, software development methodologies have conditioned non-technical people in business to think and behave in certain ways. Unfortunately, traditional methodologies are wrong because they doesn't consistently produce the results these people want: software that meets their needs at the end of a project, software that has a long useful life, and software that gets delivered often.

Talk about a tall order. The sad truth is that traditional software development has consistently not delivered. One of the primary reasons is probably one of the least expected: customers haven't done their job. Before I explain, you need to understand what "the customer" for an XP project looks like.

The impossible dream?
XP tells a nice tale. The customer (or group of people speaking in agreement) tells the programmers what software to write. The customer identifies a feature and provides a reason why it is necessary. Ideally, the customer quantifies the feature -- what does it mean for the bottom line? While quantifying a feature isn't always possible, it's always a worthwhile goal. If it isn't possible, don't let that stop you from making great software, but don't assume it's always impossible. Try and see.

Business need should drive software, but more often than not, it's the technical people who lead the project. They build what they want to build, usually because customers go AWOL once the project starts, or the programmers give up talking to business people at some point. Why does this happen? The history of software development has conditioned everybody involved to think and behave in certain ways. Far too frequently, the result is disappointment, embarrassment, and frustration.

Stuck on Taylorism
Frederick W. Taylor (see the sidebar from the October installment) was a machine shop foreman in the 1880s, and ended up studying factory production for over thirty years. He noticed one overriding characteristic: inefficiency. He set out to kill it by finding "the one best way" to do any job, and a system for telling managers how to find that way for every segment of their operations. By the 1950s, Taylorism was the primary management philosophy. Software development for business made its debut in that decade, and people running businesses made what looked like a good assumption. They assumed the same management principles -- the same way of thinking about work -- that applied to other kinds of production also applied to software.

Think about an automobile assembly line for a minute. Parts and raw material come in one end and finished cars come out the other. The last thing you want is for everybody on the line to get together and decide to build bicycles instead. There isn't any room for creativity on an assembly line. What you really want is predictability -- you want the line to run exactly the same every time. In this world, the problem and the solution are always the same, and you can effectively optimize the process. Of course, once you've got things optimized and running smoothly, change becomes the enemy. Even if the environment is dynamic underneath, people go to great pains to make it look predictable.

This model of "efficiency" couldn't be a worse fit for software. With software, the problem is always different. It may be similar to ones you've seen before, but it's never the same. That means the solution can't be the same. You can't just follow a manual to get the right answer. And if the problem's different and the solution's different, you can forget optimization. It just doesn't exist. Change is constant.

In a way, you could say software development teams (for internal or external users) are locked into assembly-line thinking. Taylorism is etched deeply in corporate culture. The people who act as customers for software projects are usually people in charge of groups of users, or are users themselves. If they're in charge of users, they're managers. If they're users themselves, they exist in an environment controlled by managers. In either case, assembly-line thinking is the norm.

Business people involved with software development have come to believe that their role is mostly a front-end one: they specify an exhaustive, unchanging set of requirements for the programmers early in the development cycle, then sit back and wait for the results. Of course, they should have control over the process. After all, they're paying for it, they're providing the requirements for it, and they're the ones who must be satisfied with the finished product. But the business rarely drives software. Technical people are quick to tell business people that software is "soft," but then these same technical people fight change, because it's painful and expensive. Programmers don't want to release software until it's perfect, and business people don't want the new software to be too disruptive for the users, so the two cooperate to release infrequently -- sometimes years after the project starts.

What you wind up with at the end of this cycle is software that isn't what the business needs -- it's what the business thought it needed when the project started. Most customers are not interested in buying such "vintage" software, but it's what they get. Technical people don't like to deliver software like this, but they believe they have no choice. Everybody feels frustrated, tired, angry, and short-changed.

Somewhere along the line, each person involved with creating software compromised. Maybe it was to keep a job or to minimize conflict. Maybe it was because fatalism crept up and attacked in the dark. Maybe it was laziness. Whatever it was, each person made a bad bargain. Each person decided that having things as they are was better than trying to make things different. Unfortunately, the road to better goes right through different. We need to get back on that road. One of the best places to start is with customer behavior.

Learning to drive
Software development has been remarkably consistent over the past thirty years. There have been refinements along the way, of course, but the basic themes are the same:

Users don't really know what they want, so developers have to tell them in order to produce anything.

Change hurts, so we should suppress it almost at all costs.

The way to suppress change is to write down everything at the beginning, get somebody to sign off on it, then stick to the plan.

The only way to define all the requirements at the beginning is to have business people commit to a set of requirements, try the finished product at the end to confirm that everything's consistent with those requirements, and stay out of the way in the middle.
The result is that most software projects produce (if they produce anything at all) the software that somebody thought he wanted at the beginning, rather than the software users end up wanting at the end. We end up with exactly what we don't want, but there doesn't seem to be a way out of the rut. Folks in charge can't just dictate change. That has never worked in the past and never will. Why are we stuck here and what do we do about it?

First and foremost, people who are equipped to be XP customers need to start acting the part. Who can be a customer? Usually it's somebody with enough domain and end-user knowledge to be able to make the tough decisions about the priority of features. This could be a super-user who knows what users really need and want. It could be a marketing person who knows what the market is asking for and what competitors are doing. Rarely can it be a manager who gets the job by default, although that's probably better than no customer at all. Somebody has to take the job and commit to doing it.

Second, whoever takes the customer job has to see himself as part of the team. He has to be willing to spend as much time with the rest of the team as necessary to produce the right software. The customer can't specify requirements up front and then disappear, counting on plausible deniability to cover for himself if the software ends up a bomb. And the customer can't acquiesce when other people on the team tell him to go away and stop making trouble. He's not making trouble; he's giving the team direction.

Third, customers have to suspend disbelief and try to behave as if having the team explore its way to the final product will yield better results than specifying everything up front. This is hard for programmers and for customers. Programmers want to make great software without being hassled every step of the way. They think specifying everything up front and not deviating from the spec will ensure this. Customers are afraid, too. They want to throw in every possible requirement, including ones they don't really need, to give themselves more negotiating room when they have to give things up. Neither of these perspectives helps the team make great software. Customers need to say what the software really needs, and what is most important. Then they have to trust the programmers (yes, a hard thing to do) to work diligently toward that. Programmers, of course, have to earn more trust by doing what they said they would do. This is risky for everybody, but so is the typical way of doing things. With XP, though, the risk is obvious, instead of being hidden by mounds of paper and promises.

Fourth, customers have to change the way they think about software. How do you know what software you really need? There are only two approaches I know of: guess and hope you're right, or deliver the software in small bits and make adjustments as you get a better understanding of what the customer really needs. Spending lots of time having people talk about the software they need without actually using any software is just another version of the first approach. People are people. Having them use computers doesn't change that. The only way really to understand the requirements is to have a working example that both team members can use to find common ground: "See this here? That's not what I meant at all. That's really in a bad place because it gets in the way. It would be better over there. But this, this is perfect." Feedback is king, so the team should be releasing early and often. Waiting until the software is "perfect" only delays the bad news that you guessed wrong.

If this is all customers have to do, what's the problem? It's just not that easy. In fact, it's so difficult that most people have no desire to do it. Even if they do, they can't. Most organizations aren't set up to allow this process to happen. There is huge resistance to using XP to make software, because some powerful people have legitimate concerns about whether it's sensible -- and because some powerful people are stubborn.

The organization might be the problem
An XP customer can't do the job if the organization he's part of doesn't make it possible. This means two things:

An XP team must exist for the customer to be included.
The customer's boss has to let the customer be part of that team.
Teams have to be using XP before an XP customer can do the job. If a team is pretending to use XP, or restricts the customer's ability to fill that role, it won't work. Unfortunately, most organizations are set up to oppose XP, either actively or by default. Unless at least a small part of an organization is ready to try XP, it won't fly. But you can start small. One customer, a few developers, and a smallish app is all you need. If that team produces great results, there is a chance other teams will want some of that action.

What if there's an XP team shopping for a customer, but the prospective customer's boss won't allow that person to spend any time with the team? Then the project is doomed at the start. If the team needs the customer for a planning session or to play with the latest app, but the customer is always busy filling out report A-324-XYZ for the upcoming bi-weekly status meeting, the team won't be able to deliver what they promised. You can't explore effectively without somebody who is an expert at similar terrain -- that's the customer. People in the organization who control that customer's time have to give up some of their claims.

Most organizations are set up to make this nearly impossible. So are we stuck forever? Maybe, but I don't think we have to be. Changing the situation simply takes courage.

The courage to change
To be blunt, I believe there are three reasons corporate IT is stuck in a rut:

Habit
Cowardice
Lack of vision
Habits are hard to break. You don't even think about doing them. They're a natural part of your life, even if at some conscious level you know you shouldn't behave that way. This is why people smoke, or overeat, or scream at their kids. Once you have a habit, breaking it requires conscious effort. The way most corporations make software comes directly from the habits of the people who compose that organization.

A good number of people in corporations are gutless. When something really matters, and they really think the organization is headed in the wrong direction, they either cave in or they flee. Now, I'll be the first to agree that if life in an organization gets bad enough, and you can't improve it despite your best efforts, it's probably time to go. But running away at the first sign of resistance is not a solution. You're running from the inevitable. You'll go somewhere else where similar problems will crop up again, and you'll leave that new place too. Is it any wonder organizations don't change? Everybody runs away and leaves them broken.

What we need is a new generation of corporate leaders, both technical and non-technical, who will stand up and speak the truth -- even when it flies in the face of tradition and habit. The strategy of appeasement and retreat simply doesn't work. The non-technical leaders must act as customers for XP teams and participate full time if necessary. The technical leaders must be willing to give up the power to control the spec and explore their way to great software.

We need more brave people, but bravery without vision isn't worth much. We need people who have a vision of what could be and the courage to try to get there. In true XP fashion, the vision will change as we move toward it, but we have to move.

Software development hurts and produces junk because you and I allow it to. It's our fault. Blaming "those people" or "the organization" does nothing except perpetuate the cycle. We need to cry foul, require change, and start leading the charge ourselves. Doing that is difficult. In the end, it comes down to one thing: do you want to skate through life and collect your paycheck, or do you want to change the world?

已读帖子

新的帖子

被删除的帖子