极限编程和客户端
什么类型的客户端可能支持 XP（极限编程）实践？
What type of client is likely to support XP (Extreme Programming) practices?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
什么类型的客户端可能支持 XP（极限编程）实践？
What type of client is likely to support XP (Extreme Programming) practices?
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（6）
我在一家从事敏捷开发的公司工作（严格来说不是 XP，但仍然适用），我们的客户群完全是政府组织。 一旦他们看到敏捷流程在工作中的结果，即使是那些需要以瀑布式方式提供文档的人也非常乐意继续获得敏捷流程的好处。
是的，我同意 vfilby 的观点。 您的客户应该关心结果，而不是您如何实现这些结果。
I'm working for a company which is doing Agile (not strictly XP, but still applicable), and our client base is exclusively government organizations. Once they saw the results of the agile process at work, even those who had requirements to provide documentation in a Waterfall like manner were more than happy to continue to reap the benefits of the agile process.
And, yes, I agree with vfilby. Your customers should care about the results, not how you achieve them.
如果您的团队取得了良好的业绩并拥有良好的业绩记录，那么公司就渴望获得成功的结果。 如果反过来的话，只有盲目徘徊的公司才会感兴趣。
在奇怪的情况下，客户会希望遵循某些做法。 就像经验丰富的开发经理将项目外包给外部公司一样，或者潜在的客户听说 XP 很不错，但对它没有真正的知识或经验。 在前者中，有经验的消费者会知道他想要什么，如果你不提供这些服务，他们就会去其他地方。 如果你试图伪造，他们会知道并且会非常不高兴。 后者，只要取得好成绩，并认为是自己的智慧让自己从地里出来就行了，这并不重要。
不管怎样，结果才是最重要的。
现在开始我的谩骂，到目前为止，我的谩骂已经引起了很多人的愤怒：
你会为了迎合客户而损害你的良好实践吗？ 如果您坚决支持 XP，那就卖掉它吧！ 如果他们希望您使用您强烈不同意的方法。 告诉他们。 如果不能达成共识，就不应该达成协议。
我要告诉面包师使用什么谷物吗？ 烤箱有多热？ 一定不行。 如果我说我想在面包上撒上罂粟籽，我不在乎它们是如何放在那里的，只要它们在那里就行。 Dp 我选择面包师是根据他的方法，还是根据面包的美味程度？ 让一个非程序员告诉你如何做你的手艺简直是糟糕的。
如果您想宣扬 XP 的优点，那么请坦率地宣传成本效益和投资回报率。 向他们展示为什么在提高开发人员效率和减少缺陷方面对他们来说更好。 如果您为非程序员工作，那么您就是专家，掌握主导权并提供建议。
如果您的团队在 XP 方面表现出色并取得了良好的成果，那么向任何潜在客户推销您的实践将毫无问题。 结果对客户很重要； 如果你能证明你能在一致的时间内持续生产出高质量的产品，那么你销售你的方法应该没有问题。 （除了一些绝对需要瀑布的例外）。
If your team achieves great results with a proven track-record, then companies desiring a successful result. If the converse is true, only companies who are wandering blindly will be interested.
There is the odd case where the client will want a certain practices followed. Like a experienced dev manager outsourcing a project to an external firm, or potentially a client who has heard that XP is good in passing but has no real knowledge or experience with it. In the former the experienced consumer will know what he wants and if you do not provide those services they will go elsewhere. If you try to fake it, they will know and be most displeased. The later, it doesn't matter so much as long as they get good results and think it was their own wisdom that brought them forth from the ground.
Either way, it is results that matter.
Now begins my diatribe which so far has inspired much ire:
Would you jeopardize your good practices just to suit a client? If you are staunchly in favour of XP, sell it! If they want you to use a methodology that you strongly disagree with. Tell them that. If you can't come to a consensus, there should be no deal.
Do I tell a baker what grain to use? How hot to have the ovens? Hell no. If I say I want poppy seeds on the buns I don't care how they are put there so long as they are there. Dp I select a baker based on his methods, or on how damn tasty the bread is? Letting a non programmer tell you how to do your craft is just plain bad.
If you are trying to extol the virtues of XP then be upfront, pitch the cost-benefits and ROI. Show them why it is better for them in terms of developer efficiency and defect reduction. If you are working for non-programmers, you are the expert, take the reigns and give advice.
If your team excels at XP and has great results you will have no problem selling any potential client on your practices. Results matter to clients; if you can prove that you consistently produce high quality products within consistent timelines you should have no problem selling your methodology. (with some exceptions that absolutely require waterfall).
这可以说使得这些客户变得稀少:-)
Which arguably makes these clients few and far between :-)
我认为客户接受敏捷开发实践（尤其是 XP）可能比以前更容易说服，因为它们现在更加主流。 过去在敏捷团队中获得过积极体验的客户更有可能接受这些方法。 对于较小的客户或问题较小的客户来说，如果他们有顾虑，可能更容易接受 XP。 对于持怀疑态度的客户，我建议从小事做起，建立信心。 并确保兑现您的承诺！
I think it probably takes less convincing than it used to for customers to accept agile development practices, particularly XP, since they are now much more mainstream. Customers who have had positive experiences with agile teams in the past are more likely to buy into these methods. It's probably easier for a smaller customer, or a customer with a smaller problem to accept XP if they have concerns about it. With a skeptical customer, I would suggest starting small and building confidence. And make sure you deliver on your promises!
几乎其他人似乎都在以您是为客户编写定制软件的 ISV 或为 ISV 工作的背景来解释您的问题。 是这样的情况吗？
如果您的问题类似于什么样的公司可能采用 XP，那么我会说，一家过去曾陷入困境的公司花费太多时间编写开发人员文档并进行重用设计，结果却不得不将其丢弃一切都是浪费时间和精力。
Almost everyone else seems to be interpreting your question in the context that you are or work for an ISV writing custom software for a client. Is that the situation?
If your question had been something along the lines of what kind of company is likely to adopt XP, then I would say a company who has been burned in the past spending too much time writing developer documentation and designing for reuse only to have to throw it all away as a big waste of time and effort.
客户必须接受每次迭代具有固定时间、固定资源、固定质量（100% 工作）和略有变化的范围的迭代交付。
然而，更常见的是他们想要确定时间、资源、质量和范围。
可能支持 XP 实践的客户端类型，
是一位已经了解 XP 提供的软件生产系统的优点和缺点的人。
The customer has to accept iterative delivery with fixed time, fixed resources, fixed quality (it's working to 100%), and a slightly variable scope, per iteration.
However, it is much more usual that they want to fix time, resources, quality AND scope.
The type of client that is likely to support XP practices,
is one that already understands the benefits and drawbacks of the software production system that XP provides.