文承上篇，继续来谈敏捷。

昨天，提到了敏捷的一个很重要思想就是“勇于迎接变化”。

就有人说了，你一定不是技术出身的吧。做技术的就讨论变化，最不允许的就是确定的需求再修改。当产品经理与技术人员沟通时，当谈的一个复杂性操作时，经常说：“你确定不会修改了吧，如果你确定需求不变，我就做！”，你要答应了，再找技术修改时哪就等于堵死了自己的后路。

实际，哪能一定有不修改的需求呢？我们做产品不也是时刻在迎接市场的考验吗？在大海上航行，当风向变化，我们的大船不也得时刻准备掉头，准备调整。变化，本身就是为了适应，没有变化，就等于没有进步。但作为产品经理的我们，能做的应该是利用自己的智慧和敏锐的市场洞察力，尽量的去感知风向，尽量的控制需求，在需求发现初期就做好充足的调研。怕变化，不是办法，在项目初期就要做好灵活可调整的方案，如果需求真的变化了，我们应该怎么办，这才是敏捷的思想，需求的变化，我们谁能阻拦得了呢？

好，继续说敏捷的其它思想。

1、尽早、持续的交付可运行的阶段性成果

之前我曾经说过，一个项目的失败，一般不是技术原因，多是因为客户对我们失去信任。我们需要持续的、不断的给客户以信任感，一种是我们在客户现场不断的交流、沟通，让客户感受到我们的热度。同样，还需要尽早的、持续的给客户提供相应的成果物（可运行的产品），让客户看到我们的能力。当然，这样还有另一个好处是，能够把问题提早的暴露出来，不要羞羞答答像个小女人，不敢见人，只有提前暴露，才能提早解决，问题越晚暴露越难解决。

在房产项目中，当天完成的内容在编译没问题后，会把修改的功能部署到平台服务器上，以便于客户随时能够看到变化，了解项目进度。如有问题的话，也能够尽早暴露出来。

总结：为了降低项目风险，尽早交付可运行程序

2、面对面的沟通

最快的交流方式就是面对面的沟通，在敏捷开发中，最提倡的方式是减少哪此冗余的、效率低下的沟通方式，用最快速的方法来直接沟通。让技术人员、设计人员、客户等所有团队成员都在一起办公，减少信息交流的断路，让沟通变得顺畅。

在房产项目中，当有问题不理解，需要交流时，都是直接找我，我不清楚的直接找客户。当我不在时，同事们也会直接与客户进行沟通，任何人都可以直接获取需求。

总结：直接沟通，减少中间环节

3、可工作的软件是最主要的衡量标准

出再多的文档、再多的中间产物，都没有出结果来得真切。客户最观心的不是中间物，而是成果物。对于敏捷软件开发来说，可以工作的软件是评测开发进度的最主要衡量标准。唱的再好，也不如做的好，做事要落地，实实在在、踏踏实实是敏捷开发的核心，不玩花拳绣腿。

总结：做出可交付的软件是项目的核心

4、保持恒定的开发速度

项目开发是一次长跑，短期内迅速的加速，并不是长跑的方式，我们应该持续的、匀速的跑步方式，这样才能保证团队成员能一直坚持到最后。敏捷开发提供可持续的开发速度，这样不仅团队成员不至于疲惫，也有利于制定项目开发进度，控制开发周期。

总结：项目开发过程是长跑，不要一开始就冲刺

5、定期团队优化

我们会每隔一段时间进行一次团队建设，进行批评与自我批评，找出工作中的问题及影响个人与团队发展的瓶颈。我们通过交流、沟通方式找出团队及成员间的问题，然后进行自我调整，通过不断的优化、升级自有团队，打造出一个能战斗的队伍。

总结：建一个能打硬仗的队伍

如果项目管理者能够很好的运用敏捷开发思想，就相当于在游戏世界里拥有了法器，美食世界里掌握了烹饪之道。在敏捷开发里还有许多其它思想，但有的思想本人并不太认同，如用“测试驱动开发”，在中国与在国外不同，在国外有ＣＭＭＩ，对测试要求非常高，测试实际就是质量检查部门、质量控制部门，有着很高的权限，对测试人员也是更加尊重和认同。

在国内，公司多重开发而轻测试，从你公司测试人员与开发人员的薪水上就能看得出来，谁更受重视。想让测试人员驱动开发，在目前的现状中有些难以做到。有时我想，前人已经总结出了那么多好的思想，确实应该多学学、多看看、多用用，但拿来的思想并不一定全适用，每种思想都有着自己的成长土壤，不是只要多施肥、多浇水就能长出好庄稼。有时，也要看看，植物的习性，是否更适应我们的环境。