软件从业人员如何激发敏捷团队？

集中办公

怎样才能极大地提高团队的生产效率呢？答案是让每个人都坐在一起。

集中办公的团队效率就是要高一些。问题不仅可以很快地在现场得到解决，而且彼此间的交流也会更加顺畅，并能很快建立起信任。集中办公的小型团队竞争力是非常强的。

那么，既然集中办公的团队这么好，是否意味着分布式团队就无法运作敏捷项目了呢？绝对不是。

对于很多人来说，分布式办公正在成为一种生活方式。虽然相比紧凑型集中办公的团队，分布式团队总会有些劣势，但仍可以用很多办法来加以弥补。

比如，在项目的初始阶段，为了将所有人都召集在一起，你要预留一些时间。哪怕是只有几天也好（如果能延长到几周就更好了），大家在这段时间内互相认识一下、开个玩笑、一起吃个饭，这非常有助于你把形形色色的人聚合在一起，打造成一个紧凑高效的团队。因此，在开始阶段，就要将所有人都聚在一起。

之后，即使没有集中办公，你也可以使用书本中提及的所有沟通工具和技巧（Skype、视频会议和社交工具），使你的分布式团队看起来像一个集中办公的团队。

专职客户

当今仍有很多团队编写的软件没有专职客户。这很可悲，甚至可以说是一种犯罪。

如果产品的使用者没有纳入到进程中，怎么可能期望团队能够建设优秀而具有创造性的产品呢？

专职客户会在演示版中现身、解答问题、给出反馈，并为团队建设优秀软件提供必要指导和洞见。他们是团队的核心成员，是交付过程中的全面合作伙伴。

正是由于这个原因，诸如极限编程和Scrum这样的敏捷方法都尽量实现客户的专职化，比如采用现场客户，或像Scrum那样设立专门的产品负责人。这是一项很重要的工作。稍后我们会对这些角色加以详述。

也正因为这样，任何成功的敏捷项目都需要专职客户。

现在你可能心存疑惑：“没有专职客户，应当怎么做？” 那是因为可能他们过去曾经失望过，也可能他们认为根本不需要现在这个项目，或者他们只是认为你根本交付不了。

不管有什么问题，如果你想建立某种客户信誉，那就得这么办……

下一次面对客户时，请告诉他们：从现在起会在两周内解决他们提出的一些问题。

不需要征求谁许可，别搞什么不知所云的大型仪式。只管收集一些问题，了解客户的疾苦，然后将问题解决即可。

接着就是要付诸实施。两周过后，向客户展示他们的问题已经完全解决了，然后重复这个过程。再收集一些其他的问题，解决掉。

你可能需要重复这个过程三到四次（甚至更多次），才会引起他们的注意。但最终他们肯定会注意到的。

此时，他们就会对你刮目相看，了解到你的真实价值：你是一个办事靠谱、值得信赖且雷厉风行的执行者。

喏！你可以找出一千个理由来解释为什么客户不是专职的。也许他们厌倦了由IT部门去完成他们的项目，也许他们没有或者不需要将软件放在首要位置，也许你没有让他们意识到他们这种角色对于项目的成功有多么重要，或者他们可能只是真的很忙。

我絮叨了这么多，就是想说明一点：如果想建立一些诚信，那就要经常往信任储蓄罐里面放点零钱，这样才会最终赢得客户。

自组织

敏捷团队常常会设定一个目标，然后退而结网，通过共同研究来实现目标。为此，敏捷团队需要进行自组织。

自组织首先要求个人放下架子，与团队协作，将自己作为团队的一分子，想出如何发挥出个人所有的独特技巧、激情和天赋，最好地交付项目的办法。

“鲍比当然可以分割代码。但他也擅长设计，因此，还是让他帮忙做实体模型吧。”

“对，苏茜是我们最好的测试人员之一，但她真正出色之处在于设定客户期望值。她的确有一套，并且也喜欢做这项工作。”

这并不意味着开发者必须要精通可视化设计,或者立刻就要求测试者去管理项目。

这只是说建设团队的最好方法是要让角色适应人，而不是让人适应角色。

那么，该如何使团队自组织呢？

• 要让他们自己创建计划、提出估算，并对项目全权负责。

• 不要担心所谓的头衔和角色，而要更关注于不断交付出可运行且经过测试的软件。

  • 你要找的人应该具有主动性，喜欢掌控自己命运而非惟命是从。

简言之，你要摆脱束缚，信任他们并授以权力，这样工作才能完成。

现在，自组织本身就够强大了吧，但是真正的神奇之处是其所引发的授权和责任感。

勇于承担和授权

优秀的敏捷团队会对其所产生的后果勇于承担。他们知道自己是客户成功的关键，并且从一开始，他们就要交付有价值的东西，这是他们义不容辞的责任。

当然，只有团队真正地被授予权力，勇于承担才会发挥效力。让团队自己去抉择，去做他们认为正确的事情，这可以激发他们的主动性并使其独立工作。他们会解决自己的问题，不必再等待他人的许可。

当然，你偶尔也会犯错。但由于这样做优点颇多，故而值得冒险。

建立一个授权和有责任感的团队说起来容易做起来难，不是所有人都希望被授权。如果只是要混个脸熟，做个打下手的工作并且只需奉命行事，那就非常简单，何必自找麻烦呢？

如果你认为在培养团队责任感这方面有问题，那么有一个简单的解决方案——让团队演示其软件。

将团队推到现实中真正的客户面前，让他们演示软件，这会极大地提升团队的责任感。

首先，你的团队会意识到现实中有人正依赖于他们的交付。他们会意识到确实有人面临着现实中真正的问题，需要现实的软件去改善其生活。

其次，只要一次糟糕的展示，团队就会突然变得有兴趣去让软件迎接反馈，并确保一切运作正常。为此，他们会坚持要求下放权力。如果他们还不这么做，你可就有大麻烦了。

跨职能

跨职能团队要能够为客户提供全面的服务。这意味着团队要具备必要的技巧和技能，才能完成客户需要的所有特性，成功地完全交付。

当为团队招募员工时，你要招聘那些多面手，因为他们能够轻松地完成多种任务。如果想招聘程序员，就要找到那些精通整套技术栈之人（不只限于前端技术或者后端技术）。而对于测试人员和分析师来说，他们在做深度需求分析工作时，应与做测试一样轻松自如。

团队缺乏某种专业技巧（比如数据库性能调优）时才会偶尔用到专家。但通常在项目的整个过程中，团队会作为一个整体互相支持，同舟共济。

当然，跨职能团队的真正妙处在于其运转的速度。不必再等什么许可，也不必与其他人讨价还价争取某种资源，而是从一开始他们自己就可以交付有价值的东西，没人会挡他们的路。

好吧，这些就是当你组建团队时希望设置的一些期望值和为之奋斗的一些目标。

本文摘自《敏捷武士》