敏捷交付项目中依赖关系管理.docVIP

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
敏捷交付项目中依赖关系管理

敏捷交付项目中依赖关系管理   【摘 要】在软件的敏捷交付项目中,依赖关系是极其常见的,比如在业务需求的层面即定义好的工作流强制依赖,或是交付团队的前后端依赖等。依赖关系的管理对于项目能否按时交付起着至关重要的作用,而一个未能按时向市场交付价值的软件项目,就是一个失败的项目。本文将从业务层面和组织层面分析,如何对交付项目中的强制依赖进行管理,降低交付风险。   【关键词】敏捷交付;依赖关系;项目管理   依赖关系是什么?   把大象放进冰箱需要几步?我们都知道,三步嘛。第一步,打开冰箱;第二步,把大象放进去;第三步,把冰箱关上。这三步是必须的,而且先后顺序不能颠倒,否则事情就没办法完成。我们把这种活动之间的先后顺序叫做依赖关系。   按照依赖的程度,依赖关系大概可以按如下方法分类:   1.可选依赖:一般人做西红柿炒鸡蛋会先炒鸡蛋,而先炒西红柿味道也不错。这种可以颠倒,无伤大雅的依赖关系,就是可选依赖。   2.强制依赖:盖房子必须先盖第一层才能盖第二层,这种固有的,没办法避免的先后顺序关系,叫做强制依赖。   可选依赖一般比较容易处理,而强制依赖往往考验一个人或一个团队的组织应变能力和管理能力。在敏捷交付项目中,依赖关系几乎是无处不在。比如业务层面,一个审批流中,一方如果没有提交成功,另一方就没有办法审核。比如组织层面,在前后端分离的团队中,前端的功能交付和后端是强依赖关系,后端API没有准备好,前端往往不能开始开发和测试。依赖关系对项目管理来说,影响最大的就是交付时间。而一个没办法按时向用户交付价值的项目,就是一个失败的项目。所以,依赖关系的管理对于项目的成功与否至关重要。那么,在敏捷项目中,业务层面和组织层面的强制依赖关系,我们该如何处理呢?   一、业务层面强制依赖关系的处理及案例   笔者在经历的第一个敏捷交付项目就遇到了业务强制依赖的情况。这是一个澳洲电信的项目,团队收到一个修改流量套餐的需求,大致工作流和设计如下:   这一工作流程中的各个步骤环环相扣,页面之间层层递进,没办法省略其中任何一步,是强依赖关系。而这个功能的开发工作量相对比较大,放在一个用户故事中很有可能没办法在一个迭代中完成。那么在依赖关系无法避免的情况下,如何尽量减少依赖,让几个团队成员同时工作,在一个迭代里完成这一功能的开发呢?   方法一: 通过合适的故事卡拆分,将依赖降到最低   考验业务分析师(Business Analyst)技能的时候到了。很多人都知道,用户故事的拆分需要遵循INVEST原则,其中I代表的就是Independent(独立的), 即尽可能的减少各故事卡之间的依赖关系,让其相互独立。故事卡的拆分方式有很多种,笔者经过慎重思考选择了下图的拆分方法。即,将页面之间的强依赖关系抽离出来,体现在故事卡1、2和3中。当3完成以后,故事卡4和5就相互独立开来,互不影响了。这样能一定程度上减少该功能的开发时间,尽早交付其业务价值。   方法二: 将有依赖的故事卡按顺序完成的时间考虑到迭代计划中   在新项目启动,或团队接到新的业务需求时,往往会需要进行工作量估算,再按照团队速度大概估计需要多少个迭代来完成,即排迭代计划。排迭代计划有个简单粗暴的公式,即总故事点数/团队每个迭代能完成的故事点数(团队速度)=所需迭代数,这是理想情况。那如果业务需求内部有非常强的依赖关系,就要另当别论了。   参考项目管理中的关键路径法,相互依赖的故事卡从第一张卡开始到最后一张卡结束的时间,将影响整个功能何时交付。例如,上面案例中从用户故事1开始到用户故事4(关键路径)的所需时间如果超过一个迭代,尽管他们的故事点数总和看上去可以完成,在进行迭代计划时,也需特别考虑,延续到下个迭代去完成。   二、组织层面强制依赖关系的处理及案例   敏捷交付崇尚面对面沟通的全功能团队,即从需求到设计,从开发到测试的角色,都一个团队,所有问题当面沟通解决。好?之一就是从组织层面减少依赖关系,提高交付效率。   理想很丰满,而现实往往特别骨感。我们常常碰到前后端团队完全分离,而且不在一个国家的项目,前端开发完强依赖于后端API的开发进度。也有的项目UX设计师和团队不在一起,而且设计进度跟不上开发进度,团队每天猜测UX会如何设计,然后苦等UX上线催进度。。。   笔者最近参与的一个电信施工类APP项目就是前后端团队完全分离的,产品负责人在欧洲,客户方的后端开发在加拿大,需求分析,交互设计以及前端开发在中国。项目在需求分析,设计确认上强依赖于产品负责人的输入,而前端开发强依赖于后端开发的进度,而由于时差的关系,每天只能在有限的一两个小时内和对方远程沟通,未沟通到的点只能等到第二天。开发团队每天不是正在被阻碍,就是在担心即将被阻碍。这些依赖关

文档评论(0)

3471161553 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档