| « | August 2025 | » | | 日 | 一 | 二 | 三 | 四 | 五 | 六 | | | | | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | | | | | | | |
|
公告 |
| 不得窥道门，不得悟佛门，不得入窄门，实乃破门。 |
| Blog信息 |
|
blog名称:破门点滴
日志总数:161
评论数量:404
留言数量:-2
访问次数:1420488
建立时间:2004年11月13日 |
| |
|  [XP 实践]摘录 XP － 消除业务／IT 团队的隔阂
随笔, 软件技术
破门 发表于 2006/11/17 11:40:54 | | 将企业需求转变成
它实际使用的软件是 IT
世界中最难的问题之一。让技术人员和业务人员进行持续且坦诚的交流是一个令人畏缩的挑战。尽管大多数公司在口头上夸夸其谈，但他们的行为表明他们实际不重
视交流。他们到处设置障碍。信息就无法流通。拉帮结派的斗争使他们偏离了需要完成的工作。人们对于其他组所做的工作一无所知。项目的启动遥遥无期，而为了
似乎永远也不可能达到的目标，这些项目艰难地前进着，而且它们会多次中途夭折。
从人们可以记起的那一刻起，情
况可能就是这样了。行为形成了习惯。业务人员已经习惯技术人员以种种方法向他们说“不”，所以他们开始新项目时，抛出每个可能的功能要求，并要求每件事都
要拥有高优先级，甚至是不需要的时候。技术人员以前也经历过这样的“游戏”。他们知道业务人员实际上并不需要所有那些功能。背地里，他们认为大多数业务人
员都很愚蠢和优柔寡断。他们知道业务人员会设法改变需求（可能在“游戏”的后期），而且他们知道这个“范围蔓延”将削弱按接近于业务人员期望的准时和预算
内交付任何项目的能力。所以他们开始新项目时，就试图限制范围，而且通过限制“范围蔓延”来执行项目。这种情况意味着：
业务人员认为 IT 团队只知道说“不”，而且他们没有得到他们想要的软件。
技术人员感到受侮辱了，而且他们没有生产出他们希望能够生产出的软件。
这个游戏是个问题，但它也是个病症。根本原因是人的本性。技术人员不愿与业务人员交流的真正原因是因为他们通常不想解决业务问题。他们宁愿玩冷冰冰的玩具，而且就技术管理而言，要赢取权利很难。当然并非到处都如此，但很普遍。
业
务人员不愿交流的根本原因是因为他们不愿花额外的精力帮助技术人员把事情做好，而且他们不想对项目结果负责。如果业务人员想要技术人员理解他们真正需要什
么以及为什么，那么他们首先需要自己理解它。他们通常没有这样做。如果业务人员想让技术人员生产“正确的”软件，那么他们需要花些时间与技术人员共同探
讨，以达到共同目的。通常他们不愿意（或被不允许）这样做。大多数业务人员没把这看作他们工作的一部分。
这种内耗使大多数软件项目产生令人不满意的结果就不足为奇了。事实上，我很惊奇的是，在以这种方法进行工作的环境中，
有些项
目实际上还是成功了。那么我们要如何修正呢？除了组织性变革以外不需要进行任何更改。逐步变革不会起作用，虽然我愿意帮助组织设法以这种方式进行变革。这
种变革的主要催化剂是一种根本不同的软件开发方法，它要求并使软件开发团队的业务成员和技术成员合作。我想那就是 XP 的真正意义所在。
回顾我在前面讨论的一个团队的概念。如果您是技术人员，那么您是否通常会把业务人员视为
团队中的一员呢？如果您是业务人员，您是否把自己视为软件开发团队中的一员呢？要让生产软件的方法产生根本变化，我们必须改变人们之间的关系。XP
要求这样做，本专栏以后的一篇文章中将描述的客户实践会使这一点完全清晰。客户要自始至终推动过程。作为程序员，那些客户是我团队中的成员。我们应同心协
力。业务人员同样要愿意推动开发过程。他们要对有关功能的取舍做出艰难的决定。他们需要能及早并经常进行发布，即使当系统未“完成”时，这样团队才能从真
正的用户那里得到具体反馈。他们需要以客户测试的形式，确定何时“完成”某一特定事情。那才是最根本的。
XP 不仅仅是关于编程的。它是关于根本的、改变生活的组织性变革。我相信这是治愈滋生在全体 IT 团队中疾病的唯一良药。 原文更多内容： 《重访“XP 精华”，第 1 部分》 |
|
|
