SCRUM，当下通行的一种敏捷开发方法；精益，一种有效的生产方法；这二者和项目管理的结合将会在软件开发项目中产生怎样的作用？本文从实战的角度讲述了从传统项目管理方法到精益敏捷项目管理方法的一次尝试。

1      项目背景

1.1      项目类型

某软件系统产品化开发项目。

1.2      敏捷方法

团队实行敏捷SCRUM框架已经9个多月。但是在使用过程中，逐步发现了一些实际工作场景有SCRUM框架不能很好解决的问题，敏捷的继续推行需要进一步改进。

1.3      团队组织

总计16人。其中包括开发9人，测试4人，管理3人。根据所开发的软件系统特点，将全员分成6个小组，分别是管理组，开发组A, 开发组B，开发组C，测试组，产品组。

2      SCRUM应用小结

2.1      优势小结

项目团队从全面引入敏捷SCRUM已经历时9个月有余，在这9个月中，团队较严格的依照SCRUM框架，进行了公司产品化软件的开发，完成了产品DEMO版本的开发，并参加了业界展会获得用户的初步认可。笔者认为SCRUM给团队带来好的改善如下：

1. 团队项目流程方法清晰明确。较之之前的工作流程，SCRUM框架清晰，简洁，能够比较大的程度上减少繁琐的流程制度给研发团队带来的迟滞。

2. 团队目标感增强。每一个sprint迭代，通过计划会议，都会使团队对sprint时间盒内要完成的工作目标异常清晰。

3. 团队沟通意识加强。SCRUM要求团队是高度自主，自组织管理的。大家在这个组织原则下可以进行更大可能的积极沟通，尤其是研发和测试人员，积极的沟通交流极大地提高了工作效率。

4. 团队成就感增强。每一次sprint评审会议，团队成员都会自豪的展示自己的工作成果，从而提升了成员的自信心和工作热情。

5. 产品质量加强，实现了快速增量交付。周期一致，有节奏感的sprint迭代，严格透明的评审，使团队中的每一个人都能够时刻关注工作质量，从而加强了产品质量。

      整体来说，通过9个多月SCRUM框架的推行，可以说敏捷的工作理念已经渗入到整个项目团队，整个团队的工作绩效也得到了大幅度提升。而且从始至终，大家基本都保持了积极参与，热情高涨的工作状态，这对于以创造性为主要特征的研发项目团队来说，无疑是最重要的。

2.2      不足小结

这里的不足指的不是SCRUM框架的不足，主要是指SCRUM框架与本项目团队具体使用的落地执行过程中组织结构所面临的问题。在这里，先向大家简要介绍一下项目团队的情况。

如上图所示，从组织职能角度，本项目团队组织属于项目型组织，包括公司的研发部，测试部，产品部，根据项目计划，各部门人员在项目中的工作时长互有不同。这样，就存在一个显著的问题，即各部门的项目任务与各部门的运营工作有时会交叉在一起，存在的主要问题如下：

1. sprint迭代内的任务有时会受到项目外技术支持相关工作的影响。

2. 高度强调的团队自主性与原有职能架构的冲突，导致组织管理的过度弱化。

3. 产品的需求完全由产品经理（Product Owner职责）负责，Product backlog条目的分析明确进展有时候不能做到与Sprint 迭代并行，从而导致影响迭代节奏。

针对上述关键问题，结合SCRUM开展来的经验总结，决定持续改进团队的敏捷工作方式。

3      精益--SCRUM

3.1      精益-敏捷管理

彼得.德鲁克认为，检验企业组织是否有效基本的标准要看这个组织是否能产生绩效，确切的说是能否产生经济效益。同理，衡量一个项目团队成功与否最直接的标准是看这个项目团队是否产生了客户接受认可的项目交付物。

上升到组织运营的角度而言，针对本项目团队sprint迭代任务与项目外技术支持任务的冲突问题，我们只有一个处理冲突的标准，即看哪个任务能够更有效地为组织产生绩效？因此，就本项目团队的敏捷方法来说，我们需要改进SCRUM团队不受外界干扰的规则，需要某种新的工作方法来解决这种冲突问题。

精益-敏捷管理重视价值流的管理及对人的领导。价值流是一组为客户增加价值的活动，从最初需求开始，到交付价值为止。我们可以把团队负责的所有任务都融入到价值流中，通过优先级的分析，在我们的迭代中进行筛选、执行。

SCRUM团队要求自主性、自组织管理。但是，我们也应该认识一个事实，首先，大多数的团队成员因为自身能力，工作经验的参差不齐，虽然经受了统一的SCRUM培训，但是每个人对敏捷、对SCRUM的理解还是存在不同的差别，所以各团队成员对敏捷方法论的认同、理解需要引导；其次，业务、技术层面具体的工作，更需要团队中较专业的技术人员进行指导，所以，SCRUM的执行，需要团队在管理及业务技术方面有不同层次的组织把控，这一点，精益-敏捷管理从对人的领导方面进行了清晰的诠释。

软件项目的需求管理一直是软件开发中存在的大问题，SCRUM中PO的角色责任可谓大矣。为了更好的促进需求管理，精益—敏捷中提到了产品协调小组的概念。

产品协调小组负责跨团队的问题，可以包括常任成员和轮值成员，产品协调小组的工作持续整个项目生命期，代替SCRUM中Product Owner的职责。

针对以上几个问题，在精益-敏捷中寻找解决方法。

3.2      精益—SCRUM解决方案

根据敏捷--精益—SCRUM的方法，原项目团队组织结构转变如下：

二图相比较，明显的改变如下：

1. 重组了管理组，用以加强对整个项目团队的管理及把控，并负责从工作方法，技术实现，整体把控上对团队进行领导。

2. 设立了产品协调组，用以代替PO的角色。

敏捷—精益—SCRUM项目管理方法具体的指导规则如下：

• 遵守敏捷项目生命期模型。

• 遵守SCRUM时间盒限定。

• 遵守SCRUM的会议规则。

• 遵守SCRUM看板的使用规则。

• 迭代交付物的评审仍然通过评审会议进行。

• 糅合精益-敏捷的管理方法。

• 管理者引领和教导团队，管理层与团队协同合作。

• 迭代的交付重视客户和企业的价值，同时关注延误带来的成本。

• 支持产品管理组织（产品协调小组），团队向产品负责，产品牵头人设置优先次序，并与团队一起去发现和构建需求。

• 迭代内的工作任务依据其价值可以进行调整。团队依据工作任务可以进行调整。

4       后记：

这篇文章记录的是几年前第一次带领团队实践SCRUM时遇到的问题：SCRUM中的团队结构在实际使用中因为其简洁性无法应对一些情况。当时采用的解决方法是在SCRUM中糅合了精益管理的内容。现在想来，精益敏捷的系列方法理念应该应用在所有团队的敏捷转型过程中，只依靠单一的方法论是不足够的，因为，我们要应对的实际场景复杂得多。