2010年5月18日,星期二,01:00

攻击敏捷积压中的技术要求

撰写者

我今天在一次会议上开会,我们试图捕获流行的SaaS产品的体系结构要求。房间里和我自己大部分都是建筑师(软件,网络和硬件)。

我们开始讨论现有系统的关键组件,以及当前的耦合如何使我们变得比我们需要的容错能力更高。组件的凝聚力,特定组件,服务和系统之间的依赖关系是我们最具挑战性的问题之一。

我们开始通过简单列出我们希望进行的功能更改来应对产品积压产品开发。例如,我们希望重新调整身份验证方案,以使其与单个客户数据库相比更符合客户分组。这将使我们能够按各种模型细分客户,从而实现更智能的管理,组处理和独立扩展。

在会议上,令我震惊的是,这些项目根本不是格式正确的积压项目,因为它们的关注范围太窄了。我们正在做的另一件事是使其与我们的技术意图和挑战保持一致。因此,从本质上讲,我们提出了由技术驱动的产品增强功能的愿望清单。这很不错,但并不是真正的精心准备。那么,我们不是在做什么?

从业务角度入手

即使可以说这是一项技术练习,我们也应该从业务角度推动它们。确定我们要解决的客户问题类型。这些问题的总体范围和影响是什么,因此从业务角度订购工作。至少应将其明确地纳入一组目标。

当您考虑技术变更时,请清楚说明成本。这真的是范围,功能和行为的必要更改吗?运行镀金检查,以确保它确实是必需的,而不是简单的东西。显然,我们应该邀请面向业务的人员参加会议,作为我们进行技术讨论的面向客户的陪衬。

考虑交付

最初,我们只是根据我们认为是最重要或最明智的事情来优先考虑尽早实施。 但是很快,我想到了我们需要从客户交付的角度考虑如何将功能集耦合在一起。

这些变化将如何打包?新功能将如何部分或完全替代现有功能?升级路径是否清晰?它简单易懂吗?

形成技术待办清单时,请考虑捆绑,交付甚至记录您的工作。考虑这些方面将极大地帮助您订购列表,但也将工作捆绑到清晰且有价值的主题或块中。

考虑可测试性

另一个有用的观点是简单考虑如何测试可交付成果。测试覆盖范围是要考虑的领域。在开发积压订单的过程中,您将如何进行端到端功能测试?对于交付的每个阶段,测试要进行多长时间?这是最节省时间/成本的方法吗?

重点在于测试效率,如何防止过度冗余的测试以及构建与构建策略一致的测试策略,对于在积压工作流中表示至关重要。

让事情“煮”一会儿

我们经常要立即做出决定。我们进行了热烈的讨论,并进行了激烈的辩论。通常,一些声音要比其他声音大,然后在积压中做出“最终”决定。热情高涨,因此会立即采取行动。

我宁愿搁置一会儿。允许人们仔细研究细节,并考虑技术和非技术方面的接订单团队成员,以审查积压订单并完善其所有方面。

请记住,每个待办事项都需要与之相关的完成或接受的概念。这有助于阐明重点。这次也可以使人们从该角度改进积压的订单。

最后,如何使用代码?

最后的考虑是不要详细开发技术待办事项列表。取而代之的是,根据史诗般的故事来发展它,并围绕一个可交付成果建立一些清晰度。然后,不用敲定积压的工作,而敲定一些实例化积压工作的那些重要方面的工作代码。

这样您将获得信心和知识。您还将获得执行成本的见解,可以在确定后续工作的规模和评估时加以利用。

技术积压的攻击通常不同于功能积压或功能丰富的积压。我认为这是许多人犯的一个大错误。希望这篇文章有助于拓宽您的方法。

别忘了在下面留下您的评论

罗伯特·加伦

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

©BA Times.com 2020

麦格雷戈徽标白色网站