“聊胜于无”的结果与视角割裂

“聊胜于无”的结果

    开发主管、项目经理、客户经理和团队主管都各自学习敏捷知识，并且在项目开发中运用了敏捷的方法。

    开发主管认为尽管团队现在编写的代码质量肯定比以前好，但是他感觉为了赶进度，他在技术上有所牺牲。

    项目经理认为现在没有一个自顶向下的大计划可以用作路线图。他发现自己越来越依赖于通过每日站立会议获得项目的进展。他越来越感觉自己只是一个协调者或者组织者，而不是控制整个项目的项目经理。他只关心当前状态，因此他感觉很难看清项目会遇到的障碍，也无法帮助项目铺平道路。

    客户经理感觉自己成了项目负责人，他必须参加这些每日站立会议，还要不停地回复开发人员关于软件产品细节的邮件和问题。他自己本来就由别的工作要做，他也不喜欢被打扰，他自己本来就有别的工作要做，他也不喜欢被打扰，他感觉好像其他人把构建伟大软件的责任都推到了他身上，而他自己不可能解答所有的问题。

    团队主管总感觉有一些事情不尽如人意。虽然引入敏捷有利于项目的进展，没有人被强迫逞强，也没有了那么多加班的周末和长夜。但是团队绝对没有感受到“生产力超强”，也没有人对产生的结果感到惊喜。只是感觉项目的状态从不正常变为了正常，这样的结果聊胜于无。

视角割裂

    敏捷有很多实践，并不是使用了敏捷的实践就可以立即变为一个高效的团队、立即交付高效的软件，以编写用户故事这种敏捷实践为例，一个用户故事通常只有几句话，写在一张索引卡上，描述一项非常具体的用户需求。

    项目经理主要任务是创建任务，一个用户故事就是要完成的任务。

    开发主管主要任务是分解任务，把用户故事分解为多个小任务，为每个任务创建一个索引卡。

    产品经理主要任务是明确需求，他要确保每一个用户故事都准确描述用户的一项需求。

    团队主管主要任务是制定计划，他帮助团队成员计划下一步要完成的事情，并且通过进度让整个团队保持动力。

    但是这也会产生副作用，开发主管主管可以自由参与构建软件的相关决策。他自主的加入部分功能，但是产品经理说这些功能不是客户所需要的，并且会增加用户的成本。这使开发主管很沮丧，不得不重写大部分功能的代码。开发人员与客户缺少沟通导致敏捷项目遇到了瀑布式项目会遇到的问题：开发人员作出了错误的假设，然后开始编程，最后不得不对代码做一些本可以避免的修改，而这些修改使得软件更有可能出错。

    如果每个人只考虑自己的工作，只关心用户故事如何帮助自己，而不进一步看一看整个团队可以怎样使用用户故事（或其他的敏捷工具、技术和实践），那么最后就有可能出现这样的问题。我们把这种问题称作视角割裂。

    人们能交付的东西通常取决于他们所关注的东西。越是关注自己的目标，而不是整个团队的目标，那么他们能为公司交付真正价值的可能性就越低。

为什么采用敏捷得到的是“聊胜于无”的结果

    他们只是在擅长的领域采用了更好地实践，因而把这些事情做的更好。但是他们还没有触及项目以往没有得到关注的领域，因为影响这些领域的实践对团队中任何成员都没有吸引力。