1、敏捷开发在大型软件项目管理中的应用探讨一、敏捷开发概述Scrum 是一种迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum 在英语的意思是橄榄球里的争球。虽然Scrum 是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法。Scrum 是迭代的、增量型的流程，其流程如 1所示。Scrum 构造的产品迭代周期为 Sprints,工作的迭代时间一般为一到四周，并且是相互衔接的。Sprints 是有固定的周期，结束于固定明确的日期，无论该工作完成与否，从不延长。在每一 Sprint 的起始阶段，一个多职能的团队从已优先化的要求列表（下文中称 Product Bac
2、klog）中挑选若干项目，并承诺在 Sprint 的末期完成这些项目。在 Sprint中，任务的内容不会变化。每一工作日，团队成员互相通告工作进度，并更新简易的剩余工作量直观表示图表。在Sprint 的末期，团队将对这一阶段工作结果作一展示并取得相关的反馈，为下一 Sprint 做好准备。Scrum 强调生产可以使用的产品，意指在 Sprint 的末期产品的“完成”；在软件方面，是指编码已经被检测并可以随时交付使用。图 1 Scrum 周期图在 Scrum 中有三个基本的角色：产品所有者 (Product Owner)，开发团队和 Scrum Master。1.产品所有者（Product Ow
3、ner）产品所有者（Product Owner）负责取得产品最大的商业价值，收集相关于产品的所有信息。从客户或产品的终端使用者，开发团队成员和项目管理者中获取并将信息转化为优先权项目列表。在一些情况下，产品所有者 (Product Owner)正是客户本人；在另一些情况下，客户可能是有不同需求的成百上千的人。产品所有者(Product Owner)这一角色在许多企业中是由产品经理或产品市场经理担任。2.开发团队开发团队构建客户将会购买的产品：比如报表或软件。Scrum 团队是“多功能”的。它包括交付每一 Sprint 中的随时可交付产品所需的各类专门人员，并且它是有很高自律性和责任性“自我管理
4、”的团队。团队决定承诺完成哪些任务和完成承诺任务最好的方法。Scrum 团队通常包括五到十个成员，然而团队大到 15个成员和小到 3 个成员也有很好的收效，一个软件项目的开发团队包括程序员，界面设计师，检测员和研究人员。开发团队不仅构建产品，他们也向产品所有者 (Product Owner)提供让产品尽善尽美的建议和想法。团队成员可以将其时间划分给 Scrum 项目和其他的项目，但是如果团队成员能专注于 Scrum 项目开发则效率更高。团队内部成员也可以在不同 Sprint 中变化，但是这样会减少整个团队的生产效率。3.Scrum MasterScrumMaster 的任务是以任何方式帮助整个
5、团队取得成功。ScrumMaster 不是团队中的经理；ScrumMaster 的职责是服务整个团队，帮助团队铲除壁垒而取得成功，协助团队会议，并支持 Scrum 的实践。在一些团队中会有某一人专心致力于担任 ScrumMaster，而另一些小型团队可以采用其中一个成员兼职担任（此人会适当减少日常工作量）。一个好的 ScrumMaster 可以来自不同的背景和学科：项目管理，工程技术，计算机或者电子工程等等。ScrumMaster和产品所有者 (Product Owner)不应是同一人；有时，ScrumMaster 可能会号召拒绝产品所有者 (Product Owner)（例如，他们有时会在某
6、一 Sprint 中期试图加入新的条件）的要求。不同于项目经理，Scrum Master 不会指示和分配工作。他们只是协助流程的实施，推动团队自我组织和管理。二、大型软件项目管理中应用敏捷开发的问题探讨传统认为敏捷开发主要适用于小规模团队完成的中小型项目。大型软件项目从需要的业务知识背景、研发团队规模、系统架构等方面都有很高的要求，需要在应用敏捷方法的过程中，实施一系列改进。我们尝试从以下几个方面讨论大型软件项目中应用 Scrum 中可能遇到的问题及解决方法。（这里我们假设该大型软件项目团队规模在 40 人左右，该项目是整个用户系统中的一部分，其他还包括 IT基础设施项目）1.产品负责人的确定
7、选择产品负责人是个很有难度的事情，在大型项目中，由于涉及的知识面非常广，很难找到一个人能够有时间、具备领域知识、而且有权利设置需求优先级。因此，可以由两个（或以上）业务分析师来一起承担产品负责人的职责。他们有充裕的时间、充足的项目经验和丰富的业务知识，足以担当起产品负责人的角色，为多组客户充当优秀的代理。有关优先级的和范围的高级决策，是这些产品负责人共同通过会议的方式决定的。2.团队的构建关于团队的规模，传统 Scrum 一直认为 5-9 人是一个最佳范围，团队过小，管理成本会过高，团队过大，则不利于团队的沟通，降低团队工作效率。在 40 人团队规模下如果要继续有效的使用 Scrum 方法，唯
8、一的办法就是分拆团队，采用 Scrum of Scrum 的方法。相对来说，拆分团队并不难，当团队扩大以后，自然就形成了一个分割，人数控制在 5-10 人左右，在这个组内再任命一名技术、管理能力均衡的成员作为这个小组的Scrum Master 管理所在的子团队，同时听命于项目经理。但是，在拆分团队过程中，也要注意一些问题。（1）跨智能团队最容易发生的问题是按照工作职能划分子团队，如：用户界面程序员一组，中间层程序员一组，数据库员一组，这样的架构其效率很低。应当淡化团队分工，按照业务功能形成跨职能团队。这样，团队里面的人仍然干差不多相同的活，但是现在能够关注整个功能，而不是某一层上功能的一部分，
9、虽然会引起团队间一些集成的问题，但是会使端到端的功能实现得更快。（2）团队技术共享由于采用迭代开发，团队遵守自然设计（emergent design）的原则。这意味着团队编写高质量的代码，但是只有必要的时候才会增加功能或者设计结构。团队 A 可能写了一个加密模块，因为只有一个地方在用，他们就没有使用接口。团队 B 可能后来也需要一个加密模块，但与团队 A 的稍微不同。这是，最好的办法是让团队 A 修改代码，使用接口这是就需要为团队 A 赋予新的任务，即对加密模块的开发与维护任务，并对团队 B 进行支持。这时这个加密模块的需求，就应该由产品负责人加入到非功能需求中，同时，团队 A 的 Scrum
10、 Master 也要负责这个需求的协调与沟通。（3）拆出一个只关注架构的团队大型软件项目通常都是整个应用系统中一部分，需要和已有的 IT 基础架构无缝挂接。虽然产品负责人对核心功能需求非常熟悉，但是在安全、日志、可用性、性能等方面就所知甚少了。要从用户的组织中了解这些需求难度很大，因为这得跟不同部门中的许多人沟通讨论。这种调查工作给 Scrum 的迭代节奏拖了后腿。为了解决这个问题，可以创建一个只关注架构方面的内容的独立团队。他们的工作就是弄清楚非功能性需求，并把它们转换成 backlog中的用户故事。同时，使用“Scrum of Scrum”会议来跟特征团队沟通。我们都喜欢这种方式，因为特征团队可以全速前进。而且有些员工也喜欢在“架构团队”中工作。
