php 三元预算? :_项目预算：一种反模式-CSDN博客

php 三元预算? :

The desired benefits of agile development are many. Customers are happier and more willing to buy. Lead time from idea to delivery is shorter. Employees are more motivated and more productive.

敏捷开发的预期好处很多。顾客更快乐，更愿意购买。从构思到交付的交货时间较短。员工更有动力，生产力更高。

Sounds good, doesn't it? In practice, certain behaviors stand in the way of the benefits. As a scrum master and agile coach, I see the same anti-patterns in many companies over and over again. Today's anti-pattern is about project budgeting and contracts.

听起来不错，不是吗？实际上，某些行为妨碍了收益。作为一名敏捷大师和敏捷教练，我一次又一次地在许多公司中看到相同的反模式。今天的反模式与项目预算和合同有关。

确定范围-不是一个好主意 (Fixing the scope - not a good idea)

In many companies, the scope of delivery must be decided on first. Then someone estimates the effort and calculates the necessary budget. Finally, there is a go or no-go decision for the project.

在许多公司中，交货范围必须首先确定。然后有人估算出工作量并计算出必要的预算。最终，该项目有一个进行或不进行的决定。

It is similar for many customer supplier relationships. First, a contract must be set up that describes exactly what will be delivered. Otherwise there is no order.

对于许多客户供应商关系而言，情况相似。首先，必须建立一个合同，该合同确切描述了要交付的内容。否则没有命令。

How else could it be? How else can you, as a customer, be sure what will come out in the end?

怎么可能呢？作为客户，您还能如何确保最终会得到什么？

As an agilist, here's my answer. Customers can't possibly know the exact end result in advance. Software development is full of surprises. The requirements of today are history tomorrow.

作为一名敏捷专家，这是我的答案。客户可能无法提前知道确切的最终结果。软件开发充满了惊喜。今天的要求是明天的历史。

It's important to recognize the tension between predictability and changeability. You can't have both: perfect predictability of the end result at the beginning and maximum consideration of change requests later.

认识到可预测性和可变性之间的张力非常重要。你不能兼得：最终结果的开头完美的可预测性和后来最大限度地考虑变更请求。

您可以做什么 (What you can do instead)

At the beginning of agile development, it is sufficient for stakeholders to agree on a product vision, and maybe a rough roadmap. Funding can be done incrementally, sprint by sprint.

在敏捷开发的开始，利益相关者就产品愿景达成共识就足够了，也许还有一个粗略的路线图。可以逐个冲刺地逐步增加资金。

But what if this is not possible in your company? What if the stakeholders don't want to give up the illusion of safety that comes from clarifying requirements early?

但是，如果您的公司无法做到这一点，该怎么办？如果利益相关者不想放弃因尽早澄清需求而产生的安全错觉怎么办？

Well, it's a waste of time to specify details of requirements that will change later. So what to do?

好吧，浪费时间来指定稍后将更改的需求详细信息。那么该怎么办？

You can agree on user stories in advance. That makes sense. But don't define the acceptance criteria! Clarification of details is postponed to development, shortly before implementation.

您可以事先就用户故事达成协议。这就说得通了。但不要定义接受标准！在实施之前不久，细节澄清会推迟到开发阶段。

The advantage: you can react to lessons learned from development and new customer needs.

优势：您可以对从开发和新客户需求中汲取的经验教训做出React。

正确进行变更管理 (Change management done right)

Either at the beginning of a project or during contract negotiation, stakeholders should agree on the mode of cooperation and the handling of changes later.

在项目开始时或在合同谈判期间，利益相关者应就合作模式和以后的变更处理达成协议。

It is important to follow a few important principles.

遵循一些重要原则很重要。

If there are changes, a change management process that evaluates each change individually is NOT enough. Instead, a change should be related to other changes.

如果有变更，仅凭评估每个变更的变更管理过程是不够的。相反，更改应与其他更改相关。

For each change that is implemented, either

对于实施的每个更改，

take another requirement out of scope, or
使另一个要求超出范围，或者
increase the duration of the project.
增加项目的时间。

During development, individual elements can therefore be replaced by elements that are equivalent in terms of development effort. Scrum supports this with the Product Backlog–by pulling a backlog item up, the other elements automatically have less urgency.

因此，在开发过程中，各个元素可以用在开发工作量方面相等的元素替换。 Scrum通过产品待办事项支持这一点–通过增加待办事项，其他元素的紧迫性自动降低。

If you want to know more about agile contract design, I recommend you have a look at Money for Nothing and Your Change for Free.

如果您想了解有关敏捷合同设计的更多信息，我建议您先看看“一无所有”和“免费找零” 。

To get the basics of agile software development right, visit my online course. If you want to keep up with what I'm doing or drop me a note, follow me on dev.to, LinkedIn or Twitter. Or visit my GitHub project.

要正确掌握敏捷软件开发的基础知识，请访问我的在线课程。 如果您想跟上我的工作进度或给我留言，请在dev.to ， LinkedIn或Twitter上关注我。 或访问我的GitHub项目。