提示：本文共有 967 个字，阅读大概需要 2 分钟。
读《用户故事与敏捷方法》有感四
在一个大型项目中，尤其是有许多用户角色的项目，确定用户故事有时让人无从下手。我发现最好的办法是考虑每一个用户角色，了解用户使用我么软件的目的。
所以编写故事的时候注意以下几点。第一，根据实现时间来确定故事规模，逆向专注于最需要你关注的领域。通常，这意味着要把注意力放在那些即将发生的事情上，而不是放在更远的将来才发生的事情上。对股市而言，要基于故事实现的时间跨度，以不同的层次来编写故事。例如，对于下面几轮迭代的故事，它们的大小应该能够安排进那几轮迭代中，而对于更遥远的故事，它们可能会更大，但精准度则更低。第二，不要过早设计用户界面，一直困扰软件需求方法的问题之一是将需求和解决方案混在一起。也就是说，在陈述需求的时候，也显式说明或暗示了解决方案。最常见的情况是用户界面，这个应该放在最后边考虑。第三，不要忘记意图，不要忘记，故事啦的主要目的是用来提醒开发人员和客户团队对功能进行讨论的。既然仅仅是一个提醒，就要保持它的简洁性。加入需要的细节，以便联想到继续对话的切入点，但不要在故事卡上加入太多细节并以此取代对话。
接下来我们就需要着手估算用户故事了，首先一定要找到故事点。有一种可以满足所有这些目标的估算方法，即用故事点估算。故事点有个很好的特性是团队可以定义自己认为合适的故事点。一个团队可能决定定义一个故事点为一个理想日的工作。另一个团队可能定义一个故事点为一个理想周的工作。还有一个团队可能把故事点作为故事复杂度的测量。因为故事点有很多意义，有意Joshua Kerievsky认为故事点代表时间的模糊单位。
我们可以将一个故事点的工作量看做是一个理想日的工作。我们极少会有这样的理想日，但是用理想时间考虑故事有两个好处。第一，相对于用连续的时间估算，它更简单。用持续时间估算破事我们考虑对时间的各种可能性影响，例如，星期二全公司会议，星期三约了牙医，每天花几个小时回邮件等等。第二，相较于用完全模糊单位没用理想日估算故事点可使我们的估算拥有更好的依据。估算的主要目的之一是知道整个项目的工作量，所以最后我们总是要将估算换算成时间。显然，相较于完全模糊单位，用理想时间更简洁。
安排好故事点后，我们需要将汇集的故事点转换成项目的预计工程。答案当然是使用速率，迭代轮数等于理想日除以使用速率。
看到此处说明本文对你还是有帮助的，关于“读《用户故事与敏捷方法》有感四”留言是大家的经验之谈相信也会对你有益，推荐继续阅读下面的相关内容，与本文相关度极高！
