极限编程是关于放弃羁绊尽力而为绽放自我
2019-12-20
来源： 真北敏捷 Kent Beck
的时候，通常已经有人知道了解决方法，但有权做出改变的人却不知道。当忽视自己直觉的时候，即使是我一个人也会出现这种问题。人们之间的沟通的情况则更加复杂。
一旦你发现了一个令人惊异的问题，沟通会帮助你解决它。你可以向过去碰到过类似问题的人打听。你们可以作为一个团队讨论如何避免问题的再次发生。
每当你遇到一个问题，首先问自己这个问题是不是由于缺乏沟通引起的，你需要什么样的沟通来解决该问题？需要什么样的沟通来使你以后避免这样的麻烦？
沟通对于创造团队意识和高效合作意识是很重要的。虽然沟通并不能给予你高效软件开发所需要的全部。
简单
简单是XP价值观中智力色彩最强烈的。构造一个优雅地解决今天问题同时又足够简单的系统是很难的。昨天的简单解决方案在今天看来可能仍然不错，但也可能过于简单了，或者太复杂了。当你需要做出改变，以重新获得简单性时，你必须找到一条从你当前位置到目的地的路径。
我请人们思考这样一个问题：什么是最简单而又可能有效的？批评家通常会忽略了这个问题的后半部分：“嗯，我们的系统不能简化，因为它有严重的安全和可靠性约束。”我并不是要你思考过于简单而无效的东西，只是要求调整你的思想以消除多余的复杂部分。如果安全上的考虑导致本来只需使用一个处理器就可以解决的问题必须分成两个处理器来解决的话，那么对我而言，结果仍然可以是简单的。更好的解决方案仅仅在于你能否找到一种在单个处理器上处理安全问题的方法。
简单的意义与具体的环境相关。如果我正在和一个懂得解析器生成器的团队一起编写解析器，那么使用解析器生成器就是简单的。如果团队中没有人知道如何解析，并且要解析的语言也很简单的话，使用自顶向下的递归解析器将会更简单。
价值观之间是相互平衡和相互支持的。加强沟通能够去除那些不需要的或者可暂缓的需求，从而达到简单化。同时，力求简单化会使你大大减少沟通的内容。
反馈
没有哪个固定方向是长久有效的，不论我们在谈论软件开发细节、系统需求还是系统架构。超越经验而确定出来的方向，它的半衰期尤其短。变化是不可能避免的，变化产生了对反馈的需要。
“从一开始就选择正确的做法，不是更容易嘛？”——当然可以，除了三件事情：
我们可能不知道“正确”的做法是什么。如果我们正在解决一个全新的问题，也许有几种有效的解决方案，也许根本没有明确的解决方案。
今天正确的东西明天可能就是错误的。在我们控制之外的或没有能力预测的变化很容易就会使昨天的决定失效。
今天按照“正确”的做法去做每一件事，可能需要太长时间，以至于还没有完成之前，明天环境的变化就使之失效了。
我们不断改进，并不期望可以马上做到完美，我们使用反馈来一步步地接近我们的目标。反馈有很多种形式：
你和你队友关于某个想法的观点；
当你实现一个想法时，代码会是什么样的；
测试是否容易编写；
测试能否运行；
一旦该想法被部署，它运转得如何。
XP团队致力于在尽可能快的情况下产生尽可能多的反馈。尽量将反馈的周期缩短为分钟或小时，而不是星期或月。知道得越早，你就可以调整得越早。
可能会出现太多反馈。如果团队正在忽略重要的反馈，则需要暂缓下来（这可能会让人失去信心），直到响应了重要的反馈，团队才可以处理那些导致过多反馈的潜
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
