转向敏捷开发方法的最佳案例？
如果您必须向一家企业提出关于采用或转向敏捷开发方法（如 SCRUM 或 XP 等）的案例，您会提出什么案例（您如何推销这个概念）？
例如
编辑：我问的原因是我的一个朋友（他是一家公司的解决方案架构师）目前正在尝试决定如何就这个主题与他的管理层接触，我已经给了他我所能提供的建议。 我特别想听听那些成功地提出转向敏捷方法论的人的意见。
If you had to make a case to a business about adopting or moving to an agile development methodology (like SCRUM or XP etc) what case would you make (how do you sell the concept)?
e.g.
Edit: The reason I ask is that a friend of mine (he is the solution architect at a firm) is currently trying to decide how to approach his management about exactly this topic, and I've given him what I can in terms of suggestions. Curious especially to hear from those who have successfully made a case to move to an agile-aligned methdology.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我的案例：该组织折腾了两年，最终失败了，然后才最终跳上了敏捷的潮流……没有更好的选择（到目前为止……个人观点）来以世界上最快的速度生产高质量的软件变化。 你不能再按照旧的方式做事了。 有些人是通过艰难的方式学习的。
房间里的大象：仅仅因为一个想法好并不意味着它会被接受。
逻辑论证：
我是否突破了字符限制？:)
My Case: The organization thrashed around for a good 2 years and failed before finally jumping onto the agile bandwagon... there is no better alternative (as of now... personal opinion) to produce quality software at the rate at which the world changes. You cannot afford to make things the old way anymore. Some learn the hard way.
Elephant in the room: Just because an idea is good doesn't mean it will be accepted.
Logical Arguments:
Did I break the char limit?:)
非技术人员对按时、在预算范围内完成、质量优良、并且能够满足他们在交付时的要求的项目感兴趣。 您应该关注敏捷如何帮助实现这些品质。
有时很难向非技术人员推销敏捷，原因有二：
谈论敏捷流程处理变化的能力。
如果您与已经与您合作过的客户合作，通常会更容易。 您可以轻松地向它们显示例如一段时间内积累的所有变更请求，并显示它们如何影响项目的进度和成本。 然后，您可以解释敏捷流程如何帮助处理此类案例。
同样，您可以对“瀑布项目”进行初步估计，并将其与现实生活中的结果进行比较。
我还会谈论敏捷的质量方法。 迭代期间的测试大大提高了质量。 带有即时反馈的简短迭代也很有帮助，请提及它们。
Non-technical people are interested in projects done on time and within budget with good quality and which would satisfy their requirements at the time of the delivery. You should focus on how Agile helps to deliver those qualities.
It's sometimes quite difficult to sell Agile to a non-technical person for two reasons:
Talk about Agile process ability to handle changes.
It's usually easier if you work with the customer who already work with you. You could easily show them for example all of the change requests accumulated over the time and show how they affected the schedule and the costs of the project. You could then go into explaining how Agile process will help handling such cases.
Along the same line you could take the initial estimations done on a 'waterfall project' and compare them with real-life results.
I would also talk about the Agile approach to quality. Testing during iterations increase the quality considerably. Short iterations with immediate feedback are great help too, mention them.
卖得好的东西是：
适合小型开发团队，但需要来自以下方面的支持开发团队。
Things that sell it well is:
Great for smallish development teams, but require buy-in from the development team.
如果不具体提及旧方法的问题以及新方法将如何解决这些问题，几乎不可能引入新的方法。
实际上，您可能需要提供一堆选择，然后最后推荐您最喜欢的。 做好准备，充分解释为什么它是您最喜欢的，并充分了解您所选择的方法的弱点。
并确保你不会混淆你的感受的强度和你的论点的强度，并且你不会试图将个人价值选择和文化依恋冒充为客观的技术评估。 您的同事并不愚蠢 - 他们会知道您是否在这样做，并且很快就会对您大加指责。
如果你想从哲学角度理解这一点，沟通实际上并不取决于口才、修辞或表达方式，而是取决于听到信息时的情感背景。 人们只有在走向你时才能听到你的声音，而不是在你的话语追赶他们时才能听到。
It's almost impossible to introduce a new methodology without specifically referring to problems with the old methodology and how the new methodology is going to fix those problems.
In reality, you probably need to offer a bunch of choices, and then end with recommending your favourite. Come prepared with a good explanation of why it is your favourite, and with a really good knowledge of the weaknesses of your chosen methodology.
And make sure that you're not confusing the strength of your feeling for the strength of your argument, and that you're not trying to pass off personal value choices and cultural attachments as objective technical evaluations. Your colleagues aren't stupid - they will know if you're doing this, and they'll quickly flip the bozo bit on you.
If you want to get philosophical about this, communication doesn't actually depend on eloquence, rhetoric, or articulation, but on the emotional context in which the message is being heard. People can only hear you when they are moving towards you, not when your words are pursuing them.
根据我的经验，燃尽图是让非技术管理层立即接受 Scrum 的一件事。 有一个纸质图表——可供所有人查看并易于理解——显示每天的进展，这一想法立即成为赢家。 它很早就清楚地表明项目是否按计划进行。
由于积压工作、冲刺、每日 Scrum 等都是使燃尽图发挥作用所必需的，因此首先推销燃尽图的想法，然后解释 Scrum 其余部分的需要，最后指出执行燃尽图是可行的。该流程试用三周，对进度的影响最小。
In my experience, the one thing that instantly sells Scrum to non-technical management is the burndown chart. The idea that there is a paper chart - available for all to see and readily understand - that shows daily progress is an instant winner. It clearly shows very early on whether a project is on schedule.
Since the backlog, sprints, daily scrum etc are all required to make the burndown chart work, sell the idea of the burndown chart first, then explain there is a need for the rest of Scrum and finally point out that it is viable to perform a three week trial of the process with minimum impact to the schedule.
我认为企业的第一大卖点是他们决定你要做什么，所以他们会设定优先级。
I think the number one selling point to the business is that they decide what you are going to work on, so they will be setting the priorities.
我的嘘声，一个非技术人员，通常更喜欢列出新的方法将如何提高团队的生产力。 因此，我们引入 SCRUM 作为一种管理方法，重点关注进度可见性、更好的沟通方面的收益以及更快的反馈。
事实上，所有其他收益对于像我老板这样的人来说都是无形的。
My boos, a non-technical person, usually prefer to listem about how a new methodology will improve productivity of the team. So, our aproach to introduce SCRUM, as a management methodology, focused on gains at progress visibility, better communication and sooner feedbacks.
All the other gains, as a fact of matters, seens intangible for people like my boss.
从我读到和听到的来看，“敏捷”这个词似乎名声不好，而且让人害怕。 从商业角度来看，我认为归根结底是如何以更具响应性的方式提供商业价值。 敏捷是一种支持快速交付业务价值概念的方法。
我建议您的朋友不要用技术术语来讨论它，而是用业务术语来讨论它，并声明他有一些想法可以帮助更快地向最终客户交付业务价值。
我不建议他讨论 XP 或敏捷作为方法，而是引入简短的、以可交付成果为重点的会议（即 SCRUM），然后尝试从那里发展它。 我觉得，如果你告诉企业，你可以更快、更可预测地得到他们想要的东西，并且你兑现了这一声明，那么你就会获得对实现这一目标的做法的认可。
From what I have read and heard the term Agile seems to get a bad rap and scares people. From a business perspective I think what it boils down to is how can I provide business value in a more responsive way. Agile is a method of supporting the concept of delivering business value quickly.
Instead of discussing it in technical terms I would suggest your friend discuss it in business terms and state that he has some ideas that could help deliver business value to his end customers more quickly.
I would not reccomend he discuss XP or agile as the methods but instead introduce short, deliverable focused meetings (ie SCRUM) and then attempt to grow it from there. I feel if you tell the business that you can get them what they want faster and in a more predictible fashion and you deliver on that statement you will get buy-in to the practices that get you there.