管理大型项目的用户案例
我们刚刚开始一个有很多子项目的大型项目。我们目前不使用任何类型的命名过程,但我希望在后门获得某种敏捷/类似Scrum的过程。
我将最关注的领域是整个项目的良好积压,至少在我看来,是一种迭代的思想,其中从积压中获取了一些东西,对其进行了更详细的研究并发展到合理的期限。
我想知道人们使用什么技术将项目分解为待办事项,一旦创建了待办事项,便如何维护和排序。以及如何维护元素之间的关系(即必须在可能之前做到这一点,否则这是一个故事,现在是五个故事)
我不确定这个问题的答案会是什么样子。我认为最有帮助的是,如果有一个开源项目以某种方式保持其积压的在线状态,以便我可以看到其他人是如何做到的。
从我这里获得+1的其他事情是来自真实项目的真实用户故事的示例("用户可以登录"故事并不能帮助我描绘项目中的内容。
谢谢。
解决方案
我不确定这是否是我们要寻找的东西,但它可能仍会有所帮助。 Codequeeze的Max Pool提供了一段解释他的"敏捷墙"的视频。看到他的过程很酷,即使它不一定与问题有关:
我的敏捷墙(加上一些技巧)
因此,这里有一些提示:
我们使用RallyDev。
我们创建了我们的需求所在的软件包视图。
大故事被标记为史诗,并放置在它们打算用于的发行版本的发行积压中。儿童故事被添加到史诗中。我们发现最好使故事保持非常细致。粗糙的故事使难以真实地估计和执行故事。
- 通过发布进行组织
- 将迭代保持在2-4周之间
- 产品负责人和项目经理在发布的待办事项列表中添加故事
- 开发团队会根据TShirt的大小,分数等来估算故事。
- 在Spring计划会议中,开发团队从发布积压中选择迭代的工作。
因此,通常:
这是我们过去4个月来一直在做的事情,发现它运作良好。保持故事的大小细小非常重要。
记住用于评估用户故事的Invest和Smart首字母缩略词,一个好的故事应该是:
我独立
N面议
V值
E估计
小
可测T
聪明的:
S特定
M可测
可实现的
R相关
T盒装
首先,我要说"保持简单"。将共享的电子表格用于跟踪(和备份)。如果看到扩展或者同步问题,使得将待办事项保持在一致状态会变得越来越耗时,请进行交易。这将自动验证并证明支出/再培训成本的合理性。
我已经从Thoughtworks中阅读了有关Mingle的一些好东西。
像DanielHonig一样,我们也使用RallyDev(小规模),这听起来可能对我们至少是个有用的系统。
另外,关于用户故事开发方法的一本很棒的书是Mike Cohn编写的《用户故事》。如果我们还没有的话,我当然会建议我们阅读。它应该回答很多问题。
我建议我们在使用工具之前要仔细考虑,特别是因为听起来好像脚步刚开始时过程可能会很不稳定。我的感觉是,在此阶段,一种工具可能比启用我们更容易约束我们,并且我们会发现它无法替代物理空间中的优质卡片墙。我建议我们改为将精力集中在手头的任务上,并在觉得自己确实需要一个工具时拿起一种工具。到那个阶段,我们将很可能对要求有了清晰的认识。
我现在已经运行了几个敏捷项目,我们再也不需要比电子表格更复杂的工具了,而且这个项目的预算超过一百万英镑。通常,我们发现白板和索引卡(每个用户故事一个)足够了。
在标识故事时,请确保始终以对用户有意义的术语来表达它们,其中有些(也许只是很小的)表面功能。永远不要让自己写关于我们无法向用户展示的技术细节的故事。
安排故事的技巧是尝试优先安排我们最不了解的事情(计划要学习的内容,而不是要做的事情),同时还要从故事开始,以开发核心功能应用程序,使用后续的故事来围绕它们包装功能(和技术复杂性)。
如果我们确信可以在以后再解决一些难题,请不要着重于细节,只写一张代表我们以后需要进行的重要对话的故事卡,然后继续与更重要的东西。如果我们需要了解即将发生的事情,请查看一种称为计划扑克的宽带delphi估算技术。
迈克·科恩(Mike Cohn)的书,特别是《敏捷估计和规划》将在现阶段为我们提供很多帮助,并为我们提供一些有用的技术。
段落数量不匹配