瀑布迭代
We all have been in some engineering project related to work or school where the process, requirements and results — all part of a project lifecycle — are attempted to be defined before the project is off the starting blocks.
我们所有人都参与过与工作或学校有关的某个工程项目，因此在项目脱离起点之前就试图定义过程，要求和结果(项目生命周期的所有部分)。
You can recognize these situations when you hear people often say things like:
当您听到人们经常说诸如此类的事情时，您可以意识到这些情况：
“Let’s define the requirements as complete as possible”
“让我们定义要求尽可能完整”
“We need more details before we begin”
“在开始之前，我们需要更多细节”
“I have done this before, let’s..”
“我以前做过，让我们开始。”
We call it waterfall thinking when a team assumes that they can only start with the next project phase when they have finished the previous phase in an all-encompassing way. Whether it was the nature of the assignment to do so or a fellow group member convinced your team into following this lifecycle approach, it will ̶m̶o̶s̶t̶ ̶l̶i̶k̶e̶l̶y̶ definitely result into a failure-prone process. Which we don’t want!
当团队假设他们只能以无所不包的方式完成上一个阶段时，我们只能将其称为下一个项目阶段。 无论是分配的天性如此还是老乡组成员确信你的团队到以下这个生命周期方法，它很可能会造成一定成易出故障的过程。 我们不想要的！
I will provide you with the scientific details in a bit.
我将为您提供一些科学细节。
Luckily there is an alternative method where your project lifecycle is organized into a series of mini-projects that we call iterations. Each iteration has its own phases and delivers an evolving end-product. Happy team members and scientifically proven better deliverables as a result.
幸运的是，有另一种方法可以将您的项目生命周期组织为一系列称为迭代的小型项目。 每次迭代都有其自己的阶段，并提供不断发展的最终产品。 结果，团队成员快乐，科学证明了更好的交付成果。
Sounds interesting right?
听起来很有趣吧？
象征性地潜入瀑布 (A dive into the Waterfall, figuratively)
The waterfall approach assumes that a project has a set of lineair sequential phases where each phase fundamentals are pre-defined and are building on the results of the previous phase.
吨他瀑布式方法假设一个项目有一组的线性的连续的阶段，其中每个阶段的基本面是预先定义的，并建立在前一阶段的结果。
Teams that follow this project lifecycle are tempted to define all the requirements they can think of in the very beginning because the subsequent project phases are stacking up and are based on this requirements foundation. As a result of this approach the requirements are ‘freezed’ during the first phase. This makes the project vulnerable to false assumptions and time-consuming discussions when the requirements needs altering later on in the process.
遵循此项目生命周期的团队很容易定义他们一开始就能想到的所有需求，因为随后的项目阶段正在堆积并且基于此需求基础。 这种方法的结果是在第一阶段“冻结”了需求。 当需求在流程的后期需要更改时，这会使项目容易遭受错误的假设和耗时的讨论。
Studies reveal¹ that 45% of the pre-defined requirement features in waterfall projects are not used at all and that 19% of these requirement features are rarely used in the final product. That seems to be a substantial waste of time and resources!
研究表明¹在瀑布项目中根本没有使用45％的预定义需求特征，而在最终产品中很少使用这些需求特征的19％。 这似乎是在浪费时间和资源！
Let that sink in. Almost 65% of pre-defined requirement features will be barely used.
让它沉入其中。几乎几乎不会使用预定义需求功能的65％。
Waterfall practices were cited as the number one contributing factor for project failure in 82% of the cases in a major software projects study².
在大型软件项目研究²中，瀑布实践被认为是导致项目失败的第一大因素，占82％的案例。
But why are waterfall projects so prone to fail?
但是，为什么瀑布项目如此容易失败？
In a lot of (software) engineering projects the responsible development team assumes that the requirements can be easily predicted and defined at the beginning of the project. But it turns out that most projects are subject to change. Requirements change rates can spike from 35% up to 50% during development³. It is safe to say that change is one of the constant factors in an engineering project lifecycle.
在许多(软件)工程项目中，负责任的开发团队认为，可以在项目开始时轻松预测和定义需求。 但是事实证明，大多数项目都可能会发生变化 。 在开发期间，需求变更率可以从35％飙升至50％。 可以肯定地说，变更是工程项目生命周期中的恒定因素之一。
However, I don’t imply that you should start developing on your project right away without defining some necessary starting requirements. But in order to work successfully with the expected change rates we need a different approach. A project lifecycle that implements an iterative cycle and evolving requirements may just be the right answer!
但是，我并不是说您应该立即开始开发您的项目，而无需定义一些必要的启动要求。 但是，为了成功地以预期的变化率工作，我们需要一种不同的方法。 实现迭代周期和不断发展的需求的项目生命周期可能是正确的答案！
让我们迭代！ (Let’s Iterate!)
An iteration is basically a repetition of a process cycle. When applied to (software) engineering projects, iterating means that you repeat the project lifecycle multiple times in a fixed short-period of time. So instead of a long time gap between the build process end the end-product with the waterfall approach, you are constantly delivering an evolving end-product at the end of each iteration. We call this evolutionary development.
迭代基本上是一个处理周期的重复。 应用于(软件)工程项目时，迭代意味着您可以在固定的短时间内多次重复项目生命周期。 因此，您可以在每次迭代结束时不断交付不断发展的最终产品，而不是在构建过程最终产品与瀑布式方法之间花费很长时间。 我们称这种进化为发展 。
Let’s breakdown the iteration lifecycle.
让我们细分迭代生命周期。
As you can see in the illustration, the first stage is the (initial) planning stage where the necessary requirements for that iteration are mapped out as well as the planning for the subsequent stages. Note that the iteration should be a fixed time-period. This is also the stage where you define the necessary requirements.
正如您在图中所看到的，第一阶段是(初始)计划阶段，其中计划了该迭代的必要要求以及后续阶段的计划。 请注意，迭代应该是固定的时间段。 这也是定义必要需求的阶段。
In software development, a three-week period is often used as timeframe for the iteration and is called a Sprint.
在软件开发中，通常将三周的时间用作迭代的时间表，称为Sprint 。
Then a requirements analysis is performed to make sure that all the necessary business logic for the specific iteration is incorporated. Depending on the analysis results, you can come to the conclusion that you have to adjust some requirements. No problem, make your adjustments!
然后执行需求分析，以确保合并了特定迭代的所有必要业务逻辑。 根据分析结果，您可以得出必须调整某些要求的结论。 没问题，请您进行调整！
When the requirements are established, the design phase is where the possible implementation solutions are narrowed down to a few options to determine the most effective way to construct the product.
确立要求后，在设计阶段就将可能的实施解决方案缩小为几个选项，以确定最有效的产品构造方法。
The implementation phase is what you probably expect from this phase; the actual building of the product according to the analyzed requirements and the design.
实现阶段是您可能期望从该阶段开始的； 根据分析的要求和设计来设计产品的实际结构。
After the implementation, the product must complete testing procedures to identify any issues and to check if the new product version satisfies the common product standards.
实施后，产品必须完成测试程序以识别任何问题并检查新产品版本是否满足通用产品标准。
Finally, it is time for the evaluation phase. Team members, clients and other stakeholders examine the product and give feedback on its current status and performance. Once again you can come to the conclusion that your current product version lacks some requirements. That’s the fun of it, you have valuable feedback now. This feedback is in turn the input for a new iteration and further evolutionary development.
最后，是评估阶段的时候了。 团队成员，客户和其他利益相关者检查产品并提供有关其当前状态和性能的反馈。 再一次可以得出结论，您当前的产品版本缺少某些要求。 这很有趣，您现在已经获得了宝贵的反馈。 该反馈反过来又是新迭代和进一步进化开发的输入。
The next thing you will be saying in a project:
您将在项目中说的下一件事：
“Veni, Vidi, Iteratis”
“ Veni，Vidi，Iteratis”
I came, I saw, I iterated
我来了，我看到了，我反复
Now you can iterate as often as it is necessary to deliver and deploy your product. The iterative approach challenges teams to evaluate a series of good ideas and implement them altogether along the road, as they see fit in relation to the current status of the product. The whole approach reminds a bit of The Marshmallow Challenge where iterative thinking is discussed as one of the main success factors in well performing teams.
现在，您可以根据需要交付和部署产品的次数进行迭代。 迭代方法向团队提出挑战，要求他们评估一系列好的想法，并在他们认为与产品当前状态相关的情况下完全实施。 整个方法让我们想起了棉花糖挑战赛 ，其中迭代思维被认为是表现出色的团队成功的主要因素之一。
最后的想法 (Final thoughts)
Why is the iterative approach so successful?
为什么迭代方法如此成功？
The iterative approach is successful because the project lifecycle can handle the occurence of change. There is also room for trial and error. Fundamental flaws which are not apparent from the start can be dealt with in the next iteration. With each iteration, the project evolves and becomes better and completer. It also enables us to monitor and evaluate the whole project per iteration and make important choices along the road. Consider giving it a try in your next project!
迭代方法是成功的，因为项目生命周期可以处理更改的发生。 还有尝试和错误的余地。 从一开始就不明显的基本缺陷可以在下一次迭代中解决。 每次迭代，项目都会发展并变得更好更完整。 它还使我们能够每次迭代监视和评估整个项目，并在沿途做出重要选择。 考虑在您的下一个项目中尝试一下！
Good luck iterating.
祝你好运迭代。
[1] : Johnson, J. 2002. ROI — It’s Your Job, XP 2002, Sardinia, Italy.[2]: Thomas, M. 2001. IT Projects Sink or Swim. British Computer Society Review.[3]: Jones, C., 1997. Applied Software Measurement. NY, NY.: McGraw-Hill
[1]：Johnson，J.，2002年。《投资回报率》，这是您的工作，XP，2002年，意大利撒丁岛。[2]：Thomas，M.，2001年。IT项目接收器或游泳。 英国计算机学会评论 。[3]：Jones，C.，1997。 应用软件测量。 纽约州：麦格劳-希尔
翻译自: https://medium.com/boilercode/stop-with-waterfall-thinking-and-start-iterating-9be9c9bf5bcf
瀑布迭代
扫一扫
1733
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
