在SCRUM中安全问题
2015年4月9日上午最后发表04:34伊恩·米切尔
3回复
09:50是4月8日,2015年
你好,
我想知道如何安全问题应该是在SCRUM中处理。
是安全问题的管理非正式(即,yopougon口服每日例会)或正式例如安全专用产品待办事项列表中的项目?
谢谢你的帮助在这个马特。
03:14点4月8日,2015年
你可能需要一个更具体的和“安全scrum”将帮助你得到一些不错的答案。
我假设你意义的加密数据,我认为这将是一个任务的用户故事,这也将是验收标准的一部分。它是最有可能应该被添加到团队“完成”的定义和完成完整的团队。你不想要的概念“建筑安全在最后2冲刺”——因为你所做的一切直到这一点并不是潜在的可交付,你没有你需要的安全。
2015年4月9日上午03:46
蒂姆斯说过,安全需求应(所有其他非功能性需求)同意在“完成”的定义。这并不意味着美国国防部1000 +页的参考指南。
它可以很简单/非正式:
——我们坚持我们公司3 & 6章中定义的安全策略,
——我们的产品能够承受一般的线程,但没有规定来处理一个特定的集中攻击。
关键是它是透明的开发团队,产品所有者和可能的涉众是什么。安全关键应用程序必须能够将内部或外部引用。
2015年4月9日上午04:34
>我想知道安全问题
>应该在SCRUM中处理。
考虑的关键是是否可以实现和验证的需求开发团队。如果他们可以,他们可以添加PBI的(如所谓的“施虐者故事”)假设回归测试可以自动化,因此可伸缩。这也是合理添加约束和观察到“完成”的定义。这些可能维护安全的品质,每个增量将遵循。
安全需求不能实现和验证了一个开发团队是在产品待办事项列表和“完成”的定义。例子可能包括关于某些实时系统的渗透,恢复,故障转移和释放后担心涉及安全支持。这些通常与组织环境的质量将增加部署,而不是交付增量本身的品质。