2009年7月21日,星期二,01:00

故意不完整

撰写者

'm certainly happy to be joining the community. So, a little about me-

我叫Bob Galen,来自北卡罗来纳州的卡里。我已经在25年的大部分时间里从事软件开发工作,例如开发人员,经理,总监,项目经理,测试人员和项目经理。

在过去的十年中,我一直在将自己的思想和实践转向那些拥护敏捷方法论的人们。我发现它们是交付软件时最一致,最人道和最有效的方法,我尝试与遇到的每个人分享我的见解。

观点-您将在我的博客文章中看到与以下主题领域相关的严重偏斜:

  • 软件测试对广管局的影响
  • 敏捷对BA的影响
  • 广管局的领导力和软技能主题

这样您就可以感受到即将来临的景点。但是,足够了...

敏捷社区中的关键需求工件是用户故事。迈克·科恩(Mike Cohn)做了出色的工作 用户故事介绍 书。稍后我可能会对该主题进行更多定义,但是现在我想探讨用户故事的一个关键特征。那个特点是-

用户故事是 故意不完整。是的,你明白我的意思了。这是模棱两可的。它有明显的孔。它引发了许多问题。这些问题也来自不同的角度。开发人员的设置与测试人员的设置不同。或广管局。还是建筑师。甚至是“客户”。

定义不明确的需求有什么意义?我会告诉你。这是为了从实现所需的不同角度出发围绕每个需求进行对话。您会看到这些问题是预料之中的...实际上,敏捷团队需要这些问题。有“过程和工具上的人与协作”的敏捷宣言概念,而用户故事是这种协作的发起者。

我认为它不是双向协作,而是多方协作。最低限度地,当团队成员选择要实施的用户故事时,他们会聚集在三个主要角色的三个角色中:以开发为中心,以测试为中心以及以业务/客户为中心的视图。他们从各自的角度讨论故事的细节并加以完善。

不仅对其进行完善,而且还可以利用迄今为止从以前的故事开发和项目执行中收集的所有知识。这是关键。您推迟特定的定义,以实现执行的每个Sprint或Iteration都会获得更丰富的信息。因此,这种“工作软件”知识也被融入到每个用户故事的演变中。另一个推动因素是精益的 Just-in-Time 和 Just Enough 在软件开发方面进行思考。事实证明,我们在软件开发工作中常常很冒昧。我们假设无需先编写某些软件就可以预测软件需求或设计甚至规划的未来。

这种方法可能适用于简单或过时的事情,但不适用于复杂的应用程序或针对客户问题的新颖,新颖且具有竞争力的解决方案。

对于那些在这种基于对话的需求方法中苦苦挣扎的人,我将有最后的想法。您是否见过书面要求推动开发和测试工作,当将两者结合在一起时,代码与测试不匹配?当然有我已经看到这种情况经常发生。所以当 写作g 需求是好的和必要的,用户的故事也许正在触及我们需求制定中的一个重要但缺少的元素。

未完待续...


罗伯特·鲍勃·加伦 是RGCG L.L.C的总裁兼首席顾问。 Bob曾在软件开发和质量保证组织中担任过董事,经理和贡献者级别的职位。他拥有超过25年的经验,涉及广泛的软件技术和产品领域。鲍勃可以在 [email protected]

罗伯特·加伦

罗伯特·鲍勃·加伦 是RGCG L.L.C的总裁兼首席顾问。基于NC的Cary敏捷方法指导&培训顾问。他是一位经验丰富的敏捷教练,活跃于敏捷社区并定期撰写文章。&讲授与敏捷方法有关的所有主题。鲍勃写了这本书 Scrum产品所有权,重点放在团队交付中的角色和驱动价值上。鲍勃可以在 [email protected] 并通过他的LinkedIn进行联网 个人资料.

©BA Times.com 2020

麦格雷戈徽标白色网站