让我们确认安全的安全......然后继续前进
这一周，一大笔的安全相关东西在我的桌子上做了。超过通常的金额。其中一些是积极的，其中一些是消极的，其中一些是旧的，其中一些是一些新的 - 但这一切都提出了相同的基本问题。安全成为软件开发的所有东西的救主吗？安全真的很敏捷，或者只是Rup的第二个来了吗？将安全生存或被降级到过去30年来过去的失败方法清单。
这是我的接受。没关系。
敏捷的简史
敏捷，它在14年前定义的时，基本上是一个轻量级的建筑软件框架。敏捷是关于小组，扑发，现场客户，轻量级文档和频繁的反馈机会的概念。这些团队需要足以解决它们形成的问题。他们需要有一个清晰的积压，并且他们需要能够在某些预定间隔上产生工作测试的增量。
现在，如果你走得更深，敏捷团队需要在代码库中工作，该代码库是批量的，包裹在测试中，并安全地进行更改。但是，该代码基础需要由一支团队提供自主权来决定如何最好解决它们形成的问题。该团队需要与他们形成支持的组织的业务目标紧密对齐，他们必须与组织其他人有一定程度的独立性。亚博vip9通道
让我很清楚。大多数组织不能形成这样的团队。很多组织有：
- 紧密耦合，非自治团队
- 与业务的不一致亚博vip9通道
- 缺乏良好的测试
- 代码基础，不安全地进行更改
- 矩阵型员工
我要继续吗？
所以，什么是安全的
事情是这样的，你要么为做好敏捷创造条件——就像14年前定义的那样——要么做别的事情。这个东西叫做SAFe。
它封装了一个更大，更多的企业聚焦，价值流。最大组织中真正存在的值流，不能忽略。
我再强调一遍，不是你为做好敏捷创造条件，或者你做别的东西，安全就是别的东西。
判决是什么？
我们可以说,安全是一种逃避,它并不是敏捷,或RUP的第二次降临,但不要低估了复杂性、风险或成本的完全重构一个企业能做敏捷的组织,在任何类型的规模。然而，一些组织根本不能或不愿在这方面投资。在一天结束的时候，小批量比大批量好。迭代式和增量式比瀑布式更好，即使它不是敏捷。
就我个人而言，我不认为SAFe是坏的……或者SAFe会破坏我们在更大的计划中试图用敏捷所做的事情……然而，我确实相信SAFe在某些时候会对一些公司更好。SAFe不是我用来解决企业问题的方法。我希望与那些确实想要从根本上分离自己的公司合作，并尝试像最初设想的那样进行敏捷开发。
但是，我的务实足以知道这可以是一条漫长的道路。
那么，我们该怎么办呢?
评论（23）
史蒂夫Colasinski
我们公司正在努力采用安全。我不是那个决定的一部分，但被要求乘坐。令人惊讶的是，该团队仍在尝试根据兼职资源的安全来定义内部过程。亚傅体育app这努力进展很慢。此时的结果是不可预测的。似乎公司正在寻找深度结构来遵循。
邓兰省
伟大的迈克。我认为你的实用主义是正确的。我认为安全是帮助许多组织虽然我不会为自己选择它:)。
保罗嘘声
伟大的帖子，我补充说，很少有人似乎探讨了这个问题，更重要的是，安全的框架等安全是基于......
在最后一个ACCUS，我促进了一个有趣的结果的会话。我们没有尝试抨击安全，而是了解更多的内在依赖，以便确定它是否适用。您可以在此处查看结果：此处会话：http://paulmboos.com/2014/10/05/acc-us-session-how-to-practice-agile-scaling-wo-a-condom-un-safe-aagility/
切丽
你的帖子让我自豪。让我们只是为我们是谁以及我们现在所在的人做正确的事情，并保持眼睛持续改进。
德里克邻居
安全是与平庸的道路。大多数大型组织都可以与平庸一样好，因为他们有足够的现金来思考它并不重要。直到它。最好的原因是最糟糕的借口。
如果你加入了一个想要实现SAFe的组织，而你想要的不是平庸的像地狱一样运行。
嘿德里克，谢谢你的评论。如果公司愿意使敏捷所需的更改，但是在大型复杂系统架构中，你的架构没有正确的对齐，那么你还有什么关系，没有良好的测试，没有良好的测试等？在他们解决问题的情况下，可以安全成为可行的中间状态？我不是一个安全的辩护神论，就像我说的那样，这不是我所希望的最终状态，并倾向于同意你的评论......。也就是说，可以安全地在过渡组织中有任何地方？
维克多Grgic
嗨迈克，有更好的“中间状态”。我非常喜欢你的文章，除了结论是一个错误的二分法。有许多传统公司的例子逐渐变得真正敏捷，只有Scrum。例如。大规模scrum（少 -http://less.works.）在这种努力中进一步帮助许多典型问题。因此，有更好的方法来处理复杂和大型企业，虽然它们都没有承诺快速解决方案，因为没有一个。
我唯一会在博客中改变的是我说“安全是中间状态”的地方。我希望我会说“一个”中的中间状态或类似的东西。我仍然认为帖子的点是有效的。如果您只使用Scrum，那么敏捷良好的条件也存在。同样少了。如果您正在转向那些终端状态，那么您拥有一个创造成功条件的组织，他们愿意进行投资。如果您将安全视为中级状态，根据定义，您就在一个没有正确的条件的公司，并不愿意投资创建它们。
维克多Grgic
同意。
德里克邻居
我认为安全可能是过渡步骤。但是，我尚未满足已成功使用它的组织。他们中的大多数都认为它不是一个旅程。
Kurt Jaeger.
我对那个帖子很满意，因为它建造了务实的桥梁。安全适合我们与我们交谈的客户，如Deutsche Bahn，Compugroup Medical，Amadeus，所以即使是大型企业也能够赢得敏捷和精益，因为John P. Kotter预测他的书籍和视频XLR8也见https://www.youtube.com/watch?v=pc7evxnf2ai.
Martin van Langen
写得好。我在过去的两个任务中也经历过这一点。他们觉得这是敏捷性的快捷方式，而不会痛苦。
詹姆士
我认为SAFe指出了一个在敏捷中被低估的重要话题:需求工程。
极限编程将我们的注意力转移到诸如测试驱动开发、持续集成、结对编程等质量实践上。
Scrum将重点放在项目管理方面，与强化规划会议，常规审查周期，报告，刻录图表等实践。
用户需求和需求管理呢？安全教授我们的分析和定义要求的价值吗？它将如何与其他需求工程实践（如行为驱动的开发或逐个规范）集成？
Fitnesse的工具如何（http://fitnesse.org.）和协调（http://concordion.org.)支持敏捷团队协作指定?
里克维斯
我喜欢这篇文章。非常务实的安全挑战。我相信，如果我们有敏捷的团队，（共同定位，使用良好技术实践的自治团队）那么我们可能不需要安全。良好的计划管理可能就足够了。试图在没有敏捷团队的情况下实施框架可能很少有益。安全使我们拥有敏捷团队的假设......这是整个框架建立的基础......或者只是也许，我们可以使用框架来销售创建敏捷团队的需求:-)
路加北京
虽然我同意安全不提供魔法子弹的前提，但当人们谈论做“敏捷，专注于共同的自治团队行使良好的工程实践时，我发现它有趣。如果这个世界观让您在同一价值流上的40个团队中的协调，那么这很棒。敏捷不是一组方法 - 这是一组原则。在我的经验中，许多原则开始以规模分解。无论是安全还是别的东西，它都太过云，只是说否则。每一个缩放工作都需要额外的协调 - 安全只是一个实现。当Ken在他的博客中摧毁了安全时，我注意到他在他自己的缩放范例上出现了很久。我相信它将100％粘在宣言的所有元素中。
丹尼斯·埃伦堡
我是一个新认证的SA，所以也许我需要更多的经验，所以通过非敏捷镜头看到安全，但我认为安全是高度依赖于良好的敏捷练习，特别是在团队层面。我与大型银行和电信客户合作，他们跨越传统瀑布的频谱，以思考他们在敏捷实践中非常复杂的敏捷（而不是）。在团队层面无法做到敏捷的组织可能会在尝试使用安全方面奋斗。在团队层面敏捷的团队纪律，倾向于以安全的方式擅长。这是我的经验。
Michael Durrant.
在下一个冲刺中测试延迟反馈对我来说感觉不一致
Pankaj C潘迪特
绝对地…。
马丁燃烧
迈克，这是一次非常有价值的尝试，可以从一个不同的角度看世界，了解当你处在一个非常不同的起点时世界是如何运转的。
你是对的：安全最有效的是，整个产品组织不能简单地在一个可以在一个绿地中定义所有实践的单个房间里的10人。这是许多软件密集型产品的现实。
但我认为有一系列各种组织，您的标准可能是可能的，而不是今天。起点就是在其他地方，但有工作，也许他们可以到达那里。或者至少：一个比今天更近的地狱。
用作目的地是安全的吗？是的，在某些组织中。如果他们有一半的有效教练，当他们到达那里时，他们会看到它不超过一个登台帖子，即使它需要5年才能到达那里。
安全是高效的（例如）在转动高度耦合的送货系统时，具有很少的业务对齐的强烈业务对齐，松散耦合的“团队团队”系统。亚博vip9通道在教学管理者和高管放弃控制。在向前解雇他们的利益攸关方宣传工程卓越实践。
您完全有权将其定义为“不敏捷”，但我不同意。我非常喜欢Dan North的敏捷念头作为一个以中心的社区，而不是一个有界的敏捷。一个你不断地“走向”的地方。为了我的思考，宣言中最重要的话语是“通过做和帮助他人揭示更好的方式” - 这必须是一个上下文问题。
安全敏捷，还是别的东西？嗯，这取决于你的开始。就像沙发到5K节目：耐力训练是谁？对于像我这样的脂肪，是的。对于现有的马拉松赛跑者，而不是真的。
所以问题是：鉴于你非常有效地被确定为起始条件的约束，你会先做什么来减少它们并进展到理想？
斯文Thiergen
只是我的第一个看看安全，现在是2017年。这篇文章是在2105年写的，安全可能已经（有点）不同，那么如果我错过了一些点，那就道歉......
我认为这篇文章是对的，大量公司无法改变足以允许真正的灵活性。这就是为什么敏捷团队禁用了一些较小或更大的程度，你来到了问自己“在这里做敏捷真正有意义，或者我们应该寻找别的东西，这真的很有意义吗？
“别的东西”比敏捷更少的潜力，而是改善更好的结果，从而最终得到更好的结果。
到目前为止这么好，但安全真的不仅仅是另一个“别的”。绝对没有在这里捍卫安全，但指出一个重要的区别......安全是基于真正的敏捷性！
在SAFe中，你可以从传统敏捷中了解到一切:Scrum大师、产品负责人、Scrum团队，甚至Scrum本身(或看板)。计划，演示，复古等。
实际上，SAFe通过引入团队的思想增加了(至少)一个额外的组织层。简单地说，就是一群由50-125名开发人员组成的scrum团队使用一个共同的产品待办事项列表来开发同一个产品。
除此之外，还需要在多个团队层面上发挥作用，比如用户体验设计师、架构师，或者Scrum管理员，作为团队Scrum管理员的“首席Scrum管理员”。
安全是好的还是坏的是另一个讨论。我认为他们的大部分想法都是合理的;我曾经为一家公司工作过这个精确的场景，我们只应用了许多安全的想法而不会像这样调用它。
这就是为什么我不同意声明“如果你不能真正的敏捷，你需要做别的事情;安全只是另一个别的“。
安全，例如如果您没有在同一产品上工作至少20-30人，似乎并不是任何意义。这是许多公司挣扎的许多公司的情况，仍然需要“别的东西”。
史蒂夫vanarsdale.
谢谢，再次，迈克。两年后，在2017年，这仍然是关于安全和所有其他敏捷方法的相关性和阐明的意见。对组织规模的敏捷实践越来越敏捷是一个值得一定的过程的努力。Ron Jefferies的报价是一个焦点。
imo：这是敏捷艺术的脚手架，三维框架，允许/保留/使得在致力于系统，可预测和可靠地供应人员，材料和可靠性供应的组织中的敏捷性的“气泡”。资本给我们爱好者......在我们的敏捷发展泡沫中安全地陷入了坚定。对于我的钱和职业生涯来说，一个缩放的敏捷框架比我能够到达那里的速度，这是一个缩放的敏捷框架。
尤金
如果SAFe不是敏捷，它就不应该被当作敏捷来推销。像RUP一样，SAFe应该被称为迭代方法。如果它是这样销售的，那么我没有问题。迈克，我不知道你是否在使用SAFe的环境中工作过，但如果你没有，我建议你试试。当我第一次学习敏捷时，虽然我从一开始就喜欢它，但我对当时的教练如何撤掉其他方法感到厌恶。直到我第一次遇到SAFe。我曾在3个实施了SAFe的组织工作过，我可以向你保证，这3个组织的人现在都讨厌敏捷——因为SAFe。我知道为什么会出现SAFe，但如果你想要敏捷，那就去敏捷吧。不要违反所有的原则，并认为这是可以的。外管局受到管理层的喜爱，但他们并不是负责这项工作的人，所以当他们意识到问题的时候，他们组织内的问题已经接踵而至。 SAFe should be marketed as another iterative methodology. It doesn’t have to be “Agile”. And sure, maybe it will work in some organizations. I haven’t seen it yet. 2 of those organizations decided to never do Agile again. The other one, as I have learned, is very close to doing the same. SAFe may be good for marketing, and some Agile folks may think that it helps Agile get visibility. I think in the long run, it will harm Agile. Agile, when practiced right, makes everyone love their work. Remember the teaching principal called, Shuhari. You must first “Protect” the basics, then you can “Detract”, and then “Transcend”. SAFe does not protect the principles and values of Agile, so you can never move to “Detract” and “Transcend” as an Agile Master.
s . L。
尤涅，
喜欢你的评论。您发现哪些敏捷值和原则没有使用安全的保护？