|
案例背景项目管理者联盟
黄冲是A公司的一位资深项目经理，负责为B公司创建一个企业网站。该项目的难点之一是权限审批系统，客户一开始向黄冲描述说系统不复杂，但经过详细的需求分析，黄冲发现项目并不像客户开始描述的那样简单。因为客户所在企业有100多个部门和车间，所以客户要求按照部门和车间对网站的用户进行管理。同时，权限管理是层层授权的，非常复杂。项目管理者联盟
一开始，黄冲采用瀑布式方法来管理项目。需求文档准备完毕后，黄冲安排了开发人员和设计师实施此项目。最终，项目很顺利地通过了客户的检查，开始部署到服务器上进行试运行。但当部署到真实环境中，系统中存在的问题开始暴露出来。PgMp.mypm.net
问题主要集中在权限系统上，项目需要重大调整。经过两方领导的多轮磋商，初步决定两条腿走路。一方面用最短的时间修改现有系统，保证客户企业新产品发布时，网站能够正式推出。另一方面重新开发一套新系统来替换现有系统。项目管理者联盟
在开发新系统过程中，黄冲汲取教训，决定引入敏捷开发。同时，在黄冲的强烈要求下，客户企业决定安排专门的产品负责人参与进来，这样才能保证新系统的开发不至于重蹈覆辙。在敏捷过程中，黄冲率领项目组成功使用了多种敏捷方法和技术。项目管理者联盟
用户故事项目管理者联盟
黄冲首先和客户方派来的代表一起模拟权限系统的运作方式，最终得到了一个和最初设计功能近似但具备充分实用性的权限系统设计方案。在黄冲和客户代表的模拟过程中，开发人员迅速创建一个符合演示过程的权限系统来验证权限系统的可行性。项目管理者联盟
快速决策项目管理者联盟
经过A公司的艰苦努力，客户企业最终决定由一位领导来专门负责该项目的决策。所以大部分决策可以在较短的时间内获得反馈意见。而客户代表在整个新系统开发期间，几乎一半时间都在A公司上班。这也保证了A公司和B企业客户之间的充分沟通。项目管理者联盟
单元测试talent.mypm.net
为了保证子系统的修改不至于影响到全局系统，黄冲与客户代表一起编写了一些重要的单元测试。这些单元测试的编写全程没有让开发人员参与，所以更能够反映客户的意图。同时测试重点也更偏重业务领域，而不是程序行为。转自项目管理者联盟
通过运用敏捷方法，新系统一个月就开发完成了。除了权限系统是完全重做的，其他部分大多使用了已有系统的结构和代码。这个结果获得了客户方的高度认可，项目最终获得了迟来的成功。
案例分析项目管理者联盟
这个案例包含了正反两方面的成功经验和失败教训。首先我们来看一下成功经验。项目管理者联盟
过程定制项目经理圈子
在案例中，黄冲做得比较好的一点是他没有完全照搬所有敏捷模式，而是针对项目情况进行了过程定制。既然敏捷开发强调的就是应对变化，那么敏捷开发过程也是可定制的。例如，结对编程、持续集成这类技术对公司和开发人员的要求都很高，如果要一一达标，确实不易。所以，有选择性地进行敏捷开发，是比较可取的方式。正如案例中所提到的，黄冲就采用了用户故事、单元测试等简单有效的方法。项目管理者联盟
对于用户故事方法，除非客户充分配合，否则是难以实施的。这个时候应该在前期将工作做细致，尽可能明确客户的大部分需求。然后以最快的速度做出原型系统，并与客户进行沟通以获取反馈意见。blog.mypm.net
同时，即使采用用户故事，对于较复杂的系统，也应该深入客户企业，了解客户企业员工的工作流程。因为有时候客户方负责项目的人士很可能会按照自己的想法渲染实际的工作流程或者环境，这对项目的中后期是非常不利的。club.mypm.net
充分沟通项目经理圈子
不管采用何种开发模式，充分沟通是保障项目成功的关键因素之一。沟通越充分，双方协作程度越高，项目就会进行得越顺利，成功的几率也更大。敏捷开发是通过小步前进的快速迭代来逐步逼近项目最终目标的，所以沟通就更为重要。否则一次迭代完成后，却得不到及时和正确的反馈，那么项目也无法进行下去。training.mypm.net
案例中，黄冲要求客户企业安排专门的产品负责人参与此项目是一个关键点。这就像“敏捷准则”中准则4所说的“项目过程中，业务人员与开发人员必须在一起工作”，这保证了产品最大化传递客户价值。又如准则6提到的“无论是团队内还是团队间，最有效的沟通方法是面对面的交谈”。面对面交谈不仅是“高带宽沟通”，更营造了团队与客户协作互信的氛围，这种氛围是敏捷项目顺利开展的必要保证。项目管理者联盟
在国内，一个项目要做得顺利，项目负责人还要懂得“做人”。和客户方负责人、联系人保持良好的关系是非常重要的，否则他们的一句话就可能让项目的开发成本增加不少。情商、协作、谈判、积极倾听、解决冲突这些软技能虽然远远超出了技术领域，但对项目的成功实施有时起着决定性的作用。项目管理者联盟
对于一个最初运用瀑布式方法的软件项目，该案例也同样有很多失败教训可以借鉴。项目管理者联盟
繁重的前期规划PgMp.mypm.net
案例中提到，一开始项目用的是需求文档的形式，这些需求文档后来证明实际上是脱离企业应用实际的，对客户的价值不大。这实际上与敏捷宣言中的“工作的软件高于详尽的文档”是相违背的，充分暴露了传统瀑布式方法的局限性。项目管理者联盟
|
