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

[url=http://www.scrumcn.com/architecture/html/?255.html]应该为bug修复的故事安排故事点吗[/url]
如果团队不为这些工作安排故事点(值), 团队速率就只能显示团队在每个sprint中的“新的工作”的工作量。
如果团队为修复bug的工作安排故事点，团队速率能代表团队的真实的完成工作的容量。
我通常的推荐是为bug修复的工作安排故事点。这样我们能看到团队能完成的真实的工作是多少，同时也能通过历史数据看出每个Sprint中我们花了多少工作在bug修复中。

[url=http://www.scrumcn.com/architecture/html/?332.html]从两方面保护团队[/url]
保护团队是Scrum Master的其中一个职责已经是总所周知的事情。一个经常被提及的例子就是[color=red]Scrum Master保护团队免受激进的Product Owner的压力[/color]。这个例子本身并没有什么问题，因为很多团队都需要Scrum Master的保护，否则Product Owner就很有可能会迫使团队放弃一些质量来完成更多功能特性。然而，一个好的Scrum Master同时[color=red]也需要保护团队避免其遭受“自满”的侵害[/color]。
一位优秀的Scrum Master有时会对激进的Product Owner说：“现在还不是对团队施加压力的时候。他们已经尽力了，要是再给他们压力的话，他们可能会崩溃的。”但是我对优秀Scrum Master的建议是，每次对Product Owner说完这句话以后，稍后不妨找个合适的时间然后跟Product Owner说：“现在团队已经准备好了，是时候激发团队的潜能了。”

[url=http://www.scrumcn.com/architecture/html/?244.html]非功能性需求的用户故事[/url]
幸好，限制或者说非功能性需求也能够很容易的使用用户故事的方法表达。下面是一些例子：
[list]
[*]作为一个客户，我希望能在Windows95之后的所有版本上运行你们的产品。
[*]作为CTO，我希望系统能使用现有的定单数据库，而不是重新创建一个，这样我们就不会有两个数据库需要维护。
[*]作为一个用户，我希望这个网站在99.999的时候我都可以在想访问的时候可以访问它，这样我不需要麻烦去找另一个站点。
[*]作为一个使用拉丁语使用者，我希望某一天也能使用这个系统。
[*]作为一个用户，我希望90%的情况下我的驾驶方向都是正确的，而99%的情况下我所花的时间 都是合理的。
[/list]
如上面例子中所示，我其实很容易就能使用“作为。。。，我想要。。。，这样。。。”的模板，我倾向于在大部分用户故事中使用这样的模板。

[url=http://www.scrumcn.com/architecture/html/?249.html]什么样的项目最适合于敏捷开发[/url]
我认为在决定一个项目[color=red]是否适合于使用敏捷方法的最终因素是紧急性[/color]。敏捷方法中的[color=red]时间箱和迭代[/color]就是为了保持项目中的[color=red]紧张度和专注度[/color]。如果项目没有紧急性，这些就是不需要的。
最适合敏捷方法的项目是那些有着激进的[color=red]时间期限限制[/color]，那些有着[color=red]高度的复杂[/color]程度，以及那些有着[color=red]高度新颖性[/color]（独特性）的项目。
一个我们大家都听过的适用于Scrum的情形：[color=red]婚礼筹备[/color]。