不要轻易声称自己敏捷了

看到不少团队蛮干，经常表现就是开发都开始了，临时改需求并要求立刻开发。这样的环境下，你连瀑布都做不到，何况是敏捷。

有些变更确实可以且应该直接插入带开发中的，有些不行。不行也不是绝对不行其实是价值代价考量。根本在于估计关联影响和时间影响分析。无论如何都需要走变更流程，评估影响，这就涉及到了需求价值分析，开发结构分解和估计开发时间。

此时就涉及到了谈判。开发者的筹码是专业，老板的筹码是资本。如果开发者特别听话，老板不需要高兴，因为你找的不是成年人。也就不要指望拿到成年人给出的成果。特别是，你为这个高兴，你自己也未必成年。PUA 的成功其实是双输。

那些哀叹者说就是这个环境没办法没办法的人，尤其不要说舔着脸什么敏捷。你连谈判的勇气和筹码都没有，谈什么敏捷。敏捷的底层是勇气勇气来自于筹码的底气。

敏捷联盟的那帮大佬的做派来自于都是很多筹码的，不要轻易去学做派。

有些用了敏捷开发模型的，说什么拥抱变化，你听听就好。当然要拥抱但是我下一个迭代拥抱还不是一样的拥抱。拥抱不是目的，作出高价值低代价的产品才是目的。

敏捷还说当面沟通胜过文档。有些人当成可以不写文档。

我见过当面一群十几个人人沟通几个小时，从需求胡扯到 for 循环怎么写。我半路加入当即叫停并找了一个人花了半小时写了文档，在拿着文档沟通几分钟搞定。好好地写个文档可以节省多少时间啊。此时写文档是比当面沟通更敏捷的。

敏捷联盟的敏捷是名词，敏捷的结果是形容词，所以你用了“敏捷”不等于你就“敏捷”了。

magiclx

70 天前

在当时诞生的背景上，是对传统开发过程的反思。对开发者和出资方来说都很有价值，当然，落地时，那又是另外一个故事。

1. 小公司看结果，不管这些虚头八老的东西，只管成本低，产出高。
2. 中型软件公司上敏捷的，领导得懂，要不招式都打不好。好的敏捷咨询师和培训师的钱不能省，敏捷落地成败还和团队素质，各相关方都很有关系。
3. 大公司一般会裁剪定制自己的敏捷过程，为保持节奏，多用固定发布周期的模式。

其实从用人角度讲，敏捷成本会更高，因为得用上思维更清晰，更正面思考，更全能的开发者，这类人都不便宜。