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

　　【摘 要】在软件的敏捷交付项目中，依赖关系是极其常见的，比如在业务需求的层面即定义好的工作流强制依赖，或是交付团队的前后端依赖等。依赖关系的管理对于项目能否按时交付起着至关重要的作用，而一个未能按时向市场交付价值的软件项目，就是一个失败的项目。本文将从业务层面和组织层面分析，如何对交付项目中的强制依赖进行管理，降低交付风险。
　　【关键词】敏捷交付；依赖关系；项目管理
　　依赖关系是什么？
　　把大象放进冰箱需要几步？我们都知道，三步嘛。第一步，打开冰箱；第二步，把大象放进去；第三步，把冰箱关上。这三步是必须的，而且先后顺序不能颠倒，否则事情就没办法完成。我们把这种活动之间的先后顺序叫做依赖关系。
　　按照依赖的程度，依赖关系大概可以按如下方法分类：
　　1.可选依赖：一般人做西红柿炒鸡蛋会先炒鸡蛋，而先炒西红柿味道也不错。这种可以颠倒，无伤大雅的依赖关系，就是可选依赖。
　　2.强制依赖：盖房子必须先盖第一层才能盖第二层，这种固有的，没办法避免的先后顺序关系，叫做强制依赖。
　　可选依赖一般比较容易处理，而强制依赖往往考验一个人或一个团队的组织应变能力和管理能力。在敏捷交付项目中，依赖关系几乎是无处不在。比如业务层面，一个审批流中，一方如果没有提交成功，另一方就没有办法审核。比如组织层面，在前后端分离的团队中，前端的功能交付和后端是强依赖关系，后端API没有准备好，前端往往不能开始开发和测试。依赖关系对项目管理来说，影响最大的就是交付时间。而一个没办法按时向用户交付价值的项目，就是一个失败的项目。所以，依赖关系的管理对于项目的成功与否至关重要。那么，在敏捷项目中，业务层面和组织层面的强制依赖关系，我们该如何处理呢？
　　一、业务层面强制依赖关系的处理及案例
　　笔者在经历的第一个敏捷交付项目就遇到了业务强制依赖的情况。这是一个澳洲电信的项目，团队收到一个修改流量套餐的需求，大致工作流和设计如下：
　　这一工作流程中的各个步骤环环相扣，页面之间层层递进，没办法省略其中任何一步，是强依赖关系。而这个功能的开发工作量相对比较大，放在一个用户故事中很有可能没办法在一个迭代中完成。那么在依赖关系无法避免的情况下，如何尽量减少依赖，让几个团队成员同时工作，在一个迭代里完成这一功能的开发呢？
　　方法一： 通过合适的故事卡拆分，将依赖降到最低
　　考验业务分析师（Business Analyst）技能的时候到了。很多人都知道，用户故事的拆分需要遵循INVEST原则，其中I代表的就是Independent（独立的）， 即尽可能的减少各故事卡之间的依赖关系，让其相互独立。故事卡的拆分方式有很多种，笔者经过慎重思考选择了下图的拆分方法。即，将页面之间的强依赖关系抽离出来，体现在故事卡1、2和3中。当3完成以后，故事卡4和5就相互独立开来，互不影响了。这样能一定程度上减少该功能的开发时间，尽早交付其业务价值。
　　方法二： 将有依赖的故事卡按顺序完成的时间考虑到迭代计划中
　　在新项目启动，或团队接到新的业务需求时，往往会需要进行工作量估算，再按照团队速度大概估计需要多少个迭代来完成，即排迭代计划。排迭代计划有个简单粗暴的公式，即总故事点数/团队每个迭代能完成的故事点数（团队速度）=所需迭代数，这是理想情况。那如果业务需求内部有非常强的依赖关系，就要另当别论了。
　　参考项目管理中的关键路径法，相互依赖的故事卡从第一张卡开始到最后一张卡结束的时间，将影响整个功能何时交付。例如，上面案例中从用户故事1开始到用户故事4（关键路径）的所需时间如果超过一个迭代，尽管他们的故事点数总和看上去可以完成，在进行迭代计划时，也需特别考虑，延续到下个迭代去完成。
　　二、组织层面强制依赖关系的处理及案例
　　敏捷交付崇尚面对面沟通的全功能团队，即从需求到设计，从开发到测试的角色，都一个团队，所有问题当面沟通解决。好處之一就是从组织层面减少依赖关系，提高交付效率。
　　理想很丰满，而现实往往特别骨感。我们常常碰到前后端团队完全分离，而且不在一个国家的项目，前端开发完强依赖于后端API的开发进度。也有的项目UX设计师和团队不在一起，而且设计进度跟不上开发进度，团队每天猜测UX会如何设计，然后苦等UX上线催进度…
　　笔者最近参与的一个电信施工类APP项目就是前后端团队完全分离的，产品负责人在欧洲，客户方的后端开发在加拿大，需求分析，交互设计以及前端开发在中国。项目在需求分析，设计确认上强依赖于产品负责人的输入，而前端开发强依赖于后端开发的进度，而由于时差的关系，每天只能在有限的一两个小时内和对方远程沟通，未沟通到的点只能等到第二天。开发团队每天不是正在被阻碍，就是在担心即将被阻碍。这些依赖关系都太痛了！那可以如何解决呢？
　　方法一： 识别关键活动，提前规划时间节点
　　以某一功能需求的实现为例，从需求到设计，从前端到后端，可谓是端到端的强依赖。任何一个环节进展受阻，都会影响下游工作的按时完成，给功能的按时交付带来风险。为了更好的把握风险，需要将全流程中的关键活动识别出来，规划出时间节点，在交付过程中不断审查每个时间节点下的活动完成情况。
　　例如，某个功能需求需要在12月15日上线，那么我们可以根据各个前期活动的工作量倒推出用户验收测试需要完成的时间，后端和前端开发需要完成的时间等等，并可视化出来，作为参照来衡量目前的进度是否有风险。
　　方法二： 可视化具体的依赖关系，及时跟进
　　对于关键活动，我们需要把握时间节点，而对于具体问题，则可以进行工作拆分，将依赖关系一一对应，并可视化。
　　例如，对于前端开发依赖于后端API进展的这一问题，可以通过工作的拆分，将后端API和前端用户故事的依赖关系梳理出来，并面向全体成员可视化。按照依赖的严重程度，识别出优先级，优先级解决影响最大的依赖链，并实时跟进依赖源头的进展，比如在每日站会中追踪后端开发的工作情况。
　　方法三：识别和解决问题风险，适时向上升级
　　如果识别到关键活动不能按时完成，或后端进展不理想，前端开发即将被阻碍的风险，则需要及时明确出来，找到解决方案或推动风险的解决。而如果效果不理解，则需要适时向上升级，寻求更高层面的帮助。
　　例如，通过每日站会来明确风险，寻求帮助；部分敏捷项目会有Scrum of Scrums站会， 就是产品负责人，技术负责人，交付负责人等关键角色一起开的站立会，这是一个升级问题和风险的最佳场合。当然也可以通过邮件，slack群聊等各类方式将风险和问题提出来，群策群力，或者升级给各个负责人，依靠更强大的力量来解决。
　　三、结语
　　你也许会发现，传统项目管理的很多方法论，比如关键链和时间节点管理，还有敏捷管理中提倡的可视化等，在处理依赖关系上都非常好用。我常常说，不管是白猫还是黑猫，能捉到老鼠就是好猫。灵活运用各类方法，管理好依赖关系，你的敏捷交付项目就成功了一半了啦。
　　【参考文献】
　　[1] Jim Highsmith. Agile Project Management[M]. Qinghua Pubshiing House， 2005，7.
　　[2] Fowler， Martin， and Jim Highsmith. The Agile Manifesto. Soft-ware Development 9[C]. No. 8 （August 2001）： 28-32
　　[3] Project Management Institute. A Guide to the Project Management Body of Knowledge[R]. 2000 ed. New Square. PA： Project Management Institute， 2000.