敏捷是人们关注的焦点，但我认为那些对项目管理持怀疑态度的人有这种麻烦。
- 我一开始不太了解敏捷。
- 我无法想象敏捷如何管理项目
我会回答这些问题和焦虑。
如果你读了这篇文章，你就会明白的！
我将详细解释我是否敏捷，如何真正管理我的项目。
目录
敏捷开发需要记住的两件事
在过去三年中，我真正想到的敏捷开发是“与敏捷开发和成长中的生活一起”。 这种灵活、快速地思考和应对变化的风格，最初让我对方法的差异感到惊讶，因为到目前为止，我有很多项目管理，我倾向于非常仔细地规划和处理这些变化。
我觉得实际尝试和在网上阅读文章和书籍之间有差距，所以我想根据我的经验来解释真正的敏捷开发。
什么是敏捷开发？
为什么敏捷开发如此引人注目？
人们普遍认为，这是因为项目管理方法能够应对近年来业务的变化。
事实上，我也有这种感觉。 自从我推出最高技术和恩利特以来，我一开始使用一个简单的估计模拟工具，这是我的产品之一。Estim作为产品所有者参与。 在决定需要开发哪些反馈时，考虑到内部和外部实际使用的反馈，以及世界需求的变化，有时我们不需要上周需要的东西。 跟上这种快速变化的方法对于敏捷开发至关重要，因为它可以灵活、快速地移动。 因此，我明白为什么它受到关注。
敏捷开发方法
敏捷开发本质上是迭代的。 在一两周内重复规划、实施、测试和审核流程。 当我开始在敏捷开发项目中工作时，我使用Scrum，这是敏捷的典型开发方法，所以我将以Scrum为例，简要地解释它。
冲刺
在 Scrum 中，将短中断的时间段称为“冲刺”并重复。 我认为分隔期可以是一周或两周。 老实说，敏捷的新手团队在一周内会很不耐求。 从第二年开始，我们得到了一个星期的冲刺，但最初，这是一场来自开发成员的嘘声风暴。 一周就像皇家道路一样，但最好与球队协商，逐步推进。
产品积压工作
现在，我们将把我想开发的东西投入产品积压工作。 我认为，现在，我所想的只是好。 你经常问，“这真的在那里吗？ 这样的讨论可能很早就发生，但这是一个徒步的论点。 因为每次你这样做都会改变，所以如果你现在接近开发，那就更好了。 我认为，即使服务方的人花很多时间讨论它，也没什么意义，因为用户决定是否应该说极端。 这只是我的意见。
冲刺 （sprint） 积压工作
将高优先级要求放在冲刺 （sprint） 积压工作中，然后开始开发。 此处的常见失败在稍后将详细介绍，但“完成”的定义是模糊的。 需要注意的是，冲刺中的目标往往没有明确。
回头看
这是一个小组，找出项目团队在冲刺结束时的优缺点，并将其用于下一个冲刺。 这将是一个自我反省的机会，我希望球队能够减轻他们通常无法承受的压力。 当其他成员告诉我，我们不仅改善了坏的一面，而且取得了一些好东西，这很好。 这是动力，你可以期待更好的表现。 所以，让我们做它。 然而，当你成为几十个冲刺，你总是厌倦了回头看，所以建议你改变你的思维方式，如KPT和Fun/Don/Learn。
敏捷开发中的成功项目是什么？
由于它是一个敏捷开发，它不一定适用于任何项目，而且不适合。 不要忘记敏捷开发的先决条件。 不仅开发团队，而且所有参与开发的利益相关者都必须接受这些条件。 我经历过很多次，因为这种看法不同，项目变得一片混乱。 因此，我将解释至少需要的三个先决条件。 如果这些被抑制，项目不会100%成功，但如果它们不被抑制，我认为99%的失败。 现在，让我们来看看这三个。
成功敏捷开发的三个最低先决条件
1. 恐怕你还没有
决定接受不确定性。 我理解你想不惜一切可能打破难以预测的情况的感觉。 但是，敏捷开发之所以有效，是因为它与业务并行运行。 因此，在不确定时，能够澄清什么和可以做什么的想法变得非常重要。
2. 与
变化不明确一起，通过适应业务变化来发挥发展潜力。 对正在开发的规范进行重大更改或删除是理所当然的。 与其坚持按计划进行，不如记住，每次更改时，您都会更改计划，
3. 一旦你有
勇气放弃它，它就会充满你想要发展的东西。 你必须记住，不做也是一种选择。 重要的是确定其中的优先次序，只关注真正需要做的事情。 不要忘记，“你想要或不想”是由实际用户决定的。
敏捷项目管理
到目前为止，您已经了解了敏捷开发的特点。 您可能已经注意到，传统的项目管理方法可能无法适应敏捷开发。 因此，现在我想解释敏捷项目管理。
传统管理方法与敏捷方法的区别
通常，在项目的早期阶段无法做出决策，并且没有不确定性来推进项目。 在这种情况下，传统的管理方法与敏捷管理方法的响应方式不同。
传统管理方法 – 中型开发案例
当我是 50 人医疗保健应用程序开发的项目经理时，这是一种非常仔细的规划和管理方法。 有三个阶段的估计，如在需求定义阶段计算超估计估计，在需求变得有点规范时计算估计值，在最终确定在此规范中继续时作为常规估计计算。 此外，在开始开发之前，我们创建了屏幕过渡图和屏幕详细信息，在开发之前处于最佳状态，在审查计划时，主流是如何减少更改的影响。
敏捷管理方法 – 小型开发案例
当我成为不到10个LINE应用程序开发的Scrum大师时，我采取了积极主动的变革方法。 因为每周我想做的开发优先级，以及规范的添加和更改是正常的。 因此，即使设计师提前创建屏幕过渡图，规范通常也会在冲刺 （sprint） 计划前一小时在 Github 上创建。 这有点烦人，但我在一两个星期内执行了一系列任务，如规划、设计、实施、测试和演示结果反馈，以最大限度地提高团队绩效，同时保持这种速度和灵活性，并很好地管理项目。
敏捷管理中不应忘记的三点
确定“完成”的定义
顺便说一下，我们说“做”的定义。
可以毫不夸张地说，项目是否成功取决于“完成”的定义是否固定。
过去的情况是，工程师认为在实现完成后“完成”，测试人员在测试完成后认为“已完成”。 每个冲刺的目标都会有偏差，我想创建的功能是冲刺的堆积，所以最终我最终没有完成我的意图。 团队应该正确定义的“完成”是“在 00 个开发环境中实现、测试和修复缺陷的完成”，应该以共同的认识进行。
虽然这些定义可以由团队定义，但为了在整个团队（包括利益相关者）中达成共识，必须明确文化。
可视化开发状态
在每个冲刺 （sprint） 开始时，从故事分解为任务，并估计每个任务。 这并不意味着你应该完成它。 我们并不在看我们的团队每天处理哪些任务，以及我们以多快的速度前进，但我们希望始终了解这一点。 从那里，您可以分析团队假设的速度、估计值与实际值之间的差异以及这些细分，从而提高团队的效率。 我经常在 Google 电子表格上使用燃尽图表，以便直观地了解团队的状态。
我们能够清楚地管理故事名称、负责人、状态等，并自动描述开始时间。 这也是在谷歌电子表格的张普雷。 此外，它还根据分配百分比计算团队成员在一个冲刺 （sprint） 中的工作时间，并详细、准确地管理冲刺 （sprint） 中成员的任务和工作时间，例如冲刺 （sprint） 中相应的工时是否超过该工作时间。
现在，您已经详细介绍了敏捷开发中的可视化功能，请继续阅读。
设计沟通
在敏捷开发管理中，不仅开发团队，而且所有参与开发的利益相关者之间的自主沟通都非常重要。 自治，但部分是相当属人化的地方，所以很难通过，即使我想通过的气氛。 即使他们说，“这是敏捷的！”，当成员不善于自我管理或敏捷初学者聚会时，沟通就不会发生。
因此，建立易于沟通的机制非常重要。 以Scrum为例，我确信我每天在同一时间举行很短的时间会议，而每日Scrum则每周开会一次，以审查我们目前的计划。 我们还邀请了参与开发的所有利益相关者。 因此，在固定时间召开具有特定目标的会议，是促进沟通的机会。 与那些通常不经常谈论自己的成员交谈相比，这种机会比他们想象的要有效。
总结
由于互联网上存在无数关于开发管理方法的信息，因此您最终会想知道哪种方法更好。 但是，如果您参考本文中介绍的敏捷功能、适合每种方法的项目类型以及敏捷项目管理的具体方法，您将找到适合您的方法。
然而，软件开发的项目管理总是发生意想不到的事情。 敏捷开发不能只依靠知识，只有尝试才能理解。