近期接触了scrum项目管理，根据查阅的资料和自身的体会，本文将从软件过程、敏捷开发、scrum框架、scrum的用法和scrum的价值等5个方面对其进行简单的阐述。
价值等5个方面对其进行简单的阐述。
一、软件过程
（一）软件过程的定义
软件过程是为了建造高质量软件所需完成的任务框架，即形成软件产品的一些列步骤，它规定了完成各项任务工作步骤，包括中间产品、资源、角色、过程中采取的方法、工具等。
（二）软件过程的七大元素
软件过程是为了建造高质量软件所需完成的任务框架，即形成软件产品的一些列步骤，它规定了完成各项任务工作步骤，包括中间产品、资源、角色、过程中采取的方法、工具等。
（三）软件开发模型
软件开发模型又称为软件生存周期模型，是软件生命周期的一个框架，规定了软件开发、运作和维护等所需的过程、活动和任务，主要包括：线性顺序模型、增量式模型和演化模型。
（四）常见开发模型介绍
线性顺序模型又称瀑布模型，其主要的开发流程为需求分析->设计->实现->测试->交付->使用和维护。
1.模型特点
这类模型的特点为强调阶段的划分顺序与依赖具体来说有：①强调各阶段工作文档的完备性，即文档驱动静态描述②每个阶段从技术和管理进行严格的审查，即质量保证的观点③一种线性的、顺序的、逐步细化的开发模式。
2.模型优点
①结构简单明了、历史较长、应用面广泛、为广大软件工作者所熟悉。②已有与之配套的一组十分成熟的开发方法和丰富的支撑工具。③一种较为有效的管理模式：订计划、成本预算、组织开发人员,阶段评审,文档管理,从而对软件质量有一定的保证。
3.风险和缺点
①难以获得完善的需求规约②难以适应快速变化需求③系统太大时,难以一次做完④反馈信息慢⑤极可能引起开发后期的大量返工，如返工到需求、设计等早期活动。
二[endif]敏捷开发
（一）敏捷开发的定义
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
（二）敏捷开发的特点
敏捷开发最大的特点是迭代式开发，各个阶段都具备独立运行和独立交付的特性。主要是以客户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，即就是多个sprint，每个sprint中又会有划分成多个build，在一个软件项目完成后会对整个产品从头到尾进行回归验证，以确保软件在每一次迭代过程中没有错误产生。在软件最后的发布阶段，客户会对最终的产品进行验收工作。上线后对软件进行一直的维护。
（三）敏捷开发的要素
Sprint（Sprint本身是一个事件，包括了如下4个事件）
Sprint计划会议（SprintPlanning Meeting）
每日站会（DailyScrum Meeting）
Sprint评审会议（SprintReview Meeting）
Sprint回顾会议（SprintRetrospective Meeting）
TDD：测试驱动开发（Test-DrivenDevelopment）
BDD：行为驱动开发（BehaviorDriven Development）
持续集成CI（Continuous Integration）
持续部署CD（continuous deployment）
（四）敏捷开发的流程
1、目标制定，目标对齐：通过市场调研、业务思路、风险评估制定公司规划和目标，根据这一目标产生所有部门的目标并实现对齐；
2、产品规划：产品研发部门根据目标制定产品关键路线图，这个路线图中分布着不同的产品特性和其完成时间；
3、组织产品待办列表：产品规划产生的需求、客户需求、市场人员收集到的缺陷等将组成产品待办列表；
4、需求梳理：然后产品负责人(Product Ower)对这个列表进行梳理，并在需求梳理会(Backlog Grooming Meeting)讲解具体每一个需求，团队成员根据需求的复杂程度评估每个任务的工作量，输出本次迭代的待办事项列表，完成优先级排序等工作；
5、迭代规划：通过Sprint计划会，明确要执行的工作、冲刺目标等。
6、迭代开发：期间会进行每日站会、性能测试、CodeReview、Demo、测试等工作；7、Sprint评审：由每个任务的负责人演示其完整的工作，由PO确定Sprint目标是否完成，版本什么时候对外发布，新增bug的紧急程度等等。
8、开回顾会议：回顾会议由Scrum团队检视自身在过去的Sprint的表现，包括人 、关系、过程、工具等，思考在下一个Sprint中怎么样可以表现得更好，更高效，怎么样可以和团队合作地更愉快。
三、Scrum框架
1、3种角色
产品负责人（Product Owner）：产品负责人是产品最终用户的代表，负责确定产品的方向和愿景，定义产品发布的计划、内容和优先级。产品负责人要不断地与开发团队沟通，保证团队在做业务角度来说最正确的事情。产品负责人是产品待办列表的唯一负责人。
Scrum教练（Scrum Master）：Scrum教练负责确保团队合理的运作Scrum，帮助团队移除实施中的障碍。
开发团队（Development Team）：一个自组织的跨技能的小团队，承担实际开发工作，负责在周期性的迭代中不断的交付有价值的工作。开发团队通过集体共同交付脚趾，而不是通过个体。
2、5种事件
Sprint：Sprint本身也是一种事件，其包含下面4种事件。
迭代计划会议（Sprint Planning Meeting）：在每个迭代之初，产品负责人和开发团队共同来计划在迭代周期内要完成的工作。产品负责人负责向团队讲解要完成的工作，开发团队负责对工作进行估计。
每日站立会议（Daily Standup Meeting）：每天，产品负责人和开发团队都要进行一个短暂的沟通。在会议期间，每个团队成员都要回答3个问题：“我昨天做了什么？”，“我今天准备做什么？”，“我遇到了什么问题？”。
迭代评审会议（Sprint Review Meeting）：在迭代周期结束时，开发团队向产品负责人及所有干系人进行演示，并接受反馈。
迭代回顾会议（Sprint Retrospective Meeting）：Scrum团队在迭代结束之后会进行一次迭代回顾会议，通过这次会议对迭代的过程进行总结，以促使团队自我持续改进。
3、3种工件
产品待办列表（Product Backlog）：这是一个产品负责人想要交付的产品功能列表。产品负责人负责维护该列表，并且将列表项按照交付优先级进行排序。
冲刺待办列表（Sprint Backlog）：这是一个迭代计划会议的输出、包含开发团队在在迭代周期内所要完成的工作列表。
产品增量（Product Increment）：每个迭代周期都需要交付高质量的产品增量。产品增量必须满足Scrum团队对完成标准（Definition of Done）的定义。
四、Scrum的用法
SCRUM方法的开发过程
包括三个过程：
(1)计划和体系结构设计（确定性过程）
将Backlog（急待完成的一系列任务，包括：未细化的产品功能要求、Bugs、缺陷、用户提出的改进、具竞争力的功能及技术升级等）按优先级排序形成Backlog 列表，根据该表和风险评估制订产品交付基线。
建立系统体系结构（如为已有系统改进，则只作有限分析、调整），将Backlog项按高内聚低耦合的原则分解为一系列问题包(Packets,每个Packet是一组对象或构件的集合) ，依据同样原则相应划分若干个开发小组（SCRUM 小组）,分配各小组合适的Backlog项或问题包。建立开发运行环境。
(2)Sprint（经验性过程）
该过程由若干个迭代的冲刺(Sprint) 活动组成，直至风险评估认为产品可交付为止。一个Sprint是在限定时间段内（Sprint周期，通常为1~6周，可在前一个Sprint结束时调整）的一系列开发活动（包括分析、设计、编码、测试等），每个SCRUM小组并行开发且必须步调一致（在一个Sprint结束后，均须完成所分配的Backlog项并有可执行的产出）。
每个Sprint包含以下活动：
l 开发。对分配的Backlog工作进行分析，将所需改动（changes）映射到各packets，打开packets,进行领域分析，然后设计、开发、实施、测试、文档化这些改动。
2打包(Wrap)。封装packets,产生一个满足Backlog需求的可执行版本。
3评审（Review）。所有的SCRUM小组一起开会，提交各自的工作并演示(Demo)，然后提出和解决问题(Issue)及难点（problem）,增加新的Backlog项；发布、审查或调整产品的标准规范；进行风险评估并提出合适的对策；确定下一个Sprint的工作内容和结束时间。
4调整（Adjust）。根据评审会汇集的信息，对受影响的Packets进行适当调整和巩固。
(3) 交付和巩固（确定性过程）
一旦根据风险评估结果认为可交付产品时，即进入该阶段。该阶段的活动包括：组装，系统测试和回归测试（Regression），准备培训材料，完成最终文档。
SCRUM过程认为一个产品的开发将一直持续下去，除非经风险评估后认为应停止。产品交付后的巩固活动类似于传统方法中的维护和改善，目的在于整理Sprint期压力下忽略的工作，为下一阶段的开发做准备，以便轻装上阵。
3.2.2 SCRUM对过程的管理：
(1)SCRUM的控制手段。
SCRUM提出了八个控制项（Controls）用于开发过程的调控，其中风险控制是首要的手段。
l Backlog。
2对象/构件。
3 Packets。
4变动（Changes）。实施一个Backlog项时，对相应Packet的改动。
5难点（Problems）。实施一个变动时所必须解决的技术难点。
6问题（Issues）。涉及到整个项目或在Backlog项分解到Packet之前须解决的问题。
7措施（Solutions）。对问题或难点的解决，通常会导致变动。
8风险（Risks）。影响项目成功的风险，应持续跟踪评估并相应做出调整。风险评估的结果将影响其他所有控制项。SCRUM定义了六个概念性变量来用于风险评估：用户需求，时间压力，竞争，质量，远见（vision）和可用资源。
在SCRUM的各个阶段都使用这些控制项来评估和权衡，管理人员侧重于以此管理Backlog，开发组用以处理变动和难点。所有人员一起来管理问题、风险和措施。
根据对控制项特别是风险的不断度量评估和权衡，一方面，计划和进度（在每个Sprint结束时）不断相应调整，保证实现产品的商务目标；另一方面，对开发中的工作任务Backlog动态地进行优先级排序，开发组总是先开发优先级最高的Backlog项，这样就保证了资源的最合理使用。另外，SCRUM强调度量（采用标准功能点度量方法）的重要性，通过对每个Sprint中生产率等的度量，计划和进度将越来越趋于准确。
(2)项目组织。
项目组由全职开发人员及与该交付产品有关的市场人员、销售人员、用户等组成。设以下小组：
l 项目管理组。由产品经理领衔，包括总设计师，各SCRUM小组组长，市场、销售的高级职员及典型用户等。
2若干个SCRUM小组。各小组由组长（SCRUM Master）领衔。每个小组都是跨专业的（通常包括开发人员，文档人员，质量控制人员或用户代表等），通常为3~7人，以使小组内有充分的交流。小组的划分最好是功能导向的（按所分配的问题包或Backlog），也可是系统层次导向（按体系结构中的分层）。.
在项目组人数增大时，可在管理组之上再设管理组（SCRUM of SCRUM）,从而使SCRUM方法的应用到大项目中。
(3) Sprint期间的调控。
在Sprint期间，应使各SCRUM小组尽量避免外界的干扰（不可将新的Backlog任务加进来，组内产生的Backlog可放到整个项目的Backlog列表中，也可在本次Sprint中解决），使小组成员专心于目前的工作，使他们工作在混沌的边沿。
为避免项目组在Sprint期间不陷入混乱，SCRUM采取两个措施:
l SCRUM会议（SCRUM Meeting）。对小组行为进行监控和刺激。会议在Sprint期间每天在同一地点举行，由SCRUM Master主持。会议上，SCRUM Master对每个小组成员提三个问题：
1） 昨天的工作进展如何。
2） 有否遇到困难和障碍。
3） 今天的工作打算。
会后SCRUM Master集中精力排除障碍，小组成员则进行当天的开发。
l Sprint评审会议。评审后根据对每人的工作成绩，进行相应的激励。
3.2.3 SCRUM方法的实践效果和发展方向：
SCRUM在实践中大大提高了生产率（据软件生产率组织的Capers Jones称可提高6倍），在实施中有一个"间断平衡"（Punctuated equilibrium）现象（类似于自然界中物种的进化，在经过一段相对平衡的各自独立、并行的发展期后，在交汇处发生变异），即在经过紧张、并行的Sprint开发后，在Sprint评审时，软件产品产生较剧烈的变化。SCRUM方法的最近动向是设法借鉴XP方法。
五、敏捷带来的价值
（一）对组织的价值
1、经常交付，可缩短上线时间——每周一次上线跟每月一次上线的差异可想而知。
2、拥抱变化，尽力接受有价值的变更——有需求变更时，首先想到的是价值，而不是增加多少工作量。
3、始终优先最高优先级、最有价值的需求——价值优先，始终保证最有价值的需求最明确最早上线。
（二）对团队的价值
1、拥有可持续的开发速度——稳定的迭代速度，可以拥有可持续的开发速度，稳定交付。
2、有效提升团队士气和战斗力——有共同的目标、清晰一致
3、自组织&学习型团队——知识、经验共享，团队一家，共同学习、共同成长、统一目标统一产出
4、沟通高效——敏捷提倡面对面沟通，这是最高效的沟通方式，用时短、产出高、最大程度排除掉了误差信息
（三）对个人的价值
1、团队知识共享，高要求&高锻炼——敏捷团队是全功能团队，要求高，团队知识共享，对于自身提高也快
2、随时随地学习，成长无处不在——团队作战、共享空间，随时随地学习。
3、个人归属感和主人翁荣誉感——自组织团队，人人都是团队的主人。
4、被尊重&快乐工作——敏捷提供尊重，人人平等。
以上说的只是敏捷很基础也很显而易见的价值，还有更多更重要的，待我们慢慢发现。
