在跟程序员聊天的时候，一提到敏捷开发，他们总是会流露出不太高兴的表情。你想知道为什么吗？
他们消极的对待敏捷开发思想以及敏捷相关实践方法的原因是什么？有没有这种可能，他们认为导致方法失败的东西其实完全不是敏捷实践，而误会了敏捷的价值呢？
有这种可能性，但是团队成员认为他们只是敏捷教练的棋子。很容易看出他们为什么会这么想。管理上有一种趋势，要么引进独立的敏捷咨询公司，要么雇佣一个敏捷教练，监督团队中敏捷方法的实现和执行。
有外部人员这一事实造成了团队与敏捷化因素的障碍，这也导致了我们与敏捷的隔离。
团队成员会觉得受到太多控制以及被管得太细微。尤其是每天的站会都会以谈论最近一段的时间完成了一点点工作量而结束。而这不是每日站会的预期目的。
太强的时间压力同样是有害的。团队成员觉得他们需要定期交付任务，而不是当任务都已经好了再测试。这种以时间为导向的方法可能导致质量受损。
经常有报告说，敏捷周期太短了，在写代码之前甚至没有时间整理所有的文档，更不用说写完代码再重头过一遍。然而，在巨大的时间压力下工作是不够的，开发人员还需真正知道的是他们只有一击而中的时间。
很容易理解你的编程人员痛恨敏捷，只是因为你让他们以错误的方式进行。但也有可能你做的是对的，是你所带的团队成员不喜欢敏捷。在这种情况下，所能做的是等待敏捷在团队中变强，或者替换团队。
使用敏捷的人决定该做什么，在产品功能和外观上有发言权，在整体上可以对项目有把控。这也许是你值得告诉你的员工的。
请记住，敏捷方法作为编程方法是由程序自己而不是项目经理想出来的。
有没有可能设计出的敏捷和使用的敏捷的主要区别慢慢成为项目经理的领域而不是程序员的领域？如果这样的话，唯一的解决方案可能是让敏捷从项目经理中收回。
如果用赞许的眼光看待有些人对敏捷没有热情的原因，有一种看待敏捷的方式那就是敏捷使得大多数争论失败了，它是时代的标志。
事实是，无论你选用哪种开发方法，在当今时代，你都需要注意不断变化的客户需求，根据客户需求不断迭代你的工作结果。
换句话说，不管你怎么称呼它，在某种形式上，你都在使用敏捷。
还有件事：很自然任何事情都有消极面。你无法想象这么多开发者将敏捷作为开发方法，却没有任何人不喜欢它。总是存在不满意的人，不是么？
所以，去尝试，个性化你的敏捷方法（敏捷宣言里只提到了一些基本准则，没有提到Scrum,sprint,每日站会），只有这样再决定你是不是需要用敏捷。
扫一扫
8万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
