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