是否有特定的用户故事场景邪恶？

Question

所以我知道,当涉及到用户故事场景时,具体是一件好事.但是,我经常谈到自己的问题:我的情景有多具体？

例如,对于用户故事:

为了允许项目成员在项目上进行协作,作为项目经理,我希望能够注册新项目

我们可以有以下场景:

鉴于项目从未在系统中注册过,当项目经理注册该项目时,注册的项目应出现在指定成员的项目列表中

或者我们可以更具体地说:

由于斯科特是一名项目经理和计算器一体化项目从未在系统中登记,当斯科特注册计算器集成项目指定简作为项目成员,则计算器一体化项目应该会出现在简的项目的列表

在编写BDD规范时,我发现了第二个"更具体"的方法.有像scottTheProjectManager而不是projectManagerStub的东西是:

• 更符合现实世界(我们没有存根作为项目经理......或者我们呢？)
• 在规范上下文中需要时更容易引用(否则,我将继续说"项目经理"或"注册项目的项目经理"......等.

我的结论是对的吗？当故事发生变化时,这种特殊性会对我有害吗？

非常感谢!

---

更新

上面的问题不仅仅是关于拥有人名而不是角色名,而是关于用实例的名称替换场景中的所有占位符.实际上,我并不是说我们实际上有一个名叫斯科特的人担任项目经理,它只是给抽象占位符命名以实现上述好处.

我将尝试通过包含以下代码来展示如何实现这些好处,该代码使用StoryQ框架表示完整的BDD样式规范

[TestFixture]
public class ProjectRegistrationSpecs
{
    [Test]
    public void ProjectRegistration()
    {
        new Story("Project Registration")
            .InOrderTo("allow project members to collaborate over a project")
            .AsA("project manager")
            .IWant("to be able to register new projects")
                .WithScenario("New Project Registration")
                    .Given(ScottIsAProjectManager)
                        .And(StackoverflowIntegrationProjectHasNeverBeenRegistered)
                    .When(ScottRegistersStackoverflowIntegrationProjectSpecifyingJaneAsAnAnalyst)
                    .Then(StackoverflowIntegrationProjectShouldAppearInJanesListOfProjects)
        .Execute();
}

//Since Scott and Jane are just instances that have meaning in the context of this user story only, they're defined private
private ProjectManager scottTheProjectManager;
private Project stackOverFlowIntegrationProject;
private Employee janeTheAnalyst; 

    //Initialize the stubs in the constructor
    public ProjectRegistrationSpecs()
    {
        scottTheProjectManager = new ProjectManager()
        {
            Id = new Guid("{A1596CFC-5FA5-4f67-AC7E-5B140F312D52}")
        };

        stackOverFlowIntegrationProject = new Project()
        {
            Id = new Guid("{F4CD5DDE-861E-4e18-8021-730B7F47C232}"),
            Name = "Stack Overflow Integration"
        };
    }
    private void ScottIsAProjectManager()
    {
        container.Get<IDataProvider>().Repository<ProjectManager>().Add(scottTheProjectManager);
    }
    private void StackoverflowIntegrationProjectHasNeverBeenRegisteredInTheSystem()
    {
        var provider = container.Get<IDataProvider>();
        var project = provider.Repository<Project>().SingleOrDefault(p => p.Name == stackOverFlowIntegrationProject.Name);
        if (null != project)
        provider.Repository<Project>().Delete(project);
    }
    private void ScottRegistersStackoverflowIntegrationProjectSpecifyingJaneAsAProjectMember()
    {
        stackOverFlowIntegrationProject.Members.Add(janeTheAnalyst);
        scottTheProjectManager.RegisterProject(stackOverFlowIntegrationProject);
    }

    //instead of saying something like TheProjectThatWasAddedByTheProjectManagerShouldAppearInTheProjectMembersList, we have: 
    private void StackoverflowIntegrationProjectShouldAppearInJanesListOfProjects()
    {
        Assert.That(janeTheAnalyst.Projects.Any(p => p.Id == stackOverFlowIntegrationProject.Id));
    }
}

Answer 1

“用户角色”是一个非常强大但难以掌握的概念。如果做得好，它们可以引导您获得简化、优化的用户体验。如果做错了，他们会占用时间，并给团队中的人一个互相吼叫的主观理由。

查看http://www.agile-ux.com/2009/12/02/personas-in-agile-development-yes-we-can/作为起点。关于这个主题的文献有大量，但大多不是专门针对 BDD 的。

我能给出的最重要的建议是，在定义你的角色时，重要的是要非常具体地说明什么让他们高兴/激励/沮丧，但这种特殊性应该是针对整个世界或一般计算而言的 - 唐不要将这些东西与产品的特定方面或个人对产品的期望联系起来，否则 1) 角色很快就会过时，需要重新创建；2) 这些人最终会被用作主观武器，以进一步提升你的个人能力。愿望，而不是作为基于事实的工具来改进为真实的人们提供最好的产品。这说起来容易做起来难。