产品管理

    如果你是一个正在向敏捷转变的项目的产品经理，你也会有些变化。首先，你的头衔从产品经理变成了产品负责人。但这不是全部。传统环境中的产品经理主 要负责前端工作。除了他们特定的市场职责以外，产品经理典型的职责就是负责前期的产品需求文档。另一方面，产品负责人则是客户的代理。在敏捷项目中，产品 经理转换到产品负责人会有下面的一些职责改变：

    1.产品负责人是团队的积极参与者。产品负责人为产品的方向和在项目中的优先级负责，对此，他们责无旁贷。

    2.产品负责人应该参加Sprint计划会议。产品负责人通常是Sprint计划会议的第一部分的主角，他负责定义Sprint的目标以及详细说明这个Sprint计划要做的每个User Story的功能。

    3.产品负责人要负责建立、维护product backlog，并且对其给出优先级。

    4.与传统理念不同，产品负责人必须确保他/她能在团队需要的他/她的时候站出来。产品负责人是否要出席每次每日站立会议，存在着争议，但产品负责人越多得参与到团队中去，成功的可能性也越大。

    5.产品负责人也开始在一定程度上负责定义验收测试标准，就这一点而言，也意味着多少对产品的输出质量负责——因为本质上来说，验收测试标准会使开发团队一开始就把质量作为重要的一部分。

    因此，作为产品负责人，等着你的是每天更多的参与，准备好大干一场吧。

    综合管理

    鉴于敏捷团队应该是自我管理的，那么把综合管理置之何地呢，它的职责是什么呢？希望以下内容能有所启示。

    1.管理者们应该能为团队扮演一个传道士的角色，尤其是如果管理者有相应的经验——不过很难确切地说是哪些经验。这也是为什么丰田要让总技师做产品负责人。这样的支持能帮助团队避免犯错，从而节省很多时间。

    2.管理者们在面对困难时应该首当其冲，例如，他们应该帮助ScrumMaster解决掉需要管理层出手的“大”障碍，比如批准项目运作经费以确保团队能够前进。

    3.新团队尤其需要来自高层的支持和认同来让敏捷过程上路。团队很容易滑回他们的老轨道，所以管理者们必须支持团队使他们能坚持敏捷之路。

    4.管理者们还应该是“教练”，帮助团队成员做职业规划、执行绩效评估、培训或组织培训。

    5.管理者们应该关注公司更长远的战略举措（如考虑怎样处理竞争威胁、促进销售、减少开支等）。

    6.基于战略举措，管理者们应该和产品负责人紧密配合，确定好这一“鸿篇巨制”，识别出优先级，然后为产品的长远之路做好规划。

    项目管理

    Scrum本质上并没有传统的“项目管理”这一角色。那这对员工而言意味着什么呢？大多数情况，项目经理会很自然地转变成ScrumMaster。 然而，你信不信，好的ScrumMaster总是开发或者测试出身。相信我，ScrumMaster这一角色并不是很类似于项目经理。所 以，ScrumMaster候选人去参加些培训是很重要的。虽然ScrumMaster认证不是必须的，但还是很有好处。那么对于这种角色转变你能期望点 什么呢？

    1.首先作为ScrumMaster你必须承认这样一个事实：团队才是进度的主人，所以你不再需要更新由来已久的优良传统——微软Project的甘特图了。取而代之的是，你不得不退居二线，但是一开始可能你得盯着团队，让他们每天更新自己的估算。

    2.作为一个ScrumMaster，你得确保整个团队很好地遵循了Scrum流程，确保每个人都理解了Scrum是什么以及应该怎样做。

    3.团队将指望你尽可能快地去扫去障碍，或者协助他们去扫除障碍。

    4.你得通过在每次会议上重申Sprint的目标来确保团队全力以赴、坚持到底。

    5.你将组织每天的站立会议（一个每天举行的会议，会议上每个人需要回答昨天你做了什么，今天你准备做什么以及有没有障碍这三个问题），确保会议在同一时间同一地点召开。

    6.你得确保Scrum的精髓，特别是检视和适应能够被很认真地执行，这样Scrum才能按原先设计的那样良性地使用。这使得团队可以在每个Sprint中学习并有所提高。

    现在让我们来看一下，在敏捷（Scrum）项目中，开发人员和测试人员的生活会有怎样的变化。老实说，我觉得有了那两条规范，开发人员和测试人员都将从敏捷转变中获益，生活也会更加美好。