Agile - Scrum bug故事点、保护团队、非功能性需求、什么项目适合敏捷开发（转）

应该为bug修复的故事安排故事点吗

如果团队不为这些工作安排故事点(值),团队速率就只能显示团队在每个sprint中的“新的工作”的工作量。

如果团队为修复bug的工作安排故事点，团队速率能代表团队的真实的完成工作的容量。

我通常的推荐是为bug修复的工作安排故事点。这样我们能看到团队能完成的真实的工作是多少，同时也能通过历史数据看出每个Sprint中我们花了多少工作在bug修复中。

从两方面保护团队

保护团队是ScrumMaster的其中一个职责已经是总所周知的事情。一个经常被提及的例子就是ScrumMaster保护团队免受激进的ProductOwner的压力。这个例子本身并没有什么问题，因为很多团队都需要ScrumMaster的保护，否则ProductOwner就很有可能会迫使团队放弃一些质量来完成更多功能特性。然而，一个好的ScrumMaster同时也需要保护团队避免其遭受“自满”的侵害。

一位优秀的ScrumMaster有时会对激进的ProductOwner说：“现在还不是对团队施加压力的时候。他们已经尽力了，要是再给他们压力的话，他们可能会崩溃的。”但是我对优秀ScrumMaster的建议是，每次对ProductOwner说完这句话以后，稍后不妨找个合适的时间然后跟ProductOwner说：“现在团队已经准备好了，是时候激发团队的潜能了。”

非功能性需求的用户故事

幸好，限制或者说非功能性需求也能够很容易的使用用户故事的方法表达。下面是一些例子：

• 作为一个客户，我希望能在Windows95之后的所有版本上运行你们的产品。
• 作为CTO，我希望系统能使用现有的定单数据库，而不是重新创建一个，这样我们就不会有两个数据库需要维护。
• 作为一个用户，我希望这个网站在99.999的时候我都可以在想访问的时候可以访问它，这样我不需要麻烦去找另一个站点。
• 作为一个使用拉丁语使用者，我希望某一天也能使用这个系统。
• 作为一个用户，我希望90%的情况下我的驾驶方向都是正确的，而99%的情况下我所花的时间都是合理的。

如上面例子中所示，我其实很容易就能使用“作为。。。，我想要。。。，这样。。。”的模板，我倾向于在大部分用户故事中使用这样的模板。

什么样的项目最适合于敏捷开发

我认为在决定一个项目是否适合于使用敏捷方法的最终因素是紧急性。敏捷方法中的时间箱和迭代就是为了保持项目中的紧张度和专注度。如果项目没有紧急性，这些就是不需要的。

最适合敏捷方法的项目是那些有着激进的时间期限限制，那些有着高度的复杂程度，以及那些有着高度新颖性（独特性）的项目。

一个我们大家都听过的适用于Scrum的情形：婚礼筹备。