摘要
在软件开发中采用敏捷方法需要很多组织级的改变，例如企业文化、个人角色、过程等。作为一个组织，想要进行敏捷转变，就必须学着妥善处理这些变化。
文中，我参考了敏捷、Scrum和精益理论。所以谨慎起见，我在文章之初先明确一下我这个“敏捷”的定义。我认为，敏捷是众多新兴的、围绕迭代递增软件开发的项目管理理论的总称。其中比较流行的几个是：精益理论、水晶方法、Scrum、动态系统开发方法以及极限编程。
Scrum和极限编程，尤其是这两者的组合，是迄今为止被运用最多的敏捷方法。尽管Scrum的定义中不包含任何关于工程规范的内容，我们仍然不可能把两者分而置之。那么如果你问我敏捷代表什么，我会这么定义：
Agile = Scrum + XP
最近也有很多思想领袖成功地把精益思想引入到了软件项目管理当中，这么看来，要是我在文中不提及这部分内容就太蠢了。
本文就是基于此来写的。
本文概述了在敏捷组织中不同角色可能发生的变化，并为能更好地从瀑布模型转变到敏捷方法提供了一些建议。文中论及的角色如下：客户/利益关系人，产品管理，综合管理，项目管理，开发人员和质量保证人员。关于技术类角色，我说得更加具体一些，这主要是由于我个人的经验更偏向技术一点。
敏捷方法着眼于短期项目目标的实现效率。例如，与瀑布模型不同，敏捷方法通常以2到4周为时间间隔来开发一些软件功能。此体系通过频繁的“检视和适应”周期，来同时确保团队动力和客户满意度。敏捷有能力彻底颠覆职位和背景对个人的局限，从而实现效率、个人潜能发挥和产出的最大化。这一能力引出了一个软件开发策略，而由此衍生的各种改变都是合理的：一个经济的、结果导向的软件开发方法。
简介
多数人不喜欢变化。反正我不喜欢。但可以肯定的是，在软件开发中采用敏捷方法需要很多组织级的改变，例如企业文化、个人角色、过程等。作为一个组织，想要进行敏捷转变，就必须学着妥善处理这些变化。本文描述了新的敏捷团队会有什么变化，以及怎样能更好地适应这个新的、生机勃勃的环境。文中涉及的敏捷组织中，可能有变化的角色如下：
- 客户/利益关系人
- 产品管理
- 综合管理
- 项目管理
- 开发人员
- 质量保证人员
需要强调一下，文中提到的信息不是都能应用于每个组织的，因为每个团队运作模式不同，所用的技能体系也不同。下文提到的改变反映了我在做ScrumMaster管理开发项目时的所遇种种。现在就来具体谈谈：
客户/利益关系人
做传统的瀑布模型项目时，一般客户和项目会保持一定距离，只在项目始末他们才会参与进来。十有八九，都是我们（开发团队）迫使客户们畅所欲言。因为我们明确告诉客户，如果项目开始后有任何需求变更，就得走变更流程，还必须承担相应的变更损失。那么在我们完成了编码过程，可能是在项目启动的数月之后，我们交付代码时才发现“我们做错了”。无需多言，这种方法就是罪魁祸首。
那么敏捷项目中，客户们需要在开发过程中自始至终都和项目紧密配合。实际上，敏捷项目会拥抱变更，且非常欢迎客户的反馈。
- 在项目所有的“检视和适应”这一环节上，都期望客户能够参与并提供宝贵意见。这可以降低风险，为客户和利益相关者提供选择空间。注：极限编程项目中，要求客户成为团队的一部分。
- 计划会议上，客户应该和产品负责人一起定义User Story，并在计划会议上给出详细说明。
- 客户应该和产品负责人一起为Backlog定出优先级。
- 客户和利益相关者要参与Sprint尾声的产品演示。根据客户和产品负责人的关系，客户甚至可以参加Sprint回顾会议。
产品管理
如果你是一个正在向敏捷转变的项目的产品经理，你也会有些变化。首先，你的头衔从产品经理变成了产品负责人。但这不是全部。传统环境中的产品经理主
要负责前端工作。除了他们特定的市场职责以外，产品经理典型的职责就是负责前期的产品需求文档。另一方面，产品负责人则是客户的代理。在敏捷项目中，产品
经理转换到产品负责人会有下面的一些职责改变：
- 产品负责人是团队的积极参与者。产品负责人为产品的方向和在项目中的优先级负责，对此，他们责无旁贷。
- 产品负责人应该参加Sprint计划会议。产品负责人通常是Sprint计划会议的第一部分的主角，他负责定义Sprint的目标以及详细说明这个Sprint计划要做的每个User
Story的功能。
- 产品负责人要负责建立、维护product backlog，并且对其给出优先级。
- 与传统理念不同，产品负责人必须确保他/她能在团队需要的他/她的时候站出来。产品负责人是否要出席每次每日站立会议，存在着争议，但产品负责人越多得参与到团队中去，成功的可能性也越大。
- 产品负责人也开始在一定程度上负责定义验收测试标准，就这一点而言，也意味着多少对产品的输出质量负责——因为本质上来说，验收测试标准会使开发团队一开始就把质量作为重要的一部分。
因此，作为产品负责人，等着你的是每天更多的参与，准备好大干一场吧。
综合管理
鉴于敏捷团队应该是自我管理的，那么把综合管理置之何地呢，它的职责是什么呢？希望以下内容能有所启示。
- 管理者们应该能为团队扮演一个传道士的角色，尤其是如果管理者有相应的经验——不过很难确切地说是哪些经验。这也是为什么丰田要让总技师做产品负责人。这样的支持能帮助团队避免犯错，从而节省很多时间。
- 管理者们在面对困难时应该首当其冲，例如，他们应该帮助ScrumMaster解决掉需要管理层出手的“大”障碍，比如批准项目运作经费以确保团队能够前进。
- 新团队尤其需要来自高层的支持和认同来让敏捷过程上路。团队很容易滑回他们的老轨道，所以管理者们必须支持团队使他们能坚持敏捷之路。
- 管理者们还应该是“教练”，帮助团队成员做职业规划、执行绩效评估、培训或组织培训。
- 管理者们应该关注公司更长远的战略举措（如考虑怎样处理竞争威胁、促进销售、减少开支等）。
- 基于战略举措，管理者们应该和产品负责人紧密配合，确定好这一“鸿篇巨制”，识别出优先级，然后为产品的长远之路做好规划。
项目管理
Scrum本质上并没有传统的“项目管理”这一角色。那这对员工而言意味着什么呢？大多数情况，项目经理会很自然地转变成ScrumMaster。
然而，你信不信，好的ScrumMaster总是开发或者测试出身。相信我，ScrumMaster这一角色并不是很类似于项目经理。所
以，ScrumMaster候选人去参加些培训是很重要的。虽然ScrumMaster认证不是必须的，但还是很有好处。那么对于这种角色转变你能期望点
什么呢？
- 首先作为ScrumMaster你必须承认这样一个事实：团队才是进度的主人，所以你不再需要更新由来已久的优良传统——微软Project的甘特图了。取而代之的是，你不得不退居二线，但是一开始可能你得盯着团队，让他们每天更新自己的估算。
- 作为一个ScrumMaster，你得确保整个团队很好地遵循了Scrum流程，确保每个人都理解了Scrum是什么以及应该怎样做。
- 团队将指望你尽可能快地去扫去障碍，或者协助他们去扫除障碍。
- 你得通过在每次会议上重申Sprint的目标来确保团队全力以赴、坚持到底。
- 你将组织每天的站立会议（一个每天举行的会议，会议上每个人需要回答昨天你做了什么，今天你准备做什么以及有没有障碍这三个问题），确保会议在同一时间同一地点召开。
- 你得确保Scrum的精髓，特别是检视和适应能够被很认真地执行，这样Scrum才能按原先设计的那样良性地使用。这使得团队可以在每个Sprint中学习并有所提高。
现在让我们来看一下，在敏捷（Scrum）项目中，开发人员和测试人员的生活会有怎样的变化。老实说，我觉得有了那两条规范，开发人员和测试人员都将从敏捷转变中获益，生活也会更加美好。
开发人员
开发人员喜爱用正确的方式做事。十之八九，他们会反对走捷径。他们很厌恶被逼着去写那些实际上没什么用的代码。如同日常生活中的情况一样，敏捷转变
也得经过一定的反复才能彻底完成。所以即使只有十分之一的烂代码在那边，也得留意。开发人员在敏捷（Scrum
+ 极限编程）转变过程中最大的改变是工程规范，或者说严格度，被提升到了最高。那么你能获得点什么呢？
- 你不再需要独立估算任务了。这一被证明为最艰巨的活动，更应该由团队通过玩计划扑克来完成。结果就是，你将能得到更好的估算，并对估算有更宽泛的见解。另外，你不再需要为不好的估算承担全部责任。
- 你必须学习结对编程。假设你在实施XP实践（强烈推荐），你就会常常这么做。这需要开发人员在心态上有很大的转变，因为这是你第一次被
迫公开你的代码做同行评审。也就是说，你有可能在过程中的任何一步被评头论足。起初很难，但收益是巨大的；由此你将成为更优秀的程序员，我保证！你的代码
将质量更高，更易于维护。
- 你不再会写完代码往那边一扔，等着测试人员为你找bug。敏捷是建立在足够产出的前提下的，并且保持开发团队的动力，必须要求质量从一
开始就被建立起来。所以，你将要去学习怎么写单元测试。你将去学习测试驱动开发。这就是作为一名工程师，你的技能会被考验的地方，从而产出尽可能好的，高
质量的代码。回报是很高的，相信我。
- 你应该参与到完整的点对点的交互中去。这将让你看到事情的另外一面，因为你也是一开始的user story讨论会的参与者。因此，你将从客户和产品负责人那里了解到第一手的问题，因为他们在Sprint计划会议上详细介绍了user
story。你也应该是每次Sprint结束时候的回顾会议的参与者，这样从头到尾你都参与，可以提出做得好的地方，不好的地方，从而在下一个
Sprint中有所改进。
- 你不再需要一直加班。事实上，如果你完整地执行Scrum，你根本就不需要任何加班。通过跟踪Velocity会设定出团队能够产出的最大值，这样就可以管理在任何给定的时间点，可以安排多少活儿。一次安排太多的活儿，会导致交付低于预期。我们的Agilebuddy团队（Agilebuddy是一个由我协同创立的敏捷项目管理软件，它能帮助开发团队进行敏捷转变以及管理他们的软件开发项目）每两周进行一次产品发布，从来没有失败过。我们就是通过优化足够的工作量来做到的。关于这一点，我们可以从精益思想和丰田生产系统中学到很多。
- 如果你是流程的拥护者，你将不必再担心出现“死亡行军”或者“忙于救火”。相反，在每次Sprint的结尾，你会为已经完成的倍感骄傲，再也不想用别的方法。这需要所有的利益关系人从一开始就认同这个新的流程（这也说成功敏捷项目的一个前提条件）。
- 每个Sprint的结束阶段，你有机会去展示你所完成的工作——锦上添花。这是分享的时刻，而不再是隐藏着，这就是跟瀑布模型项目的不同，在瀑布项目中你永远不知道什么地方或者什么时候下一个bug可能出现。
- 你们将会以一个整体去战斗，跨越每个里程碑，还是一个整体。不再是我个人。相反，你会寻找一切机会，在需要的时候，去帮助团队成员。
测试人员
我职业生涯的大部分时间是工作在瀑布模型环境中的，所以我对这个“死亡行军（death march）”再熟悉不过了。这会不可避免地导致QA测试时间缩水。
所幸地是，和开发人员类似，对于测试人员，这一情况通过敏捷方法也有所改观。它是怎么实现的呢？
- 在每个Sprint一开始就参与其中。你可能疑惑于一个测试人员在项目早期能提供什么价值。然而，由于你必须参加Sprint计划会议，你就有机
会直接听到User Story计划。事实上，你将参与到详细制定User Story的过程当中。比如，你可以帮助确定User
Story的验收测试标准。这进一步帮助了开发人员更直接地理解他们需要做些什么来通过测试。结果，发布的代码的质量和“准确性”（如，代码和最终用户需
求的符合程度）有了显著提高。
- 你将参与计划扑克活动，帮忙估算User Story的大小。参与到估算过程中意味着公司能够更好更全面地估算User
Story的复杂度。这使得估算更加精确、计划更优、压力减轻、团队士气更高、?工作将更愉快。
- 你将参与到单元测试的创建过程中去。这是测试人员增强技能的很好的一个途径。测试人员也通过他们的分析法和“怎么破坏它呢”的心态，能够为项目带来很多的价值。
- 你应该尽可能多的将功能测试自动化。这样，你将为团队的综合效率和生产率做出贡献。精益理论提到，团队要更关注质量构筑和浪费最小化，
因为相较于其它因素，这更有助于改良生产周期（从概念到实践）。所以，你写自动化测试，就是在为代码库的总体质量做贡献，由此缩短总体周期。
- 在团队中，你将成为受尊重的一员，而不是只有"停止流水线"（丰田产品系统）权限的二等公民。例如，任何发现的缺陷都应该被及时解
决，即使在项目早期。敏捷理念通过建立一个有凝聚力的团队，并且把每个功能领域都当做开发来看待，来解决传统项目管理问题。事实上，Scrum项目中只有
开发人员（也就是说，如果你是Scrum项目中的一个测试人员，你就是另外一个拿到Sprint Backlog上的交付成果的开发人员而已）。
- 因为开发人员开始编写单元测试，你将不再会收到大量的丑陋代码。因此现在你可以关注更重要的的方面了，如测试边界和边界条件，还有将你的单元测试自动化。
- Scrum、极限编程以及精益实践都期望所有需要交付的代码在Sprint最后都被完成（也就是说，通过单元测试，功能性测试，集成测
试）。那么每个Sprint你都会有时间去完成这些，因为所有工作（包括测试）都在Sprint计划里描述了——不只是说说而已，例如，项目的最后三周用
于测试。
随着敏捷方法论深入人心，测试无疑也日渐成熟，在行业内测试人员比昔日得到了更多尊重。现在测试成为开发优秀软件必不可少的环节，因为它能确保软件
按着预期的功能被开发出来。基于一些像TDD、BDD之类的概念，测试工作已经由传统的后端过程转变成前端过程，这样，质量从一开始就被建立起来了。我深
信，这是软件质量提高、客户满意度改善和开发团队更积极主动的头号原因。
结论
敏捷改进开发环境以利于最大程度上发掘团队的工作潜能，并将它转化成为难以置信的高效软件开发周期。它也顾及到了软件开发过程中个人效率和生产率的
因素，弱化了公司层级限制从而来更好地支持功能性的团队。转变成为一个敏捷组织并采用Scrum方法要求软件开发团队的所有部门同心协力，并愿意做出改
变。最初，随着Scrum实行而来的改变看起来很痛苦。转变的技术细节很容易让人心烦意乱，失去改变的重心：对软件开发方法的转型最终会显得更有效。于
是，我总结了一些指南来帮助你们度过这一过程。基于以上所讨论的转变，以及对此举背后心态的理解，这一转变将成为高产的软件开发公司的一个直观步骤，而不
是一段摸着石头过河，探知危险领域的旅程。所以无论你和敏捷是第一次亲密接触、正在逐渐接受或已经采用了它，我都希望本文能知道你更好地处理Scrum项
目中的一系列改变。
| 
