【IT168 管理文档】    在软件开发中采用敏捷方法需要很多组织级的改变，例如企业文化、个人角色、过程等。作为一个组织，想要进行敏捷转变，就必须学着妥善处理这些变化。

    文中，我参考了敏捷、Scrum和精益理论。所以谨慎起见，我在文章之初先明确一下我这个“敏捷”的定义。我认为，敏捷是众多新兴的、围绕迭代递增软件开发的项目管理理论的总称。其中比较流行的几个是：精益理论、水晶方法、Scrum、动态系统开发方法以及极限编程。

    Scrum和极限编程，尤其是这两者的组合，是迄今为止被运用最多的敏捷方法。尽管Scrum的定义中不包含任何关于工程规范的内容，我们仍然不可能把两者分而置之。那么如果你问我敏捷代表什么，我会这么定义：

    Agile = Scrum + XP

    最近也有很多思想领袖成功地把精益思想引入到了软件项目管理当中，这么看来，要是我在文中不提及这部分内容就太蠢了。

    本文就是基于此来写的。

    本文概述了在敏捷组织中不同角色可能发生的变化，并为能更好地从瀑布模型转变到敏捷方法提供了一些建议。文中论及的角色如下：客户/利益关系人，产品管理，综合管理，项目管理，开发人员和质量保证人员。关于技术类角色，我说得更加具体一些，这主要是由于我个人的经验更偏向技术一点。

    敏捷方法着眼于短期项目目标的实现效率。例如，与瀑布模型不同，敏捷方法通常以2到4周为时间间隔来开发一些软件功能。此体系通过频繁的“检视和适应”周期，来同时确保团队动力和客户满意度。敏捷有能力彻底颠覆职位和背景对个人的局限，从而实现效率、个人潜能发挥和产出的最大化。这一能力引出了一个软件开发策略，而由此衍生的各种改变都是合理的：一个经济的、结果导向的软件开发方法。

    简介

    多数人不喜欢变化。反正我不喜欢。但可以肯定的是，在软件开发中采用敏捷方法需要很多组织级的改变，例如企业文化、个人角色、过程等。作为一个组织，想要进行敏捷转变，就必须学着妥善处理这些变化。本文描述了新的敏捷团队会有什么变化，以及怎样能更好地适应这个新的、生机勃勃的环境。文中涉及的敏捷组织中，可能有变化的角色如下：

    1.客户/利益关系人

    2.产品管理

    3.综合管理

    4.项目管理

    5.开发人员

    6.质量保证人员

    需要强调一下，文中提到的信息不是都能应用于每个组织的，因为每个团队运作模式不同，所用的技能体系也不同。下文提到的改变反映了我在做ScrumMaster管理开发项目时的所遇种种。现在就来具体谈谈：

    客户/利益关系人

    做传统的瀑布模型项目时，一般客户和项目会保持一定距离，只在项目始末他们才会参与进来。十有八九，都是我们（开发团队）迫使客户们畅所欲言。因为我们明确告诉客户，如果项目开始后有任何需求变更，就得走变更流程，还必须承担相应的变更损失。那么在我们完成了编码过程，可能是在项目启动的数月之后，我们交付代码时才发现“我们做错了”。无需多言，这种方法就是罪魁祸首。

    那么敏捷项目中，客户们需要在开发过程中自始至终都和项目紧密配合。实际上，敏捷项目会拥抱变更，且非常欢迎客户的反馈。

    1.在项目所有的“检视和适应”这一环节上，都期望客户能够参与并提供宝贵意见。这可以降低风险，为客户和利益相关者提供选择空间。注：极限编程项目中，要求客户成为团队的一部分。

    2.计划会议上，客户应该和产品负责人一起定义User Story，并在计划会议上给出详细说明。

    3.客户应该和产品负责人一起为Backlog定出优先级。

    4.客户和利益相关者要参与Sprint尾声的产品演示。根据客户和产品负责人的关系，客户甚至可以参加Sprint回顾会议。