我正在为朋友的企业编写一个小应用程序，同时想借此机会复习一下我在年初接受的敏捷项目管理培训。
我个人（而且我认为我的当前组织也是如此！）总是很难以用户故事的形式收集需求，其格式为：
作为[用户类型]，我希望[功能]，以便[某些好处]
我总是诱惑于省略开头和结尾，只留下功能 - 但这就变成了传统的需求收集方式！
但我不想仅仅因为“我正在实践敏捷”而将它硬塞进去……例如，如果我知道用户将被呈现一个项目列表，那么原因是不是显而易见？
例如：
作为[商店经理]，我希望[看到库存项目的列表]，以便……？
是否有省略[以便]从句的常规做法？
当然，这实际上可能并不适用于您。我的真正观点是，人们想出这个模板的原因是有道理的——同样，很多经验丰富的人实际上并不使用它。当您刚开始实践时，无法评估遵循某种做法的利弊，因此我强烈建议尝试紧密遵循一段时间。您可能会对其有用性感到惊讶——或者不会，如果是后者，您仍然学到了东西，并可以清晰明了地放弃它... :)
我认为你应该尽力定义一个理由，即使它可能看起来很明显。如果你无法想出一个理由，那么为什么要首先构建这个功能呢？此外，这个理由可能会指出设计中的其他不足之处，从而触发其他领域的改进。
我经常根据故事主要涉及的用户/角色进行分类，因此我不会在故事标题中放置用户的身份。我的故事也比一些敏捷方法论建议的要大。通常，我从一个标题开始。我用它来进行规划。一旦我接近实际处理该故事，我会加入一些细节--基本想法、限制、假设、相关故事--以便我能够捕捉更多我所知道的信息。我还将我的故事保存在维基上，而不是在笔记卡上。我理解这种权衡——即，在需要之前我可能会花费太多时间在细节上，但我能够轻松地捕捉和分享它，通常是与离岸客户。
对我来说，敏捷是一种哲学，而不是规范。有特定的实现方式可能会（强烈）建议您以某种方式完成某些事情，并且在某些项目上可能是不可协商的。例如，如果您不进行配对编程，很难说您正在执行XP。总的来说，我认为大多数敏捷主义者会说，只要符合一般原则，您应该按照适合您的方式做那些适合您的事情 - 即使它们与特定实现方式不同，您仍然可以称自己为敏捷。一般原则包括早期发布/经常发布、单元测试、短迭代、承认变化将发生、延迟详细计划直到准备实施等。