开发人员

    开发人员喜爱用正确的方式做事。十之八九，他们会反对走捷径。他们很厌恶被逼着去写那些实际上没什么用的代码。如同日常生活中的情况一样，敏捷转变 也得经过一定的反复才能彻底完成。所以即使只有十分之一的烂代码在那边，也得留意。开发人员在敏捷（Scrum + 极限编程）转变过程中最大的改变是工程规范，或者说严格度，被提升到了最高。那么你能获得点什么呢？

    1.你不再需要独立估算任务了。这一被证明为最艰巨的活动，更应该由团队通过玩计划扑克来完成。结果就是，你将能得到更好的估算，并对估算有更宽泛的见解。另外，你不再需要为不好的估算承担全部责任。

    2.你必须学习结对编程。假设你在实施XP实践（强烈推荐），你就会常常这么做。这需要开发人员在心态上有很大的转变，因为这是你第一次被 迫公开你的代码做同行评审。也就是说，你有可能在过程中的任何一步被评头论足。起初很难，但收益是巨大的；由此你将成为更优秀的程序员，我保证！你的代码 将质量更高，更易于维护。

    3.你不再会写完代码往那边一扔，等着测试人员为你找bug。敏捷是建立在足够产出的前提下的，并且保持开发团队的动力，必须要求质量从一 开始就被建立起来。所以，你将要去学习怎么写单元测试。你将去学习测试驱动开发。这就是作为一名工程师，你的技能会被考验的地方，从而产出尽可能好的，高 质量的代码。回报是很高的，相信我。

    4.你应该参与到完整的点对点的交互中去。这将让你看到事情的另外一面，因为你也是一开始的user story讨论会的参与者。因此，你将从客户和产品负责人那里了解到第一手的问题，因为他们在Sprint计划会议上详细介绍了user story。你也应该是每次Sprint结束时候的回顾会议的参与者，这样从头到尾你都参与，可以提出做得好的地方，不好的地方，从而在下一个 Sprint中有所改进。

    5.你不再需要一直加班。事实上，如果你完整地执行Scrum，你根本就不需要任何加班。通过跟踪Velocity会设定出团队能够产出的最大值，这样就可以管理在任何给定的时间点，可以安排多少活儿。一次安排太多的活儿，会导致交付低于预期。我们的Agilebuddy团队（Agilebuddy是一个由我协同创立的敏捷项目管理软件，它能帮助开发团队进行敏捷转变以及管理他们的软件开发项目）每两周进行一次产品发布，从来没有失败过。我们就是通过优化足够的工作量来做到的。关于这一点，我们可以从精益思想和丰田生产系统中学到很多。

    6.如果你是流程的拥护者，你将不必再担心出现“死亡行军”或者“忙于救火”。相反，在每次Sprint的结尾，你会为已经完成的倍感骄傲，再也不想用别的方法。这需要所有的利益关系人从一开始就认同这个新的流程（这也说成功敏捷项目的一个前提条件）。

    7.每个Sprint的结束阶段，你有机会去展示你所完成的工作——锦上添花。这是分享的时刻，而不再是隐藏着，这就是跟瀑布模型项目的不同，在瀑布项目中你永远不知道什么地方或者什么时候下一个bug可能出现。

    8.你们将会以一个整体去战斗，跨越每个里程碑，还是一个整体。不再是我个人。相反，你会寻找一切机会，在需要的时候，去帮助团队成员。

    测试人员

    我职业生涯的大部分时间是工作在瀑布模型环境中的，所以我对这个“死亡行军（death march）”再熟悉不过了。这会不可避免地导致QA测试时间缩水。

    所幸地是，和开发人员类似，对于测试人员，这一情况通过敏捷方法也有所改观。它是怎么实现的呢？

    1.在每个Sprint一开始就参与其中。你可能疑惑于一个测试人员在项目早期能提供什么价值。然而，由于你必须参加Sprint计划会议，你就有机 会直接听到User Story计划。事实上，你将参与到详细制定User Story的过程当中。比如，你可以帮助确定User Story的验收测试标准。这进一步帮助了开发人员更直接地理解他们需要做些什么来通过测试。结果，发布的代码的质量和“准确性”（如，代码和最终用户需 求的符合程度）有了显著提高。

    2.你将参与计划扑克活动，帮忙估算User Story的大小。参与到估算过程中意味着公司能够更好更全面地估算User Story的复杂度。这使得估算更加精确、计划更优、压力减轻、团队士气更高、?工作将更愉快。

    3.你将参与到单元测试的创建过程中去。这是测试人员增强技能的很好的一个途径。测试人员也通过他们的分析法和“怎么破坏它呢”的心态，能够为项目带来很多的价值。

    4.你应该尽可能多的将功能测试自动化。这样，你将为团队的综合效率和生产率做出贡献。精益理论提到，团队要更关注质量构筑和浪费最小化， 因为相较于其它因素，这更有助于改良生产周期（从概念到实践）。所以，你写自动化测试，就是在为代码库的总体质量做贡献，由此缩短总体周期。

    5.在团队中，你将成为受尊重的一员，而不是只有"停止流水线"（丰田产品系统）权限的二等公民。例如，任何发现的缺陷都应该被及时解 决，即使在项目早期。敏捷理念通过建立一个有凝聚力的团队，并且把每个功能领域都当做开发来看待，来解决传统项目管理问题。事实上，Scrum项目中只有 开发人员（也就是说，如果你是Scrum项目中的一个测试人员，你就是另外一个拿到Sprint Backlog上的交付成果的开发人员而已）。

    6.因为开发人员开始编写单元测试，你将不再会收到大量的丑陋代码。因此现在你可以关注更重要的的方面了，如测试边界和边界条件，还有将你的单元测试自动化。

    7.Scrum、极限编程以及精益实践都期望所有需要交付的代码在Sprint最后都被完成（也就是说，通过单元测试，功能性测试，集成测 试）。那么每个Sprint你都会有时间去完成这些，因为所有工作（包括测试）都在Sprint计划里描述了——不只是说说而已，例如，项目的最后三周用 于测试。

    随着敏捷方法论深入人心，测试无疑也日渐成熟，在行业内测试人员比昔日得到了更多尊重。现在测试成为开发优秀软件必不可少的环节，因为它能确保软件 按着预期的功能被开发出来。基于一些像TDD、BDD之类的概念，测试工作已经由传统的后端过程转变成前端过程，这样，质量从一开始就被建立起来了。我深信，这是软件质量提高、客户满意度改善和开发团队更积极主动的头号原因。

    结论

    敏捷改进开发环境以利于最大程度上发掘团队的工作潜能，并将它转化成为难以置信的高效软件开发周期。它也顾及到了软件开发过程中个人效率和生产率的 因素，弱化了公司层级限制从而来更好地支持功能性的团队。转变成为一个敏捷组织并采用Scrum方法要求软件开发团队的所有部门同心协力，并愿意做出改 变。最初，随着Scrum实行而来的改变看起来很痛苦。转变的技术细节很容易让人心烦意乱，失去改变的重心：对软件开发方法的转型最终会显得更有效。于 是，我总结了一些指南来帮助你们度过这一过程。基于以上所讨论的转变，以及对此举背后心态的理解，这一转变将成为高产的软件开发公司的一个直观步骤，而不 是一段摸着石头过河，探知危险领域的旅程。所以无论你和敏捷是第一次亲密接触、正在逐渐接受或已经采用了它，我都希望本文能知道你更好地处理Scrum项目中的一系列改变。

作者简介：

    Jack Milunsky，Brightspark公司的共同创始人之一、首席运营官和Scrum Master。Agilebuddy是一个敏捷项目管理软件，它能帮助开发团队进行敏捷转变以及管理他们的软件开发项目。