敏捷开发在大型项目管理中应用探讨

《敏捷开发在大型项目管理中应用探讨》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1、..敏捷开发在大型软件项目管理中的应用探讨一、敏捷开发概述Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum在英语的意思是橄榄球里的争球。虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法。Scrum是迭代的、增量型的流程，其流程如1所示。Scrum构造的产品迭代周期为Sprints,工作的迭代时间一般为一到四周，并且是相互衔接的。Sprints是有固定的周期，结束于固定明确的日期，无论该工作完成与否，从不延长。在每一Sprint的起始阶段，一个多职能的团队从已优先化的要求列表（下文

2、中称ProductBacklog）中挑选若干项目，并承诺在Sprint的末期完成这些项目。在Sprint中，任务的内容不会变化。每一工作日，团队成员互相通告工作进度，并更新简易的剩余工作量直观表示图表。在Sprint的末期，团队将对这一阶段工作结果作一展示并取得相关的反馈，为下一Sprint做好准备。Scrum强调生产可以使用的产品，意指在Sprint的末期产品的“完成”；在软件方面，是指编码已经被检测并可以随时交付使用。资料..图1Scrum周期图在Scrum中有三个基本的角色：产品所有者(ProductOwner)，开发团队和ScrumMaste

3、r。1.产品所有者（ProductOwner）产品所有者（ProductOwner）负责取得产品最大的商业价值，收集相关于产品的所有信息。从客户或产品的终端使用者，开发团队成员和项目管理者中获取并将信息转化为优先权项目列表。在一些情况下，产品所有者(ProductOwner)正是客户本人；在另一些情况下，客户可能是有不同需求的成百上千的人。产品所有者(ProductOwner)这一角色在许多企业中是由产品经理或产品市场经理担任。2.开发团队开发团队构建客户将会购买的产品：比如报表或软件。Scrum团队是“多功能”资料..的。它包括交付每一Sprint

4、中的随时可交付产品所需的各类专门人员，并且它是有很高自律性和责任性“自我管理”的团队。团队决定承诺完成哪些任务和完成承诺任务最好的方法。Scrum团队通常包括五到十个成员，然而团队大到15个成员和小到3个成员也有很好的收效，一个软件项目的开发团队包括程序员，界面设计师，检测员和研究人员。开发团队不仅构建产品，他们也向产品所有者(ProductOwner)提供让产品尽善尽美的建议和想法。团队成员可以将其时间划分给Scrum项目和其他的项目，但是如果团队成员能专注于Scrum项目开发则效率更高。团队内部成员也可以在不同Sprint中变化，但是这样会减少整

5、个团队的生产效率。3.ScrumMasterScrumMaster的任务是以任何方式帮助整个团队取得成功。ScrumMaster不是团队中的经理；ScrumMaster的职责是服务整个团队，帮助团队铲除壁垒而取得成功，协助团队会议，并支持Scrum的实践。在一些团队中会有某一人专心致力于担任ScrumMaster，而另一些小型团队可以采用其中一个成员兼职担任（此人会适当减少日常工作量）。一个好的ScrumMaster可以来自不同的背景和学科：项目管理，工程技术，计算机或者电子工程等等。ScrumMaster和产品所有者(ProductOwner)不应

6、是同一人；有时，ScrumMaster可能会号召拒绝产品所有者(Product资料..Owner)（例如，他们有时会在某一Sprint中期试图加入新的条件）的要求。不同于项目经理，ScrumMaster不会指示和分配工作。他们只是协助流程的实施，推动团队自我组织和管理。二、大型软件项目管理中应用敏捷开发的问题探讨传统认为敏捷开发主要适用于小规模团队完成的中小型项目。大型软件项目从需要的业务知识背景、研发团队规模、系统架构等方面都有很高的要求，需要在应用敏捷方法的过程中，实施一系列改进。我们尝试从以下几个方面讨论大型软件项目中应用Scrum中可能遇到的

7、问题及解决方法。（这里我们假设该大型软件项目团队规模在40人左右，该项目是整个用户系统中的一部分，其他还包括IT基础设施项目）1.产品负责人的确定选择产品负责人是个很有难度的事情，在大型项目中，由于涉及的知识面非常广，很难找到一个人能够有时间、具备领域知识、而且有权利设置需求优先级。因此，可以由两个（或以上）业务分析师来一起承担产品负责人的职责。他们有充裕的时间、充足的项目经验和丰富的业务知识，足以担当起产品负责人的角色，为多组客户充当优秀的代理。有关优先级的和范围的高级决策，是这些产品负责人共同通过会议的方式决定的。资料..2.团队的构建关于团队的

8、规模，传统Scrum一直认为5-9人是一个最佳范围，团队过小，管理成本会过高，团队过大，则不利于团队的沟通，