SCRUM: 敏捷团队的故事（SCRUM: The Story of an Agile Team）——（3）

测量开发速度

  你想知道在当前迭代版本中自己的表现如何吗？常用的方法就是通过燃尽图来看：

  上图中有五天的工作时间，假设我们能完成该迭代版本中的十个关键功能点。图中的每个点的数值代表每天结束时待完成的需求。绿色线表示一种理想的状态：每天都固定完成两个功能点。而红色线则表示我们实际工作完成情况，或者说是真实的开发速度。
  这幅图并不是在任务板上的图片，但我们团队通常会拿A4纸为每个项目做一份燃尽图，放到任务板上。当一天结束的时候，团队里会有个人来负责记录当天工作的完成情况。如果程序员们一条一条实现需求时，很容易就能知道还剩多少需求未完成。
  没有完成一半的需求，完成就是完全完成，没完成的话不能记录到燃尽图上。
  当然，这个假设基本会失败。一开始会和估计的一样，但接下来发生的事情则不可避免。由于无法准确预测你能实现多少个功能点，实际上第一张燃尽图可能会像这样：

  我们的第一张燃尽图肯定是和这张图类似的。我认为我们甚至连承诺的一半都完成不了。为什么呢？因为预估是很困难的。无论你做什么，或者你多么有能力，当别人问你如何完成一件你之前从未做过的事时，你很难能给出一个准确的预估。不过不要难过，尽自己最大努力就好。随着时间的推移，这样的事情将渐渐变得容易。在面对小版本的功能点时，也许你能够达到70%的准确预估。如果版本比较大，那准确率可能也会低一些，因为会有更多的功能点需要预估，这时导致错误的因素也在增加。
  当发生上述情况时，你做了些调整。在下个项目中，你只用了四个节点，像这样：

  这又是一种不好情况：你太过保守，因此将任务提前完成了。基于之前失败的预估来看，团队经过调整之后出现这种结果是很正常的。但从另一方面来看，这还是失败了。
  问题出在哪儿呢？当完成计划任务后你都做了什么？另一个需求吗？你是如何将这些进度记录到燃尽图中的？此时不能再按原本的线来画燃尽图。
  当使用燃尽图来记录工作时，建议对最后的3-5张图取平均，作为下一个项目的参考依据。当然，一开始你没有这些信息，所以失败也是很正常的，没有关系。
  一段时间后，你的燃尽图将会越来越像第一张例图：大部分情况下，能够维持不变的速率处理一个又一个关键点。

速率？

  这个词表示开发速度，与你在项目中能够做多少事情有关。敏捷开发中有一个很关键的概念之一便是持续不变的速率，使团队能够持续交付。在传统的项目管理中，项目做得越久，速率就会越慢。有一种复杂而又强硬的力量使得开发速度减慢。
  敏捷开发的方法论和技术的目的都是维持持续的开发速度：现在交付得快，以后要交付得更快。这要如何实现呢？Scrum是问题的关键之一。其他关键点也包含了开发让代码和开发过程更顺畅的技术，例如XP（极限编程），结对编程，TDD（测试驱动开发）等。所有这些合起来，能够让一个团队更加出色。
  所以，我们想要测量速率的话，真正该做些什么？

提示：测量速率是为了能更好地做出预估，而不是用来判定一个团队或其成员的能力。

  通过速率来确认团队能做什么、想做什么、收获更多、变得更好。永远不要用速率来评判团队或计算程序员的生产率。

不停地回顾和提升

  随着最初几次迭代的进行，我们的流程管理员完成了整个团队的搭建。开始时的几周，他一直在问我们有没有什么地方做得很好或做得不足的。一开始你可能会对此感到不舒服，但这的确非常重要。描述过去几周你感受到的不足之处，这会形成一种意识。另外这也能提醒你哪些地方做得很好。
  这些会议更像是一种回顾，给了一定范围来突出好和不好的事情。以下是几个我自己回顾的例子。

不足之处

• 团队成员间的争吵过多
• 团队成员X和Y在结对编程的时候不能很好地合作
• 我们在许多小事上浪费了太多时间，比如X事件和Y事件
• 我们并没有全程都结对编程
• M模块没有进行单元测试

  当在讨论问题时，尽量不要代入个人情感，说说哪些事情困扰了你。这是团队解决问题的唯一方法。最重要的是，要立刻给每个问题提供一个解决方案。不能只是将问题列出来，然后就忘记，应该要停留几分钟，让整个团队一起考虑在接下来的一周怎么避免出现同样的问题。

做得好的地方

• 我们按时完成任务
• 我们不用吵架，可以正常沟通
• 我们中的一部分人变得更加尊重建议和想法
• 我们用TDD方法完成所有代码的编写

  重申一遍，特别是在项目刚开始的时候或是对一个初级的程序员来说，应该尽可能多地突出做得好的地方。例如，能够将所有代码都按照TDD方法完成，对于一个新团队来说算是一个比较大的成就了，让他们为之兴奋，并想要做得更多。这对于一个老团队来说也是同样有效的，找些别的事来突出就好。

我想知道你在这次迭代中做了什么

  demo是用来告诉利益相关人员（和产品负责人）项目进展如何。
  标题来自我的流程管理员。在某种程度上，他也可以算是产品负责人。在一次迭代结束的时候，他会让我们上报我们都做了些什么。我们准备一个demo或在可控环境中的工作示例。
  Scrum在每次迭代结束的时候需要这些demo，demo要在上述的回顾会议之前做好。团队要准备好特殊的环境，确保产品能够正常展示这次迭代中的所有功能特性。demo是用来告诉利益相关人员（和产品负责人）项目进展如何。
  你可能会好奇为什么在每次迭代结束时，对于开发完成的产品要特意提到可控环境。产品的确是要尽可能开发完成，但一些功能特性本身可能还未完成。通常，会有一些功能点较大，需拆分多个版本完成。即产品是稳定的，但有功能特性还未实现。当利益相关人员在看demo的时候，他们希望看到这些功能特性能正常运行。因此在大多数情况下，为了展示这些未完成的功能特性，需要先准备一个特殊的环境。
  另外，通过这些demo，产品负责人将判定这些大功能点是否好用，并决定是否要给客户发布一个新版本。大部分情况下，一个功能特性并不完善，但版本发布能够带来有价值的用户反馈，此时再逐步完善这一功能特性，尽可能地使更多用户感到满意。
  这听起来还挺容易的。你们是一个敏捷团队，保持和绿线一样的工作速度，产品将会处于稳定的状态。快速地准备一个demo有多难？比你想象的更难！
  如果我没记错的话，我们团队需要做至少五次的尝试才能做出正确的demo。幸运的是，前几次在展示失败的demo时，利益相关人员并不在场。

我们仍需要更多的指导

  正是这个时间，我们的流程管理员打算开一个每日例会。是的！每天，每个早上，一个小时！
  我觉得这对一个新团队来说是件好事，因为成员间互相不熟悉，对项目也不熟悉。像这样的每日例会叫做Daily Scrum，每天某个固定时间点在团队内部开会。这个会议要在各自的工作开始之前进行。我们团队是每天早上10进行例会，这并不容易。不过这个决定是正确的。
  每日的Scrum会议都比较简短（不过超过十五分钟）。这能使团队里的每个人都知道谁在做什么事情，并讨论出开发项目中的难点和瓶颈。

提示：为了确保会议时间较短，我们都站着开会。人们通常站15分钟之后感到疲劳，用来开会刚刚好！如果你的同事找了个地方坐着休息，那么会议时间通常会持续较久。

在站会中，每个人都必须回答这三个问题：

• 你昨天做了什么？-要简洁地回答-最多2~3句话。
• 你今天打算做什么？-同样要简洁地回答，像这样“我今天打算完成这个需求。”
• 你的进度有什么问题吗？如果答案为是的话，这些问题能快速解决吗？如果知道答案的话，回答时要突出问题和解决方案，但不要对细节进行讨论，会议仍继续进行。流程管理员需记录下这些问题，和团队成员一起解决这些问题，不过要在会后进行。

  对团队来说，解决开发人员的困难和阻碍是高优先级的事，以便他们能尽快继续开发工作。通常情况下，个人的问题都能自己解决；有些时候他们需要团队其他人的帮助；还有一些时候，问题比较严重，需要整个团队的人停下手上的工作，一起解决一个问题。
  我记得我的团队有几次在不同情况下遇到过这样的大问题。有一些任务和需求，刚看的时候相当明确，但当有开发人员深入钻研这个问题时，明确的地方慢慢变得有问题或是错的。我们多次发现第三方库无法提供基本功能的支持，然后停下手中的工作去找一个更完整的库，甚至我们自己写一个库来解决这一问题。
  我们大部分程序是基于PHP开发。在某些时候，我们不得不将我们的项目接入VMWare。我们重新看了一半VMWare API的正式库，发现有Java和Perl的版本，也有非官方的Ruby版本。当确认我们能够使用其中一个版本后，只要在PHP中加入一些exec()调用，获取输出信息转化为字符串。我们认为解析信息是件很简单的事。
  但结果是，接下来的步骤更加难以实现。没有任何API库能做到我们想要的样子。基本上不是弃用了，就是不完整，几乎没可能解析出输出信息。最后，我们只好做了件没人做过的事情：在PHP中引用VMWare的 API库。不幸的是，除此之外没有任何可行的方法。
  问题很严峻，导致进度推迟了一周！当然，我们的产品负责人立刻注意到了这个情况，之后我们制定了新的计划，添加了新的需求，其中就包括创建API库。
  通常你的问题会小很多。人们经常会被复杂的逻辑绕晕，但这种情况通常在第二天早上的时候就能够有想法和解决方案。其他情况下有可能只是走错了方向，只要团队成员帮忙回到正轨就好。这些基本上就是典型的问题了。

结论

  至此我们可以得出结论。至少，这些是我们团队开始Scrum方法的经验。有些规则是非常有用的，有些则还好。进一步来说，有些规则只在短期内有用，而有些至今仍受到我们团队的推崇。
  我只能说你若想实现敏捷过程，试一试Scrum方法，并总结自己的观点。我相信你一定会找到点儿什么运用到你的团队中。想要敏捷，要从你的工作方式开始改变，为了你的项目和个人，不要害怕加入你自己的规则。
  毕竟，敏捷是适应，不是盲目地遵循一套事先就决定好的规则。

原文地址：https://code.tutsplus.com/tutorials/scrum-the-story-of-an-agile-team–net-29025