看到不少团队蛮干，经常表现就是开发都开始了，临时改需求并要求立刻开发。这样的环境下，你连瀑布都做不到，何况是敏捷。
有些变更确实可以且应该直接插入带开发中的，有些不行。不行也不是绝对不行其实是价值代价考量。根本在于估计关联影响和时间影响分析。无论如何都需要走变更流程，评估影响，这就涉及到了需求价值分析，开发结构分解和估计开发时间。
此时就涉及到了谈判。开发者的筹码是专业，老板的筹码是资本。如果开发者特别听话，老板不需要高兴，因为你找的不是成年人。也就不要指望拿到成年人给出的成果。特别是，你为这个高兴，你自己也未必成年。PUA 的成功其实是双输。
那些哀叹者说就是这个环境没办法没办法的人，尤其不要说舔着脸什么敏捷。你连谈判的勇气和筹码都没有，谈什么敏捷。敏捷的底层是勇气勇气来自于筹码的底气。
敏捷联盟的那帮大佬的做派来自于都是很多筹码的，不要轻易去学做派。
有些用了敏捷开发模型的，说什么拥抱变化，你听听就好。当然要拥抱但是我下一个迭代拥抱还不是一样的拥抱。拥抱不是目的，作出高价值低代价的产品才是目的。
敏捷还说当面沟通胜过文档。有些人当成可以不写文档。
我见过当面一群十几个人人沟通几个小时，从需求胡扯到 for 循环怎么写。我半路加入当即叫停并找了一个人花了半小时写了文档，在拿着文档沟通几分钟搞定。好好地写个文档可以节省多少时间啊。此时写文档是比当面沟通更敏捷的。
敏捷联盟的敏捷是名词，敏捷的结果是形容词，所以你用了“敏捷”不等于你就“敏捷”了。