小议软件开发过程中两种项目管理方式.doc

小议软件开发过程中两种项目管理方式 按时完成既定目标是生产流程的最终目标，但是这只是软件项目管理生命周期中的一个环节而已。俗语有云：一年之计在于春、一日之计在于晨。其意义不是说越早做越好，而是阐述一个目标的实现，需要早规划。 项目开发管理，一般的流程是从 PD(产品设计师 )那里获取到需要去，实现的相对独立的一个大功能块，然后 PM 或 TM 评估资源、安排计划、建立分支、会同 UI、 DEV、 QA 完成功能并发布上线。如果用一个词来比喻这个模式，那就是“小步跑”。这里还有另一种项目开发管理模式，以周期的方式安排项目需求，由多方来评估项目内容的优先级，然后执行既定的项目内容，在特有的频度，安排UI、 DEV 和 QA，完成打包的需求发布上线，用另一个妥帖的词来形容它就是“容器”。 首先，我们必需承认，存在即为合理，任何事务或方法的出现，都是在特 定时候或场景下，能够满足需求而采用的技能，没有对错，只有是否合适自己。这里所谈到的两种模式都是软件开发管理中常见的方法，这里只是以个人的体会分析下其使用的场景和环境以及一些体会。 “小步跑” 这个方法的特点是利用可用资源能快速响应产品变更需求。在这个要求下、需求的范围和周期对可用资源的依赖程度非常高，而在生产力中最关键的环节就是人，在遇到更高、更紧急优先级项目需要完成时、往往需要抽调其他项目资源，跨项目组支持，又可能导致其他项目出现风险。在实际过程中，对于需求方的最终需求，往往存在不确定性，从而导致 这次项目的开发计划和资源需求在前期也不确定。在项目空闲期， PM 或是 TM 必需协调好资源的负荷。 “容器” 这个方法特点是不以需求为核心，而是以特有的频度为周期，在周期内，拥有的资源达成共识后，从而只用考虑各个需求的任务量，一个团队同时可以支持二到四个子项目，，团队内部协调资源。由于项目是按照特定的周期发布，在更大的层面下考虑项目的优先程度，而在一个团队中则统一安排，但是对于临时项目或需要紧急处理的项目、则需要从当前项目中抽调资源负责，甚至于打乱发布计划，容器内存放了很多的子项目，这样的异常会影响面也很 大。 逐渐的摸索，在较稳定的以产品为目标的项目计划安排中，执行“容器”的方式较为便捷，由于产品已经比较稳定，迭代的更新大多都是有计划的、范围和时间容易估算，紧急度相对不高，更新周期可以较长，在特有的节奏下开发、发布，也可以