敏捷项目主要采用敏捷方法吗？这是一个有关敏捷项目管理的常见问题。敏捷方法是一种项目管理方法，用于快速、灵活地开发和交付高质量的产品。然而，并不是所有的敏捷项目都完全采用敏捷方法。以下是我对这个问题的理解。

首先，让我们明确一点：敏捷方法在许多项目中确实发挥了重要作用。敏捷方法通过封装小规模的任务（通常称为sprint），为团队创造了更快的反馈循环。这使得项目团队能够更快地适应变化和问题，从而提高交付速度和项目质量。

然而，有时候项目的特定需求可能使得采用纯粹的敏捷方法变得困难。例如，某些项目可能存在大量的复杂需求，需要长时间的分析和设计才能开始实施。在这种情况下，直接采用敏捷方法可能会导致质量问题和交付延迟。

所以，实际上，敏捷方法在许多项目中被视为一种工具，而不是一种固定的方法学。根据项目的特点和需求，可以根据具体情况进行调整和应用。有些项目可能采用混合方法，一部分采用敏捷方法，另一部分采用传统的瀑布方法。这样可以保持敏捷方法的优势，同时充分考虑项目的特殊需求。

总而言之，敏捷项目主要采用敏捷方法，但并不意味着所有项目都完全采用敏捷方法。敏捷方法在符合项目需求时是非常有用的，但对于某些特殊项目来说，纯粹的敏捷方法可能不是最佳选择。灵活性和适应性是实施敏捷的核心原则，只有在实际问题中做出明智而明确的决策，才能实现真正的敏捷项目管理。

二、为什么敏捷工作更有效(敏捷框架) Scrum框架是在当今的软件开发界里面应用得比较广的一种框架，也是国内能看到的，大多数的敏捷在线项目管理工具的范本
目前这个框架呢，有一个叫Scrum联盟的组织，在负责维护和管理这个组织，每年会有一些认证，每年开一些会议，会定期地去更新这个框架
Scrum框架的思想来源于一个著名的思想叫精益思想，这个思想是丰田在上世纪80年代提出来的这个思想有两个重点，一个叫，respect people，尊重人；另外一个叫Continuous improvement，也就是持续改进实际Scrum框架也是秉承的这样的原则
在Scrum这个框架里面我们会给团队分配这三类角色，第一类叫Scrum master，这是一个人；第二类叫产品负责人Product Owner；第三类叫团队，Team
Scrum 主管： Scrum master在这里不是项目经理的意思，他更像是这个团队的保姆，他要负责整个团队的鼓励工作，为团队服务，给团队提供理论支持，引导团队更像是教练的一个工作
产品负责人： Product Owner是这个Scrum团队里边儿唯一一个经过授权的人，他负责的是整个产品整个产品开发做什么，不做什么，哪一部分在哪个时间点交付的这个工作，也就是说，负责构建产品待办列表
开发团队成员 ：在Scrum里头，这个团队是近似于全功能的跨职能团队，其实敏捷对团队的要求是非常高的，这也是他成本高比较贵的原因之一
第一个工件，叫 产品待办列表 （Product Backlog），它其实有点儿像我们现在产品开发中讲的需求池的概念，通常来讲，我们会把所有需求一股脑的扔到这个列表中去，但是这个列表会有一个与传统的需求池不一样的地方这个列表里面所有的需求，都是有价值的，有次序的
第二个工件是 冲刺待办事项 (Sprint backlog)，通过我们价值的体现，包括我们对它的排序我们就会得出这样一个结论，我们应该先做什么，后做什么
第三个工件，叫 潜在可交付产品增量 ，这个东西大致的意思是，我们在做产品的时候，是一个迭代增量的过程
第一个叫 Scrum计划会议 ，把产品待办事项列表里面的东西决定哪些可以在Scrum计划会议里边儿解决掉，做出 冲刺待办列表
第二个会议，我相信很多的企业，很多的团队在做，叫做 每日站会
这个站会通常都问什么问题呢，我昨天做了什么，今天我要做什么，我遇到了什么问题，通常都是这样的对吧但是我想告诉大家的是，大多数团队开这个会的时候，问的这三个问题都是不正确的，我们去看原文：
第一个问题：What did I done yesterday that helped the Development Team meet theGoal?
第二个问题：What will I done today to help the Development Team meet the Goal?
也就是说在敏捷开发这个环境里面，我们不会讲我做一件事情，做了百分之多少，在敏捷的世界里没有百分之几这个概念，它只有零和一没完成就是零，完成了就是一所以他的问题会说，我为了我们团队的目标，昨天做了什么；我为了我的团队目标，今天我要完成什么
第三个会议叫做 Sprint评审 ，Scrum review这个会议就是来评价你迭代的这个产品，是不是可以纳入到潜在可交付的产品增量，这还是个潜在的，还是不可交付的，经过了这个会，你能不能交付这个事儿就能定了
第四个会议叫 Scrum回顾 希赛发过一篇文章，里面有一部分讲回顾（文章后附该篇文章的链接）那就是敏捷回顾的一部分，叫做帆船工作法，或者帆船回顾，有兴趣可以翻回去看一看敏捷回顾对敏捷这种活动来讲是非常重要的，应该说是在这几个敏捷Scrum的活动里面是最最重要通过回顾，我们不但能够找到过去的一些缺点和失误，还能发现一些优点，并持续的改进下去，这对于敏捷团队尤为重要，为什么呢，因为敏捷这件事，第二个原则就是要持续的改进
第五个会议是一个持续的活动，这个活动叫 产品列表梳理 说白了就是收集需求因为敏捷相对于传统开发，这个需求不是那么稳定但是我们讲拥抱变化，我们拥抱变化，不是为了让需求蔓延拥抱变化，也不是为了让项目镀金，拥抱变化的意思是要让项目符合用户的价值，要让项目达成既定的目标或持续改变着的目标，我们要对这个需求做调整，这件事才叫拥抱变化
专注，公开，承诺，勇气，尊重
1承诺 愿意对目标做出承诺
2专注 把你的心思和能力都用到你承诺的工作上去
3开放 Scrum 把项目中的一切开放给每个人看
4尊重 每个人都有他独特的背景和经验
5勇气 有勇气做出承诺，履行承诺，接受别人的尊重
2.Stacey矩阵(Stacey模型)
这个模型能很好的告诉我们，为什么要使用敏捷去解决问题
这个模型里面分四个部分，一部分叫Simple，just do it第二部分叫Complicated，然后空白的部分叫complex，右上角那个我把它叫混沌，混沌的问题咱们不去讨论，实际上我们在软件开发里面，要做的事情就是三体里面讲的，叫降维打击
在这个过程里，我们将复杂的东西划到一个相对简单的区域去解决然而呢，对于一些很复杂的情况，比如说，我们需求很不确定，我们也不确定用什么方法去做这些事，我们就用敏捷方法去做敏捷方法是什么呢，就是持续学习，持续迭代，持续规划这样一个方法
这是一个实用的非预定义过程
有同学问，敏捷项目和传统项目的区别，如何进行混合应用，相互取长补短？传统项目即预测型项目
我们在预测性的项目里，做的事情是这样的首先有一个发起人，然后我们做一个详细的计划，然后强制团队，或者说责令团队按计划去进行，然后在中间控制变更，按规定测试，结项等等，最后交付产品
然而，敏捷不是这样的，一个敏捷软件的开发往往在敏捷初期，是不会预见到几个迭代之后的软件需求的它往往是，以最小可行性产品，MVP，去交付给客户也就是说我们用最基本的模型，最基本的能用的东西给客户去用，从而不断的得到客户的反馈，不停的迭代，改进，或者重构这就是拥抱变化，或者叫检查和适应，敏捷和传统项目的一个比较好的区别的诠释
所以敏捷，其实是一种轻量型的，最开始确实是用在软件上的，软件开发原则它是一种方法，一种思想，是一种迭代的研发模式，而且是增量的，是一种一定时间盒的，以价值为中心的
敏捷是一种适应复杂情况不靠谱客户的，一种持续学习，持续增量的迭代模型
敏捷有一个特别著名的东西叫做敏捷软件开发宣言，这个当时在2001年发布的时候，推动了硅谷的一个改革
敏捷宣言里面提到了四点价值观，这四点价值观大家看看就行了他最重要的一句话，尽管右向有其价值，我们更重视左向的价值说白了就是，你一切从客户出发，一切从变化出发，一切从成果出发，一切从价值出发，比你那些花里胡哨，按规定来的这些东西，更有价值
它是一种价值观，也代表了这一帮人的一种处事方式
参考文章： https://www.educity.cn/pmp/1991709.html