【PM】【进度】：把握项目节奏的方法

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

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

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

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

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

 

持续集成 

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

代码重构

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

 代码复查

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

 

分离需求与GUI设计（这个算常识了）

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

构建自动化冒烟测试

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

将加班放在上线前的阶段

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

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

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