业务需求的灵活性有多大？

Question

我觉得我有时会碰到砖墙。

我正在和我公司的某个人讨论是否需要鼓励我们[公司内部]的客户提前考虑他们的需求并做出更大的努力以确保他们在提供给我的开发团队之前得到修复开始。

反对的论点基本上是“他们付账单，所以他们应该能够根据自己的意愿改变主意”和“他们付钱给我们，所以我们应该做我们所说的”。

虽然我承认并同意客户应该能够改变他们的要求（特别是在使用精益或敏捷方法时），但我也觉得应该有一点（任何！）固定，批准和签署-off要求提供给我的团队。因此，我正在尝试实施一个简化的精益软件开发流程，该流程要求客户在工作之前修复了一系列要求（不一定是所有要求;足以让我的团队在3周的开发和测试迭代中占用）启动。

这允许我：

• 提供更准确的估算
• 计划我的团队资源（我是团队负责人）
• 在TFS中创建工作项（或者如果我使用的是敏捷风格的故事）
• 在开发之前编写单元测试，而不是在开发处于不再发生变化的状态之后编写单元测试
• 在迭代结束时提供报告 - 例如 - 实际工作成本与估算

“他们付钱的论点是，所以只要按照你所说的去做，不要争辩”是合理的吗？如果不是，反对论点是什么？

如果客户（或我的情况下的内部业务代表）持有以下视图：

• 他们并不关心我的团队有多少次重复工作
• 他们不在乎预计的交货日期是否需要搬出
• 他们并不关心所有做法所造成的浪费

我有合理的关注基础吗？

Answer 1

您需要学习一些关于“敏捷”的知识，并且要习惯需求变化的事实。它们意味着要改变，而你的意图是生成满足变化要求的代码。

你永远意味着“完成”。这是一个古老的想法，源于错误的想法，即可以准确地提前了解需求。它有史以来最好的做法是了解特定时间点的所有要求。当然，当这些要求得到实施时，原始要求将随着业务的变化或世界的变化而发生变化。

“完成”是一种幻觉。

Answer 2

Answer 3

是的，“他们付钱”是一个合理的论据。

这也是你最好的（也是唯一的）反驳。增加收入和/或降低开支应该是任何商业人士的核心。

如果你能为自己的利益做出货币案，那么你将有更好的机会。您必须能够量化其决策的一些含义。

您必须希望您实施的任何敏捷实践都会对贵公司的货币健康产生预期的积极影响。

祝你好运。

Answer 4

您可以在两个方面处理该问题。

一个是内部的。切换到期望在整个时间内需求发生很多变化的方法应该会减少您（和您的团队）的挫败感。现在你要提前3周完成工作。一些团队使用Scrum进行为期一周的迭代，这使得计划更频繁（每周），但也减少了迭代期间某些事情会发生变化的可能性。您甚至可以更进一步尝试看板，在那里您可以在整个时间内更改优先级，而且从工程师的角度来看，这更像是一个订单而不是一个混乱。

另一件事是与商界人士合作。他们真的不在乎他们烧钱可能很难，但即便如此，你也可以尝试设置some techniques，将他们不断变化的决定与团队隔离开来（例如，让变革管理变得非常正式或引人入胜每当你计划另一段时间的工作时，他们都会组织整个积压的优先事项。）

Answer 5

精益更多的是纪律和避免浪费 - 这不是一个真正的过程。听起来这个问题可能更像是一个沟通问题。换句话说 - 你不会重视给予你足够的决定，认为它们是有效的。你的反应可能会在你的“客户”中产生一些敌意，它会变成一种自我挑战。

首先想到的是，你的“客户”并不愚蠢。这可能让你感到困惑，但请记住，除非你打开这扇门，否则你需要在一家新公司找到一份新工作，客户可以根据自己的意愿来处理这些事情。信不信由你 - 我不是想在这里苛刻，我只是建议沟通不流畅，听起来像你在说“我没有得到我需要的东西”。< / p>

您尝试改进流程非常棒，但没有任何流程可以改变这一点：

“我觉得我有时候会碰到砖墙。”和 “他需要鼓励我们的[公司内部]客户预先考虑他们的需求并做出更大的努力以确保他们在将其提供给我的开发团队之前得到修复。”

...对我说1）你很沮丧2）你不尊重他们正在做的事情。

我以前做过 - 我讨厌它。我继续前进 - 这是我唯一的解决方案。但是，如果你喜欢这份工作和你工作的人，那么过程就无法解决任何问题 - 个人技能会。这是你从“开发”到更多东西的地方 - 专业人士（你已经是 - 我只是意味着更大的）。

更多地了解业务方面。尝试DDD实践和ubiq。朗的事情让你更了解可能会发生什么，以及可能会发生什么变化。在这种经济环境下，你不能走很长的路 - 你需要适应和改变你的业务。

祝你好运！

Answer 6

你需要的是采用进化原型。但是，为了帮助抵消你在提出另一个变更请求时所感受到的一些情况，你应该说“是的，但它会将项目推迟X天/周/月，并增加成本Y量。”如果他们愿意付钱，乐意工作。 “他们付钱”是一个正当理由。

Answer 7

我认为在敏捷，特别是Scrum方法中，迭代或冲刺的内容在开始时就已确定，然后团队会在允许的时间内提供该内容（您的3周示例很好） ，然后你查看并调整下一个冲刺的变化。

没有人喜欢用“固定”或“签字”来描述冲刺是如何工作的，因为它听起来太老了瀑布，但对冲刺内容达成一致（例如一套用户故事来自产品Backlog）对于每个sprint来说基本上是相同的，只是比非敏捷项目更频繁地完成。

如果你在几周内无法达成这样的协议，那么你的客户确实在没有任何理由的情况下烧钱，除非注销税款。

Answer 8

“他们付钱，所以只要做你所说的，不要争辩”是合理的，但会导致一个人想做无意识的工作，“为了避免争论，你将不得不做所有我的想法。你还好吗？“看看会得到什么样的回应。从某种意义上说，这是升级的事情，但有时候一个糟糕的“假设”游戏需要完全展开。

可能有一些中间立场，人们可以说，“这就是我们现在想要的”，这就是完成的工作，然后建议进行改进。改变欲望是这个过程的一部分，因为找出你不知道的东西的唯一方法通常是艰难的。

一个反驳的观点是，团队应该对自己的工作感到自豪，如果被传递的内容被一遍又一遍地视为废话，那么在某些时候这会烧掉大多数人。你介意高流动率吗？有些地方可以将人们赶出去，而其他地方则没有那么多。您想在一两天内在圈子或大仓鼠轮上跑步？这听起来不是很有趣吗？ ;）

你有一个合理的关注基础，但关键是要有一些灵活性，事情会发生变化，这样当第一个可交付成果可能按照要求工作时，这不再有效，所以必须做其他事情。我想起了前任团队负责人告诉我们的事情：“90％的代码可能会被淘汰。这就是它的工作方式，接受它。”虽然听起来可能听起来很多工作并没有什么好结果，但在大多数情况下似乎确实如此。

关于这种骄傲的一点要点是Dale Carnegie's book, "How to Win Friends and Influence People,"在“做一个领导者：如何改变人们而不给予进攻或引起怨恨”的原则中作为其原则之一：

给他们一个良好的声誉，以实现。

书中有几个故事说明了这一点。

Answer 9

帮助我们解决这个问题的一个方面就是在迭代开始时我们都坐在一起讨论我们将要开展的工作。开发人员，客户，质量保证等。我们讨论它并估计我们正在开发的每一件作品。这往往会让客户思考并减少后来发生的变化。

除此之外，保持迭代很短，除了在每次迭代后进行更改。这就是敏捷/精益开发的理念。

Answer 10

我发现的一件事减少了要求的变化量，即每次更改或添加新要求时，都会更改截止日期和成本。当你做出改变而没有回过头来改变最后期限和成本时，他们会想要这个世界，当他们意识到所有这些变化都有价格时，那么他们通常会更合理。如果初始要求有问题，在您认为自己的主要问题得到解答之前，请不要提供时间估算或小时估算。

Answer 11

关于：

• 他们付钱给我们所以我们应该做我们被告知的事情

这一切都很好。但从长远来看，如果客户不被说服有某种程序，他们就会看到质量和生产力受到影响，而且几乎肯定会因此而责怪你。

软件公司的工作不是盲目地创造客户要求的东西 - 这是亚洲外包团队提供的便宜 - 而是帮助客户找出他们需要的东西，在某些情况下告诉他们他们想要什么。

建筑师不希望他的客户告诉他每个窗户的确切位置，他的工作就是采取他们的愿景并制作有用和真实的东西。

Answer 12

编辑 - 既然你说他们不关心推进交付，那么也许你必须认识到你根本不在开发项目中：你正在做研究。那里没有艰难的期限，研究也有所不同目标。一般来说，目标不是工作软件，而只是洞察力或获得的知识。

所以，如果你衡量“获得的洞察力/知识”而不是“开发的生产就绪软件”，那么你可能会做得非常好并且非常享受自己。

如果你不喜欢研究，那就没有汗水：只是建议从你的软件开发项目中拿出非常不确定的东西，并为它设置一个原型研究项目，并有明确的目标。