按时完成既定目标是生产流程的最终目标，但是这只是软件项目管理生命周期中的一个环节而已。俗语有云：一年之计在于春、一日之计在于晨。其意义不是说越早做越好，而是阐述一个目标的实现，需要早规划。

　　项目开发管理，一般的流程是从PD(产品设计师)那里获取到需要去，实现的相对独立的一个大功能块，然后PM或TM评估资源、安排计划、建立分支、会同UI、DEV、QA完成功能并发布上线。如果用一个词来比喻这个模式，那就是“小步跑”。这里还有另一种项目开发管理模式，以周期的方式安排项目需求，由多方来评估项目内容的优先级，然后执行既定的项目内容，在特有的频度，安排UI、DEV和QA，完成打包的需求发布上线，用另一个妥帖的词来形容它就是“容器”。

　　首先，我们必需承认，存在即为合理，任何事务或方法的出现，都是在特定时候或场景下，能够满足需求而采用的技能，没有对错，只有是否合适自己。这里所谈到的两种模式都是软件开发管理中常见的方法，这里只是以个人的体会分析下其使用的场景和环境以及一些体会。training.mypm.net

　　“小步跑”

　　这个方法的特点是利用可用资源能快速响应产品变更需求。在这个要求下、需求的范围和周期对可用资源的依赖程度非常高，而在生产力中最关键的环节就是人，在遇到更高、更紧急优先级项目需要完成时、往往需要抽调其他项目资源，跨项目组支持，又可能导致其他项目出现风险。在实际过程中，对于需求方的最终需求，往往存在不确定性，从而导致这次项目的开发计划和资源需求在前期也不确定。在项目空闲期，PM或是TM必需协调好资源的负荷。

　　“容器”转自项目管理者联盟

　　这个方法特点是不以需求为核心，而是以特有的频度为周期，在周期内，拥有的资源达成共识后，从而只用考虑各个需求的任务量，一个团队同时可以支持二到四个子项目，，团队内部协调资源。由于项目是按照特定的周期发布，在更大的层面下考虑项目的优先程度，而在一个团队中则统一安排，但是对于临时项目或需要紧急处理的项目、则需要从当前项目中抽调资源负责，甚至于打乱发布计划，容器内存放了很多的子项目，这样的异常会影响面也很大。

　　逐渐的摸索，在较稳定的以产品为目标的项目计划安排中，执行“容器”的方式较为便捷，由于产品已经比较稳定，迭代的更新大多都是有计划的、范围和时间容易估算，紧急度相对不高，更新周期可以较长，在特有的节奏下开发、发布，也可以同时为其他的可能存在问题的项目预留出任务时间，避免风险的发生。而和市场、运营相关的项目，其本身存在需求不明、快速开发、紧急发布这样的快节奏，“小步跑”似乎是一个可以考虑的方法，但是，过于频繁的发布和过细的任务为项目，无形中也增加了项目成本，比如代码分支管理、测试资源等，这个可以以较小的“容器”管理配合紧急需求支持小组来达到目的，在高效、稳定的情况下完成商业需求的同时，也能实现自我质量的提升。