敏捷迭代是什么意思
我开始这个系列，询问“敏捷”的发展方向。 （我不喜欢在Agile 2019大会上看到的东西。） 第1部分是关于我看到的4个大问题。 第2部分是为什么我们需要经理。 第三部分是关于人们如何想要食谱的。 这部分是关于“敏捷”或“敏捷”的含义。
我了解人们希望他们认为“敏捷”的价值能够带给他们。 让我们回到“敏捷软件开发宣言”，我称之为“敏捷宣言”。 （戴夫·托马斯对此会有疑问，但我将其用作速记。）
为什么要宣言？
甚至在我1977年大学毕业之前，我们就遇到了软件“危机”。危机是什么？
- 项目“过期”。
- 项目“太昂贵了”。
- 产品质量不好。
听起来有点熟？
这怎么发生的？ 我们对流程没有给予足够的重视。
我在硕士课程中了解了结构化设计。 我敢肯定，我在80年代就了解过UML绘图。 我已经知道耦合（不好）和内聚（很好）。
我们的流程都无法帮助我们减少项目的时间或成本。 作为一个行业，我们的产品质量仍然不佳。 （第一份混沌报告于1994年发表。）
输入流程时代
CMM / CMMI的原始版本可以追溯到1991年。当时的想法是，如果我们能够正确地执行流程，那么我们可以更快，更便宜，更优质地获得优质的产品。
我的问题是，即使在Watts Humphrey添加了Personal Software Process和Team Software Process的情况下，CMM / CMMI也是该过程将软件项目视为可以计划的。 有点像建设项目。
我不知道没有迭代需求和设计的任何产品构造。 您可能会，但我不会。
1984年发生了一些与项目有关的事情：
- Microsoft Project的第一个版本。
- PMI于1984年创建了PMP。当时，PMP更侧重于建筑项目。 （这是我记得的。在这里，我可能完全不合时宜。）
太多的人认为软件项目与建筑项目相同。 （不，软件项目是关于作为一个团队一起学习的。）
在1990年代，许多人认为如果我们：
- 处理正确
- 一开始就明确要求
- 遵循更多基于建筑的方法
我们可以正确完成软件项目。
我从来没有做到过。 我以为我很傻。 我不是 我看到了自己的现实，并使用增量方法对此做出了React。
1990年代的软件现实
如果您还没有阅读Weinberg的质量软件管理系列或McConnell的快速开发，更不用说Smith和Reinertsen的“一半时间开发产品”了，您可能就不会意识到敏捷方法有多早开始。 当我为客户进行程序管理时，我读了快速周期时间。
功能驱动（增量）方法背后的想法至少是在90年代开始的。 早在70年代，我就开始使用“ inch-pebble”一词。 我们中的许多项目经理（至少在内部）都使用临时交付成果，当我们看到团队交付的成果时，他们会重新评估和调整我们的计划。
我从未对功能集使用迭代方法。 不，我几乎总是在下个月使用此功能集中的“全部实现/尽可能多地实现”功能。 我的时间框从未超过一个月，早在70年代，80年代和90年代初期。 （我从90年代中期开始开始使用较短的时间框。）
使用瀑布方法并每隔几个月至四分之一发布内容的使用者成功了。 我们中那些使用增量方法并能够使用持续集成并可能每个月或两个月发布的人也成功了。
其余项目没有成功。 他们陷入了需求地狱。 或者，建筑/设计地狱。 或者，测试地狱。 除非他们尝试在哈德逊湾出发 。
（关于发行的说明：我们在硬媒体上发行：磁带，CD，磁盘。发行成本很高。直到90年代后期，我们才可以开始在网上定期发行。）
处理繁重的方法不起作用。 频繁发布的轻量级方法确实有效。
轻巧，不重Craft.io
敏捷宣言的作者希望帮助软件社区成功。 他们在工作中已经看到，基于完成价值和获得反馈的轻量级方法比任何繁重的方法都有效。
考虑一下。
这些人是从业者。 他们看到了项目中的死亡行军。 他们看到缺乏基于团队的工作使一切变得更加困难。 他们看到，如果不不断学习，我们会一次又一次地重复同样的问题。 而且，当我阅读宣言时，最让我惊讶的是客户与团队的融合。
客户如何成为团队的一部分？
然后，我想起了我曾经参与并领导的一些重要项目。 当我直接与客户合作时，我得到了更多的反馈。 哪种产品都没有关系：工厂生产线的控制系统，汽车零件的检查系统，化学分析仪器。 当我与客户一起工作时，我的工作量减少了，反馈更多，产品也更好了。
使用轻量级方法的项目并不需要很长时间。 它们的成本不高。 当客户说我已经完成时，我常常不得不提早停下来。
至少，我的项目不是危机。 我的项目几乎“更好，更快，更便宜”。
谁不想要那个？
团队多久可以释放一些东西？
当《敏捷宣言》的作者见面时，他们知道一个大问题：太多的团队根本无法发布任何东西。 项目团队有很大的问题，尤其是需求生成需求问题。
如果您不能停止更改需求，您将如何离开需求阶段？
这就是以某种形式管理WIP的好处：仅关注下一周左右的需求，或者关注给定列中的WIP。 当然，您知道其他事情也会发生。 不用担心它们。 不要提前实施。
这种自由有助于团队释放某些东西。 团队释放的频率越高，获得新工作的频率就越高。 而且，团队发布的频率越高，项目的变更就越少。 它可能有小的变化，但没有大的变化。
这就是宣言作者想要解决的问题。 怎样称呼这种轻量级的软件产品开发方法？ 一种“敏捷方法”。
“敏捷”不是名词
注意，“敏捷”方法为团队提供了很多自由。 我们可以从任何方法/框架/方法中进行选择，然后查看哪种方法适合我们的情况。 敏捷方法是软件产品开发的许多可能的精益方法之一或组合。 Scrum只是众多可能性中的一种。 （请参阅敏捷不等于Scrum：了解差异 。）
几年前，我看到戴夫·托马斯（Dave Thomas）的演讲《 敏捷已死》 。 然后，我读了他的文章《 敏捷死了》（《敏捷万岁》） 。 如果您想了解Dave对敏捷作为形容词的看法，请转到视频中大约10分钟。
戴夫所说的最引起我共鸣的是：
您可以出售人名词。 您不能出售形容词。
我们有一个“敏捷”行业。 但是，很少有人真正理解什么是敏捷方法。
“敏捷”不仅不是名词，也不是专有名词。 如果您使用“敏捷”来描述您的工作，那对您意味着什么？ 敏捷方法是一个笼统的术语，而不是专有名称。 您可以通过多种选择来创建成功的敏捷方法。 这不是一个名字/术语； 宣言背后的原则是所有可能的。
敏捷方法可能是什么
如果您正在考虑团队或程序的敏捷转型或敏捷方法，请考虑敏捷方法可能对您意味着什么。
敏捷方法可帮助您在释放价值时释放客户的需求。 （请参阅敏捷的工作定义）。
如果您不需要过于频繁地发布（再次确定问题），那么您可能不需要敏捷方法。
那不是问题。 您不必使用瀑布式方法。 如果它们更适合您的上下文/需求，则可以使用迭代或增量方法。
如果您能够确定自己的业务问题，并且意识到自己可能需要一种敏捷的方法，那么您可能会决定要求团队协作，以暴民的方式传播知识并更快地解决问题。
您可能会要求团队限制其在制品，以便提高吞吐量。
您可以执行此操作，而无需使用命名敏捷方法。
当团队转向单人流程时，他们不需要站起来。 他们可能不需要计划会议。 他们可能经常需要查看路线图，讨论/创建测试/留下面包屑，以便他们不会忘记需要管理的风险。
并且，不要忘记回顾。
不要让进程名称使您感到困惑
我遇到了很多人和团队，他们告诉我他们使用Scrum。 （很抱歉选择Scrum，但这种名称得到了认可，以至于“每个人”都告诉我他们对其进行标准化并使用它。）
我问一些回顾性问题：团队多久花至少45分钟反思过去并从中学习经验？
“很少，因为我们的经理不希望我们花时间。” 那是我解释经理的角色的时候 。 而且，这些回顾可以在工作中增强适应能力和学习能力。
如果您不回顾过去的工作并从中学习经验，那么您就没有在使用敏捷方法。 追溯是宣言原则规定的一种做法。 （我建议您在决定框架/方法/方法之前先阅读这些原则。）
读东西
我看到太多的管理团队想要敏捷方法的价值，却没有意识到他们的要求。 我鼓励他们阅读一些内容 （也许不止一项），并在进行敏捷转换之前进行讨论。
几年前，我写了《敏捷过渡的最低限度阅读清单》 。
那时，我还没有意识到敏捷方法需要文化转变。 从那时起，我推荐我的这些书：
您不必喜欢我的书。 还有许多其他有用的书。 我碰巧与方法无关。 我发现敏捷原则比任何特定实践都有用。
经理们，请确保您希望获得所需的敏捷转换。 如果您不希望团队具有自治性，相互协作并互相学习，请不要进行敏捷的转型。
随着团队的学习，他们向传统的分层管理提出了挑战。 确保您想要敏捷方法的副作用，而不仅仅是所谓的“更好，更快，更便宜”。
经理阅读的内容越多，他们就越了解敏捷方法。 而且，他们可能会停止要求没有意义的“敏捷”。 我意识到经理们还有很多工作要做。 而且，我知道管理人员需要知道他们想要什么。
到目前为止的系列：
- 我认为“敏捷”的发展方向是第1部分：您是否需要敏捷方法？
- 我认为“敏捷”的方向是什么，第2部分：管理适合什么地方？
- 我认为“敏捷”的方向是什么，第3部分：什么是食谱，正确的答案？
- 我认为“敏捷”的方向是第4部分：“敏捷”是什么意思？
我知道我需要总结文章。
翻译自: https://www.javacodegeeks.com/2019/08/think-agile-headedwhat-does-agile-mean.html
敏捷迭代是什么意思
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
