从IT方法论来谈Scrum

　　“方法”这个词很常用，但并不简单。大部分会出现一种现象，做了一些事情，解决了很多问题，但是当别人问自己是采用什么方法来指导自己工作时并 不能清楚的说出来。大部分工作是被事情推着走，而并没有在“方法”的指导下有序的进行工作。从精益开发角度来看，缺少”方法“，摸着石头过河，这势必造成 很多浪费，所以我比较关注如何总结出适用的方法来支持团队的工作。我在网上搜了很多地方，还没有看到有哪里或者哪本书系统的讲解了IT方法论的知识，如果 有的话希望大家多推荐一下。本篇我将结合敏捷来来谈谈IT方法论。

方法定义

　　在需求过程中对新事物沟通时很重要的一个就是对术语的解释，这样大家知道谈论的不会有偏差。所以我们首先需要清晰的定义什么是方法。在《软件工厂应用 》一文开头指出，方法论是基于大量实践的高度抽象之上，加上理论的加工后才形成的一套体系。这个说法有点太抽象，所以我准备再借用一篇论文《Method Engineering: Engineering of Information Systems Development Methods and Tools 》里的概念来说明。原文如下：

Amethod isanapproach toperformasystemsdevelopmentproject,basedonaspecificwayofthinking ,
consistingofdirectionsandrules ,structured inasystematicwayindevelopmentactivitieswith
correspondingdevelopmentproducts.

　　我还是很认可这个定义，因为它定义得比较丰富，指出来方法应该包含哪些主要内容，我从中用黑体字标识出了我认为重要的部分。它指出方法（method）是一个基于理论（way of thinking），包含一套指南和规则的 approach (针对某一问题的解决处理方法），并且这个方法结构化为一套系统化的开发活动。

<!-- <br /><br />Code highlighting produced by Actipro CodeHighlighter (freeware)<br />http://www.CodeHighlighter.com/<br /><br />-->Scrum方法是遵循敏捷宣言中所列的价值观 ，基于12条敏捷原则 ，提供了一套术语和流程 （如产品backlog 、spint计划会议指南 、站立会议 等）作为实践指导，短期迭代的进行有价值的产品交付。

方法框架

　　Aydin从通用方法工程理论出发提出了一套通用框架，这个框架包括三个元素：a philosophy, a framework and supporting tools and techniques. Aydin的论文我以前找过，但没有找到，只能从《A method for Requirements Management and modeling》 的一些介绍来理解了。如果有人找到了希望共享一下：）

　　价值观（philosophy ）部分包含所有基本的原则、假定和约束，这些部分关注需求方法，定义范围并且决定了方法的组成。框架（framework ）包含一些模板、规则和样式来展现案和归类不同的方法元素（例如产品、交付物和流程步骤）。工具和技术（The tools and techniques ）支持特定方法步骤来实现最终产品。

　　Aydin方法框架在初始阶段能够用来结构化方法，但是由于还是比较抽象，所以仍旧比较难以实施。所以有其他方法研究者提出另一套框架，这个框 架用来开发（developing）、理解（understanding）和结构化模型方法（structuring modeling methods）。这些研究提出了六种思路（six way）： the way of thinking, the way of working, the way of modelling, the way of supporting, the way of communicating and the way of controlling.

The way of thinking

　　思考方法是一些范式、基本观点或者价值观，它能够回答“为什么”的问题。Scrum是敏捷方法中的一种实践框架，所以敏捷宣言的价值观也是它的价值 观。《Scrum敏捷项目管理》前言二最后指出，Scrum的运作原理桶丰田公司持续成功的原因一样，包括三个方面：企业哲学基础、管理文化和技术工具。其哲学基础是授权于项目开发团队，以及满足客户需求。 软 件开发是一种脑力投入，如果不能保证开发人员的自愿投入，产品则肯定会打折扣，有研究证明一个愿意投入的开发人员和一个不愿意投入的开发人员效率相差在三 倍以上，对组织的贡献更是在十倍以上。在团队从里到外深刻理解集体负责和自组织后，Scrum方能有效运作。团队成员只有实现集体负责，承诺在固定时间内 交付实际产品后，才能算真正掌握了Scrum。其管理文化植根于“帮助他人完成目标”这一理念。 敏捷方法尊重人性，强调效率。敏捷方法强调面对面的沟通，通过现场客户、站立会议、结对编程等方式来保证沟通的有效。其主要技术工具是通过学习过程作出基于适时的决策 。 沟通和反馈是一切的基础，即时的反馈是拥抱变化的前提条件。

The Philosophy of Scrum

敏捷开发之 4句敏捷宣言

The way of working

　　工作方法描述了如何应用方法，它包含一些在开发过程中可能采用的一些任务，包括任务的分解和排序，以及对任务的执行和决策的制定提出正式的指导和建议。

　　Scrum 本身并不是方法论，它只是一个框架，它 只定义了高层次的管理流程，如下图所示。它并不涉及具体开发方法或者人员的有效沟通技巧等。这些没有涉及的领域需要桶其他理论和技能互为补充，以确保项目的成功。

　　

　　Scrum的核心在于迭代，整个过程只有三个角色。产品负责人的职责是利用产品backlog，督促团队优先开发具有价值的功能，并在其基础上继续 开发。产品负责人必须频繁检视产品代开发需求的优先级，以便将最具价值的功能安排在下一个迭代中完成。团队的责任是开发软件功能，他们是自组织团队，团队 所有成员对每一次迭代和整个项目共同负责，不单做考核。Scrum Master则需要对Scrum过程负责，向所有项目参与者讲授Scrum方法，负责实施Scrum，确保它既符合企业文化，又能交付预期利益，还需督促 全体成员遵从Scrum规则和实践。

　　启动Scrum项目所需的最简约计划包括：一份愿景及产品Backlog。愿景描述项目开发原因和预期目标。愿景可能描述商业运作方式将发生哪些改变，主 要特性和功能如何为客户创造收益，以及对市场的预期影响。产品backlog将定义交付愿景时，系统应满足的功能性和非功能性需求，它需事先划分优先级并经过初始预估（预估的目的是了解每个需求自身及相对与其他需求的规模）。

　　在Sprint第一天召开sprint计划会议，这个会议分为两部分，计划会议1由PO、SM和Team参加，主要是从产品backlog中挑 选出需要放 到当前sprint下的既定产品backlog，然后由SM、Team参加计划会议2，把既定产品backlog的故事拆分成任务进行估算，PO也可以一 起参加这个部分来了解具体的开发细节。sprint周期在spirnt计划会议2正式开始。开发过程中，团队每天召开每日站会（Daily Scrum），沟通团队成员间工作进度和进行任务协调。Sprint周期结束时，需要召开Sprint评审会议，由团队向产品负责人和其他利益相关者展示 当前sprint周期内的产品开发情况。产品负责人根据团队这次 Sprint 所发布的版本，评审相关的 Backlog 中的问题，检查是否已达到 Sprint 的目标。评审会议结束后会进行回顾会议，通过总结以往的实践经验来提高团队生产力。

Software Development Theory

Scrum's Implementation

Scrum之 流程和术语

Scrum 之 product Backlog

Scrum之 Sprint计划会议

Scrum之 站立例会

Scrum之 评审会议

Scrum之 回顾会议

The way of controlling

　　控制方法解决项目开发的管理方面的问题，提供一种机制来管理工作方法（way of working），它包含计划和计划评估。基于检查点和基线，计划和计划评估被划分为多个阶段。控制方法和模型方法和工作方法互相联系，不能单独来看每个方法。

　　软件开发对于管理存在两个极端：一个是没有任何的管理成本，所有的工作都是为了软件的产出，这种方式往往导致软件开发过程的混乱，产品质量低，士气 也很低落。另一个是大量管理活动的加入，评审、变更管理，缺陷跟踪，虽然管理活动的加入能够在一定程度上提高开发过程的有序性，但是成本却因此提高，更糟 糕的是，很容易导致团队的低效率，降低创新能力。因此，敏捷方法视图寻找一个平衡点，用低成本的管理活动带来最大的产出，即软件的高质量。系统越复杂，集权管理导致失败的可能性越大，Scrum应用自组织 、自管理原则 ，授权于项目开发团队 ，通过频繁运用“检查－调整 “周期加速创造更具价值的软件，它带来较低的管理成本和高质量的产出。

　　《过程动态学，建模及控制》指出，“在过程运行根本机制相当简单易懂的情况下，典型做法是采用预定义的（理论的）建模方式。若过程复杂程度超出预定义方式的能力范围，便应选用经验性方式。”Scrum承认软件开发的复杂性（需求、技术和人），实施经验性方式。实施经验性过程控制方法时，有3大支柱：可见性、检查及适应 。可见性 是 指对过程控制者来说，过程中对最后结果有影响的方面必须清晰可见，而且必须真实可信，例如Scrum中对于完成的定义必须团队都有清晰的认识。过程中的各 个方面必须频繁检查，例如进行代码评审等。适用就是经过检查后，调整工作需要尽快展开，以减少进一步的偏差。Scrum会进行每日站会，沟通每日进展情况 以作调整，每个sprint后还会进行回顾会议，以便反馈到下一个sprint中。

　　Scrum方法中没有传统意义上的项目经理，取而代之的是Scrum Master，他承担领导、指导和教练工作。软件开发工作的性质决定了会有大量复杂问题的出现，Scrum Master无权直接命令开发团队，他有责任讲授怎样使用Scrum来处理项目中遇到的每个新的复杂问题，解决这些问题离不开努力工作、智慧和勇气。

　　Scrum的运作基础是个人和团队的承诺，而非严密的规划及控制。但自组织团队不是无管理团队，它必须制定计划并有针对性的进行报告，才能管理自身工作。sprint backlog是团队履行职责的可视表现。

Scrum and Process Improvement

Development: Empirical or Planned?

The way of modeling

　　模型方法定义了一些模型语言，使用符号，结合文档进行分析，并可以可视化的来描述架构需求。

　　Scrum中可以有一些基本概念，如backlog、Story、Task，Story有优先级、Task有估算时间等，这些在开发过程中都需要使用一种方式表达出来，以下为别人使用Excel对产品backlog和sprint backlog进行描述的两个示例：

Simple Product Backlog Example

Simple Sprint Backlog Example

Scrum Rules

The way of supporting

支持方法寻找有用的工具、培训、文档来协助支持信息系统的开发。

“项目快速启动”方案是为期两天的培训，确保缺少Scrum经验的新团队能启动项目。

以下为别人对Scrum工具的描述：

Scrum工具大比拼---流行Scrum工具一网打尽

推荐三款Scrum项目管理工具

The way of communicating

沟通方法描述了对开发过程中的各个环节、工作成果等如何进行沟通，也包含在模型方法中定义的抽象概念如何通过文本或者图形符号来表达清楚。

Scrum通过任务看板来查看任务，通过燃烧图来查看项目进展情况。

用“看板图”实现敏捷项目的可视化

FAQ's