敏捷软件项目管理之我见

敏捷只是理念，实践要有自己的一套！

敏捷软件开发中最常用的 Scurm 实践，在实际操作中各家的效果不一，说明其中还有很多的细节是有问题的。

个人认为，在 User story（用户故事） 和 Developer 开发人员的 Task（开发任务） 之间存在着一个无法顺畅衔接的裂隙，通常 User story 是由 BA （业务分析师）来设定的，根据业务的需求，将希望达成的产品需求分解为一个个独立的用户故事，而这些用户故事分解的维度通常是从用户使用的角度来描述的，而这一系列的用户故事真正要达成实现，所要具体完成的开发任务却可能是另外一个全新的维度来完成的，从开发人员的角度来说，从这个具体开发工作的维度来分解任务也许更加符合项目开发流程的进展过程。

举例来说：

假设要实现一个产品列表的功能，用户故事可能会描述为用户需要点击产品列表菜单项目进入产品列表界面，看到分页的产品列表各项：名称、分类、价格、库存、当日销售量、当月销售量等，每页10条，有个按名称和分类查询的功能表单。

然而，开发团队真正要实现这个功能时，具体的分工则可能根据项目系统的架构特点、组员技能和需求细节等有所不同。比如通常可能会是这样的分工：

• A（数据库管理员）：在数据库中给产品表建立相应的索引以便更高效查询，同时完成查询产品并分页的 SQL 语句或存储过程，交给甲相应的调用命令；
• B（后端开发）：实现从数据库到 RESTful 接口产品列表及分页的程序代码；
• C（前端开发）：实现列表组件及分页组件的开发，并应用于产品列表界面-列表模块的代码中；
• D（前端开发）：实现查询组件及分类下拉菜单组件的开发，并应用于产品列表界面-查询模块的代码中；
• E（前端架构师）：选择合适的前端技术框架，建立公共组件库，实现一套可全局调用的机制供开发人员使用。
• F（后端架构师）：选择合适的后端技术框架，完成并初步实现权限、缓存、连接池等服务器相关技术方案，实现一套获取数据并暴露接口的开发模式和规范供开发人员使用。

横向与纵向的裂隙

可以看到，即使是这样一个相对简单直观的用户需求，最终要达成高质量的开发实现，需要做的工作划分维度是按技术分层横向划分的，而相对的 BA 在项目管理平台（如 JIRA）里书写 User story 时却是从用户使用的角度一通到底纵向描述的。

一个横向，一个纵向，天生就是不匹配的，难怪整个团队运作起来总觉得哪里有点别扭，而最终导致项目管理平台也好，Scrum 实践也好，都不能很好地帮助开发人员更高效地完成开发工作，也不能很好地把控项目实际开发进展情况，无法合理安排项目进度。通常在项目实际运行中，就又回到了项目经理 Scrum master 催逼进度，开发人员急于应付而欠下大量技术债的窘境。

通常 Scrum 实践中的问题

一般项目开始，项目小组成员会就需求评估点数，而这个时间就是挨个 Story 去过一遍，给出的点数是小组共同的感觉，通常很粗，很多小组成员面对很多 BA 划分出来的 Story 不知道该怎么去评估，就人云亦云看别人给多少点自己就给多少点。而很多 Story 实际很难反映出背后的很多复杂技术工作内容，特别是项目初期或中途有较大的技术架构变化时，这种情况就更严重。

项目进行中，各个 Story 齐头并进，先后次序不清，资源争夺的情况也时有发生，而多数 Scrum 都只能靠沟通来解决这类混乱问题，从而导致开发人员处于不良多工状态，经常被打扰，无法专注开发，效率非常低，时常会有开发人员感叹今天一天好像忙忙碌碌（开会、沟通、帮同事解决问题、紧急插入一些开发任务等），但正经的开发任务却没多大进展。

同时因为每个 Sprint 都被 BA 的 Story 需求 而牵制影响，团队会对技术债的偿还，基础架构的改善等工作缺少时间和关注度，导致债务越积越多，整个项目架构、代码等深层次的、隐形的问题越来越多，到后期导致新加功能、修改 bug 都变得越来越艰难，间接引起开发人员离职，新来的开发人员又难以接手，逐渐进入恶性循环，直到开发成本已经大于项目的收益时，即走到死亡终点——项目被废弃。

新的实践想法

因此，我一直在想是否有一种方式可以顺畅地从用户需求 Story 分解到一个个开发人员非常明确的具体任务上，如果是之前已经做过的类似工作，开发人员可以相对清晰地知道工作量和难度，也可以给出相对靠谱的时间预估，如果是之前没做过的研发性质的任务，也可以清晰地给定一个时间，超过这个时间就放弃（使用 Plan B）或再想别的办法，这样将更有利于项目进度的把控。

这中间就需要有经验丰富的架构师或项目经理（了解开发技术以及团队人员开发能力特点等），来将这些需求 Story 拆解为具体的开发任务（由一个开发人员在一段时间不依赖外界因素可以持续完成到某个阶段性的目标，同时产出一些具体结果的工作内容划分为一个原子性的开发任务），并且与小组开发人员商量分派到具体的人员名下，将所有任务按每个人分组并排出优先次序，评估出每个任务的大致耗时，用关键链的项目管理思想画出项目的开发计划图，安排好相关任务的资源依赖，找出项目这一阶段 Sprint 的关键链，在各个关键节点加上时间缓冲等，具体可以参考 TOC 管理的项目关键链管理方法，这样应该就可以更好地保证项目的进度和开发质量了。同时这样操作后可能会带来很多附加的好处：

• 因为采用关键链的项目管理方法，每个开发人员的工作任务都是单线程按优先次序排开的，同时考虑了相关资源和前置任务的完成，所以开发人员实际做任务时不会卡壳，也很少被打扰，自然也会更高效，同时代码质量也更好。
• 因为是由架构师和项目经理安排计划，因此会考虑做某些任务时加入偿还技术债的工作，分配适当的时间，安排合适的人员等，从而不断减少之前的技术债，改善系统架构和代码质量，更进一步带动组内开发人员采用更好的实现方式，不断改善项目质量和开发效率，进入良性循环，从而使项目长期高效地向前发展。

关键链敏捷

有人可能会说这样不是不象敏捷了？不象 Scrum 了？我觉得敏捷只是个大的指导方针，具体的实践其实是可以百花齐放的，只要最后能够更好地帮助项目高质量准时交付，也许我们也可以新创一种“关键链的敏捷”实践嘛！