什么是SAFe？
许多人都知道什么是敏捷。 涉及IT使用术语的人数甚至更多。 进一步了解敏捷。
并非每个人都自信地使用“敏捷”这个词来进行交流，批评，为此； 为了更好地展示他们的团队或公司，例如，他们了解SCRUM和Agile有什么区别； 并且经常在这两个不同的概念之间放一个等号。 但不久前，2015年，SAFe也出现了。 它是什么，为什么需要它？
SCRUM的重要优点和缺点之一，我认为命令的规定大小是7 + -2（或来自Scrum Guide的 3-9最近数据），包括产品负责人。
当然，有9位高层且有上进心的专业人员能够胜任，但是有时候有必要最终用大量的手，头，眼睛和大脑来构建东西。 给团队充气是不好的，因此需要增加他们的人数，并且在团队之间出现沟通问题，工作同步和SCRUM本身无法为这些任务提供任何解决方案。 有尝试在SCRUM命令管理级别使用SCRUM（正如敏捷宣言的作者之一Jeff Sutherland所建议的那样），有大规模Scrum，有纪律的敏捷交付，还有很多，但还有SAFe-规模化敏捷框架。
SAFe是一个公司管理框架，需要为5个或更多SCRUM团队协调某个项目或相关项目的工作。 即 这是SCRUM的上层结构，可让您管理100人或更多人的团队
有好处吗
首先，当然，出售该方法并从事培训的人员都需要该方法。 戴夫·托马斯（敏捷宣言的作者之一） 在GOTO 2015上的演讲《敏捷就是死了》中对此主题的评价很好
第二，计划管理部门。 那些以前参与项目管理的人员获得了PMP认证，绘制了甘特图，并实施了硬软管理的概念（领导者的软性和执行者的软性）。 事实是，在典型的SCRUM中，它们没有功能，而在SAFe中则是。 同样适用于所有类型的建筑师。 在SCRUM中，SAFe中没有针对他们的功能-这是一条职业道路。
此外，对于那些在大型项目上工作的经理占用大量工时且不能（有时出于客观原因）使这些项目独立的企业主来说，这可能是有益的。
许多开发人员的学历低于平均水平 通常，为了做某事，他们需要比那些经验最丰富，最有动力的专业人员更多。
整个行业。 因为 开发人员的数量每5年翻一番（请参见bob叔叔的编程前景 ），这导致这样一个事实，即在任何给定时间，至少有一半的开发人员拥有不到5年的工作经验。 如果趋势没有改变，但显然没有改变，则需要规定和规范其工作功能，参与者之间的相互作用机制和整个过程的过程。
精华液
SAFe是来自各种敏捷技术的夹心蛋糕。 最底层是几乎传统的SCRUM，通常需要两到三周的冲刺，包括产品负责人在内的3-9人的团队。 所有典型的仪式，包括日常计划-站立和在回顾会议时进行汇报。 虽然有一个关键的区别。 该命令不再是功能完全独立的模块。 冲刺不再是具有完整生命周期的独立时间段。 冲刺被组合成通常由5个冲刺组成的程序增量。 即 如果在传统的SCRUM中我们没有建立客户喜欢的东西，那么我们在下一个冲刺中进行航向校正，然后在SAFe中，我们继续走到最前沿，直到在最坏的情况下，在接下来的4个冲刺中程序增量结束（当然，我会夸大）。
在下一级别，我们有火车-所谓的敏捷发布火车。 新增了用于管理5个sprint段的功能：系统架构师（拥有体系结构的人-即不再是团队），产品经理（控制产品的人，而不是产品所有者，后者负责PM的建议）和RTE -来自遥远的瀑布世界的同一个PMP。 在这里，应用了看板的一些开发成果，特别是董事会，一种分配优先级的方法，以及通常的方法，即测量团队的历史绩效（速度）并预测在时间间隔结束时将要构建的内容的原理，这与采用估算方法并为已经确定的功能分配期限的方法相反（范围）。 一项创新是宣布最后的5人冲刺被宣布为组织者，在此期间举行了大型会议（所有团队在一起-人数为100人或更多），对技术债务进行了分析，制定了建筑开发计划，并使所有团队的工作同步进行。
在培训级别之上，我们在部门，主管和客户之间进行协调。 Lean Agile有更多的借用，但看板保留了相同的工具。 这是对变革的经济可行性的分析。 理想情况下，任何更改都要经过初步分析，在该分析中提出有关即将发生的更改的可测假设（例如，如果我们从数据中心到云建立在线商店，然后在季节性销售高峰时迅速增加容量，则可以将交易数量增加10％），然后可以要么证实这一假设，要么不行 对于少于十亿美元的公司-这可能是最后一层。 在此创建12-36个月的工作计划（关于质量，数量等的5年计划）
大型系统之上是投资组合管理。 资金分配到各个业务领域。 使用精益投资组合管理，并根据公司的发展战略，选择可以从中获得回报的领域。 在此做出有关购买或与其他公司合并的决定。 创建新业务线，关闭旧业务线。 预算是定期调整和重新分配的（与季度或年度计划相对）。 对于投资组合的每个组成部分，都会建立一套或多或少的标准化指标，然后根据这些指标进行评估。 与之前的3个级别一样，通常有每两周进行同步的特殊仪式-交换状态和关键指标。
以整体策略为主导。 框架没有描述它的定义方式。
优点
- 大量非常好的工具（WSJF，看板，Gemba等）
- SDLC的正式和规定步骤从编写代码（由TDD规定）开始到执行静态扫描和CI / CD和功能切换。 每种做法是否良好是另一个问题，但是至少有一个计划，每个人都遵循。
- 可以理解，解释和实施该过程。
- 在此过程的框架中，每个人都有一个相当严格定义的职能。
- 对于在公司工作的人来说，增加了公司的透明度。
缺点
- 足够长的时间来应对现实与期望的不匹配
- 大量的金钱和金钱花在沟通和会议上
- 通常在框架内推荐的解决方案已过时
要介绍还是不介绍？ 我相信，如果有选择，那就没有选择，最好减少部门和项目之间的依赖。 而且如果没有选择，而您需要管理一个巨大的项目，那么很有可能。