管理大型项目的用户故事

时间:2008-09-22 22:45:41

标签: project-management agile scrum user-stories

我们刚刚开始一个包含大量子项目的大项目。我们目前没有使用任何类型的命名过程,但我希望在后门获得某种敏捷/ scrum类过程。

我将重点关注的领域是整个项目的积压,至少在我的脑海中,迭代的想法是从积压中获取一些东西,更详细地查看并发展到合理的截止日期。

我想知道人们使用什么技术将项目分解为积压的东西,并且一旦创建了积压,就会如何维护和订购。还要如何保持元素之间的关系(即必须在可能的情况下完成,或者这是一个故事,现在是五个)

我不确定我希望这个问题的答案看起来像什么。我认为可能最有用的是,如果有一个开源项目以某种方式保持其在线备份,那么我可以看到其他人如何做到这一点。

从我这里获得+1的其他东西是来自真实项目的真实用户故事的例子(“用户可以登录”故事不能帮助我描绘我项目中的事物。

感谢。

7 个答案:

答案 0 :(得分:9)

我会建议你在采用工具之前仔细考虑,特别是因为听起来你的工艺在你找到你的脚时起初可能很流畅。我的感觉是,在这个阶段,一个工具可能更有可能限制你,并且你会发现它不能代替good card-wall in physical space。我建议你把精力集中在手头的任务上,当你觉得自己真的需要时,就抓住工具。在那个阶段,您可能更清楚地了解自己的要求。

我现在已经运行了几个敏捷项目,我们从来没有需要比电子表格更复杂的工具,而且在预算超过一百万英镑的项目上也是如此。大多数情况下,我们发现白板和索引卡(每个用户故事一个)绰绰有余。

在识别您的故事时,请确保始终以对用户有意义的方式表达它们 - 一些(可能只是很小的)表面功能。永远不要让自己写下关于您无法向用户展示的技术细节的故事。

安排故事时的技巧是尝试优先考虑您最不了解的事项(计划您想要学习的内容,而不是您想要做的事情),同时从可以开发的故事开始应用程序的核心功能,使用后续故事来包装它们的功能(和技术复杂性)。

如果你有信心可以留下一些难题直到以后,不要为了弄清楚这一点的细节而烦恼 - 只要写一张单独的故事卡片代表你以后需要的大谈话,继续处理更重要的事情。如果您需要了解将来的大小,请查看名为planning poker的宽带delphi估计技术。

Mike Cohn的书籍,尤其是Agile Estimating and Planning,将在这个阶段为你提供很多帮助,并为你提供一些有用的技巧。

祝你好运!

答案 1 :(得分:4)

像DanielHonig一样,我们也使用RallyDev(小规模),听起来它至少可以成为一个有用的系统。

此外,Mike Cohn撰写的一本关于用户故事发展方法的好书是User Stories Applied。如果你还没有,我当然建议你阅读它。它应该回答你的很多问题。

答案 2 :(得分:2)

所以这里有一些提示: 我们使用RallyDev 我们创建了一个包含我们要求的包的视图。 大型故事被标记为史诗,并被放入他们打算发布的发布积压中。儿童故事被添加到史诗中。我们发现最好保持故事的细节。粗粒度的故事使得难以现实地估计和执行故事。

总的来说:

  1. 按发布组织

  2. 请 2-4周之间的迭代

  3. 产品所有者和项目 经理们在发布中添加故事 积压

  4. 开发团队估计 基于TShirt尺寸的故事, 点等...
  5. 在春季计划中 开发团队选择的meeetings 为从事的迭代工作 发布积压。
  6. 这是我们过去4个月一直在做的事情,并且发现它运作良好。非常重要的是要保持故事的规模小而粒度。

    记住用于评估用户故事的Invest和Smart缩略词,一个好故事应该是: 我 - 独立 N - 面议 V - 有价值 E - 估计 S - 小 T - 可测试

    智能:

    S - 具体 M - 可衡量 A - 可实现 R - 相关 T - 时间框

答案 3 :(得分:2)

我不确定这是否是您正在寻找的,但它可能仍然有用。来自codesqueeze的Max Pool有一个视频解释他的“敏捷墙”。看到他的过程很酷,即使它可能不一定与你的问题有关:

My Agile Wall (Plus A Few Tricks)

答案 4 :(得分:1)

很多这些回复都是关于使用工具的建议。但实际情况是,您的流程将比您用于实施流程的工具重要得多。远离试图将方法塞进喉咙的工具。但是,要小心使用新工具简单地实现旧的非敏捷流程。在确定流程工具时,需要考虑以下一些重要事实:

  1. 使用软件工具检测的错误流程会导致错误 软件工具实现。
  2. 流程将根据您管理的群组进行更改。该 重要的是人,而不是过程。实施一些东西 他们可以成功地工作,您的项目将会成功。
  3. 所有这些说明,以下是一些可以帮助您的指南:

    • 从文档化流程的纯实现开始,
    • 让你的迭代变小,
    • 每次迭代后与您的团队交谈并询问他们是什么 会改变,实施有意义的改变。

    对于大型组织,如果您使用的是SCRUM,请使用级联站立机制。 Scrum大师与他们的团队见面。然后,Scrum大师以6比9的单口相遇,超级Scrum-MAster负责将Scum-Master的scrum中的项目报告到下一级......等等......

    您可能会发现每周超级scrum会议就足以满足您层次结构的最高级别。

答案 5 :(得分:1)

我首先说保持简单..使用带跟踪(和备份)的共享电子表格。如果您看到扩展或同步问题,以便将积压保持在一致状态变得越来越耗时,那么就要进行交易。这将自动验证并证明支出/再培训费用。

我读过Mingle from Thoughtworks的一些好消息。

答案 6 :(得分:1)

这是我对类似问题的回答,可能会给你一些想法

Help a BA! Managing User Stories ...