|
1、简介项目管理者联盟
现在，即使在IT预算被大幅度地削减的情况下，IT管理人员的压力仍然在不断增大。同时，业务环境正以非常高的速度持续改变，这使IT艰苦奋斗，以便能够跟上这种变化速度。这些变化导致了以“快速发布和灵活而又高质量的维护为承诺”的敏捷软件开发方法论产生了很大的兴趣。talent.mypm.net
敏捷方法(XP、SCRUM、Feature-Driven Development)努力在软件开发过程当中减少变化带来的成本。例如，XP使用快速迭代计划和开发循环尽早地产生最有价值的特性。另外，XP中的持续的、系统化的测试确保高质量，尽早发现缺陷和相应的解决方案。转自项目管理者联盟
尽管敏捷方法带来了早期的一些成功案例，但还是有很多因素阻碍它们被广泛采纳。敏捷方法的倡导者经常发现：在应用开发中，对动态变更很难得到管理方面的支持。这些方法需要开发者、管理者和用户都改变他们工作和思考的方式。例如，XP实践中的结对编程、TDD、持续集成以及on-site 客户代表等是很难让人接受的。而且，这些方法论更倾向于以开发者为中心，似乎并不太重视管理角色。项目管理者联盟
然而，实践证明，加强管理是敏捷方法被成功采纳并应用的关键，而传统项目管理方法学和工具与这些新的敏捷方法缺少关联。而这种低关联性就是深层次问题的症状。这些深层次问题表现在：对于处理变化、控制、命令、组织、人员以及解决方案等方面的基本假设方面的不同。传统管理理论假设：talent.mypm.net
（1）管理变化是需要严格过程的项目管理者联盟文章
（2）分层级的组织结构是建立秩序的途径项目管理者联盟
（3）加强控制可以得到更好的秩序项目管理者联盟
（4）在“项目组”这个机器中，人员是可以互换的“零件”club.mypm.net
（5）问题主要是通过任务细分来解决club.mypm.net
（6）通过事前详细复杂的计划可以对项目和风险进行充分的预言，并被管理项目经理圈子
在这个上下文环境中，新方法论所表现出来的无序性、平等性和解决问题的无方向性就没有什么奇怪的啦。在这种传统管理与敏捷开发方法论之间的不重合性中，敏捷方法会被逐渐采纳。同样，这些假设的变化和敏捷方法过程中新的管理框架也是非常重大的需求。项目管理者联盟
在寻找这种新框架的过程中，我们强烈地认识到：出现了基于“复杂性理论”这个新学科的管理原则。“复杂性理论”这个新学科实际上在对现存系统进行研究的过程中产生的，它主要是探寻对人类自治行为的理解。.尤其是，我们已经开始将一种复杂适应系统(CAS)的概念融入到我们的管理假设与最佳实践中。项目管理者联盟
“复杂性理论”的科学家已经研究了现存系统中的集体化行为，如鸟群、鱼群、蚁群和蜂群。他们发现，当这些复杂适应系统中的个体拥有局部的战略原则和能力时，它们的集体化行为比个体的总和表现出更完全的秩序化、自组织性和更高的智慧性。这种CAS理论被成功地应用于经济和生命科学，现在也被用于管理方面。项目管理者联盟
这种CAS的概念使我们产生一种灵感：在XP团队中，项目经理也需要一系列的简单的指导实践来提供一种框架，并在这种框架下进行管理，而不是一系列的严格的指令。根据这此实践，管理者成为一名适应性领导者--确定方向、建立简单的产生式的系统准则，并鼓励持续反馈、适应性改变和协作。这个管理框架为团队提供一系列的内容来实现敏捷方法论，这些内容包括：bbs.mypm.net
（1）在团队管理中，组员是熟练地有很高价值的stakeholderservice.mypm.net
（2）自治性团队的集体能力是解决问题的基本机制www.mypm.net
（3）在不可预言的假设面前尽可能地使事前计划最小化，而加强适应变化的能力项目管理者联盟
2、问题：作为传统的任务分配者所面对的项目管理blog.mypm.net
传统软件生命周期开发方法论的产生是因为我们要控制不断增大的开发项目，以及对产生可靠的产品的工作量的评估和管理。这些方法论来源于建筑工程管理中的一些原则。结果，它们是强调可预言性的(在建一座桥时，工程设计师必须设计桥的每一个细节)，并且是一个线性开发周期(即需求、分析、设计、开发)。根据这种可预言性，它们沿用了确定性的简化了的方法，这些方法依赖于任务分解，并且是基于稳定性的(即稳定的需求分析和稳定的设计)。作为项目控制的一个手段，这种刚性表现为顺从性。项目经理圈子
在过去，一些公司使用这些方法，并且现在也可能在使用。对于许多来说，这些方法论只是增加成本和复杂性，却给人们一种错误的安全感――管理就是通过详细的计划、度量和控制来做事。巨大的成本被过早的计划浪费了。我们认识到快速的迭代式开发和从用户那里得到不断的反馈是今天项目达到成功的前提。项目管理者联盟
下面这个例子被公认为是原有方法论失败的代表案例：“伦敦救护系统”和“但佛航空行李系统”，巨大的成本超支和拖期。让我们来看一下Standish组织关于CHAOS的调查。在第一次调查中，成功项目18%，31%失败，53%挑战。在1998年的调查中有所提高，但也是26%成功，46%挑战，28%失败。研究还表明，在成功的这些项目中，它们的项目大小都控制在使用小团队就可以完成的级别上。这个结果很明显与敏捷方法论的原则一致。而且，我们还发现，很多已经确立的项目管理实践仍可应用于敏捷开发项目，只需要进行一些适应性改变并加强对其进行领导就可以达到。项目管理者联盟
当管理者在使用传统方法论努力控制项目时，技术社区开始用敏捷方法来对付传统管理带来的挫败以及对他们的产品品质和士气所带来的影响。例如，那时的XP就几乎完全聚焦于开发过程。当技术社区支持这些实践时，却很少涉及敏捷开发项目的管理方面。这就暗示着：由于XP团队开发并管理他们自已的任务，对于项目经理的需求就很小。这并不奇怪，公司管理一直怀疑敏捷方法，不太接受它们。管理者希望着一种场景出现：满屋子的开发者做着他们各自的事情。。。。而“eXtreme”这个词并没有什么意义。service.mypm.net
抛开具体的方法论，传统的项目经理经常是作为制订并控制主要计划的人，这些计划详细地描述了任务、它们之间的依赖关系以及为完成最终产品而必须的资源。然后，项目经理监控任务的状态，对计划进行必要的调整。这种做法是建立在这样的假设基础上的，即组员是可以互换的个体，就象同一型号的螺丝。项目管理者联盟文章
所以，对于熟悉传统方法论的经理，是很少有勇气在他们的项目中使用敏捷方法的。但这也不是必须的。事实上，敏捷方法的独立性使管理社区和技术社区在项目管理中趋于同一个焦点。项目管理者联盟
|
