该帖子同步发自：(wcabt的博客  访问该博客)

　　夫战，勇气也。一鼓作气，再而衰，三而竭。这是《曹刿论战》中的一句话，意思是作战时第一次击鼓能激起士兵的勇气，多次击鼓后，士兵的锐气就慢慢减弱了。在IT世界里，每一个项目，都可谓是一场战争，这场战争同样需要团结、勇气和毅力才能胜利。

　　然而，很多项目经理不懂的再而衰，三而竭的道理，让IT战士们在前期拼尽了精力体在后期却节节败退，甚至丢掉了项目。很多人也许觉得这只是一个玩笑，但亲历过亲历过它的勇士明白赢得这场战争是多么的艰难。作为项目经理，一定要懂得把握项目的节奏，这才是项目成功的王道。

　　把握项目的节奏，你可以参考以下几点，但不是绝对。

　　持续集成

　　有的人习惯完成一个功能提交一次代码，有的人习惯一周提交一次代码，有的人习惯一天提交一次代码，无论你选择那种方式提交代码，你所做的工作都是在持续集成。只不过不同的是根据你提交代码的频率不同，系统集成的风险也有不同而已。没有绝对的理论证明哪种方法是最正确的，适合自己的就是最好的。除了在主版本上提交和维护代码之外，也可以开辟分支版本维护每个单独的版本，以应对上线等工作。

　　构建自动化冒烟测试

　　不管使用持续集成与否，都应该为项目构建自动化冒烟测试，因为冒烟测试可以证明构建的版本没有问题，而且可以在第一时间发现构建版本出现的问题，从而发现是什么地方扰乱了团队的节奏，帮助项目经理将项目带回正常的节奏。

　　按功能实现，而不是按架构

　　除了理论派的那帮疯子外，没有人愿意按照架构实现，因为在系统集成完毕之前，你不知道开发完的哪些功能可以正常运行。而且按照架构实现，将会使持续集成变的相当困难，也无法及时的进行构建和测试，项目经理也就看不到完整的功能，不能及时的回馈开发人员，这会使得项目周期变的非常长。基于以上这些架构实现的缺点，选择按功能实现的优势就不说了。

　　按功能价值实现，而不是功能难度

　　在按照功能实现时，要先实现最有价值的功能，而不是最具风险的功能。在某些条件下，也许根本不用实现那些高风险的功能，项目就可以交付了。作为项目经理，分清功能的优先级，是项目成功的必要条件。

　　代码复查

　　当前已经有很多种代码复查方式，包括结对编程、伙伴复查、同行复查、走查、正式代码检查等，你一定要记得进行代码复查，因为你不知道什么时候，哪个工程师不小心使用了错误的编码方式，扰乱了系统的架构，而后面的人却复用了这个人的代码结构，从而使架构混乱。复查的形式并不重要，重要的是一定要记得代码复查。

　　代码重构

　　很多人觉得代码重构是一件可耻的事情，实则不然。在某一个阶段的赶工之下，可能会有很多冗余的代码，这些代码虽然在功能上是可通的，但是却会扰乱系统的架构，从而对后续系统的开发及维护工作造成很大的干扰，这时候就必须要考虑代码重构。富有经验的项目经理会在合适的时间选用合适的方式进行重构，而不是照本宣科的重构。

　　分离需求与GUI设计

　　将GUI放在需求分析说明书里，只是作为一个参考，引导用户使用系统解决他们的问题，并非是系统的最终模型。项目经理如果在需求中使用精美的GUI，并以此作为最终要实现的功能，就会使项目陷入需求的泥潭，失去项目的节奏。

　　将加班放在上线前的阶段

　　在国内，尽管加班已然成为IT界的常态。但是，我依然要提醒各位的是，如果必须要加班，请将加班放在上线前的阶段。因为这个阶段会频繁的与客户打交道，在这个阶段及时的修复Bug，能够影响客户对团队以及项目的评价，从而尽早的交付项目。

　　有些项目经理在项目一开始就打疲劳战，以至于项目交付时，整个团队都很萎靡，关键的Bug不能及时交付，影响客户对系统的评价，从而延迟了系统的交付。

　　把握项目的节奏，并不是让项目匀速行驶，项目经理可以根据自己的需要适时地启动加速度与减速度，让项目按照规划的节奏行驶，驶完项目的里程。

　　本文出自 “尘风随影的天空” 博客，请务必保留此出处http://genuinecx.blog.51cto.com/2890523/1123620