假设：使用规模化敏捷框架（SAFe）在整个组织中扩展敏捷开发的公司； 10个开发团队组成一个大团队（根据SAFe的术语，敏捷发布培训）来交付一种通用产品； 需要两天的季度计划（PI计划）来确定IT团队接下来三个月的工作计划*； 三个开发办公室，最远的办公室之间的距离超过6000公里，相应的工作时间差为5小时； 以前的计划经验，这暗示着要使用模拟板/白板/荧光笔/粘滞便笺，以及所有关键员工在同一房间中各自的身体状态。
*这种重量级的结构“ IT团队未来3个月的工作计划”可能会大大增加文本的大小，因此在下文中，我将用“承诺”代替它。 因此，制定和通过工作计划将是“承诺”。
我们为什么需要这个？
1）用模拟工作方法疲劳。 当太空飞船在太空中耕作，而埃隆·马斯克（Elon Musk）正在钻探隧道时，我们这些IT人士一直在用荧光笔在粘滞便笺上粘贴，这些粘滞便笺贴在木板上-确实存在某种不和谐之处，不存在？ 这就是我们不久前的承诺：
是的，这是一张大约2 x 5米的纸，在计划之后，每个便签都将变成JIRA任务...
2）我们的游牧同事感到疲劳。 尽管我们的总部位于一个温暖宜人的国家，但去年令我惊讶的是，他们发现他们对来回的旅行感到很不满意。 我的论点“哦，好吧，你可以在海边的阳光下放松一下”。 事实证明，并不是每个人都准备好经常出差，而这经常受到家人的欢迎，考虑到办公室之间的距离和会议的频率，有些同事无法忍受所有时间。
3）在计划过程中吸引更多IT同事。 从上一段可以清楚地看出，我们很难让三个办公室的所有IT人员来进行计划，因此只选择了选择的人，这种人将其他人排除在流程之外。 总体而言，这对团队合作精神没有好处。
4）成本优化。 是的，这是一个敏感的时刻-有很多关键人物，每年让他们来回飞四次并不便宜。
零部分：使用投资组合积压
一切都比实际计划早得多开始。 为了在计划过程中高效地履行承诺，您必须要有所承诺。 为了确保这一点，我必须尽早“让”企业主承担可能采取的措施的工作（或用SAFe术语，Epics，但此后我将使用通常的术语）。 理想情况下，此过程应与季度计划的迭代性质完全脱离，并采用自己的看板方式。 我们以SAFe投资组合看板为基础：
我们有一个单独的JIRA项目，涉及三个问题类型：史诗，业务计划和体系结构计划； 以及相应的看板委员会。 计划的企业主的算法很简单：他向该项目添加了一个问题，默认情况下将其提交到待办事项列表，这是我们看板流程的第一个状态-
渠道：
在此存储尚未准备好进行审核的计划。 企业所有者将研究计划的内容，直到他为下一步做好准备为止。 在此阶段所需的最低要求是填写问题陈述，期望的结果和成功的度量的字段，以及稍微更详细但简单明了的演示。 在此阶段，重要的是要撇开技术解决方案，而专注于业务参数。 收集所有数据后，企业主将任务移至下一个状态-
审阅。我们每周都会对业务计划和建筑计划进行审查。 理想情况下，这是一个五分钟的演讲，随后进行问答。 审查的结果是，决定该计划接下来会发生什么。 它可以：
- 返回到渠道进行修订，
- 被废除，没有机会继续生活（在这种情况下，我使用看板中隐藏的特殊过时身份），
- 被批准并移至下一阶段- 分析。
在这个阶段，我们-Yippee !!! -最终可以吸引IT人员：分析师，架构师，主管，任何人。 “我们”是指我自己是发布培训工程师。 但是理想情况下，也应该是企业主，他们已经获得了一些经验和自主权，可以聘请合适的团队并独立启动分析。 同样，我在这里写的是理想情况。 实际上，我们同事的自我组织水平是浮动的，在某些情况下，他们要求特别任命的协调员的帮助，但我尝试从这种做法中退缩。
此阶段的目的是进行初步分析，或者我们称之为预发现。 结果，我们应该获得一个最低限度，使我们能够做出承诺：提议的解决方案，风险和依赖性，非功能性和基础架构要求，用户地图，体系结构方案。 此外，我们要求团队在功能级别对故事点进行初步评估-这将使我们能够在季度末确定优先级。
在此阶段，将为每个计划创建一个个人看板委员会，在其中可以看到功能和故事，并具有指向特定迭代的初步链接，该链接由单独的JIRA工作流程提供。 因此，通过更改状态，我们可以将问题分配给某些迭代。 看板中的泳道由开发团队配置。 由于我们的JIRA生态系统非常复杂，因此在预发现和发现过程中，我们在单独的项目中创建任务，以免浪费团队的积压工作：
同样在发现前阶段，我们邀请建筑师或他们最近信任的人员-“ EA大使”参与。 他们的任务是将架构部门的愿景传达给所有参与者，帮助找到最佳解决方案，最后由公司企业架构负责人批准该解决方案。
当所有相关人员都认为该计划已经过足够的分析并可以进行下一步时，它便移至下一个状态-
投资组合积压。在此阶段，进行WSJF优先级排序（
加权最短作业优先 ）很重要。 为此，我们在计划开始前三周举行了一次大型会议，不幸的是，到目前为止，该会议一直持续了多个小时。 在本次会议期间，管理委员会成员借助与斐波那契结盟的计划扑克，评估了业务价值，时间紧迫性，降低风险和机会实现能力：
为了能够跟踪计划的历史，我为每个计划在JIRA中添加了带有季度数据的标签：2018Q4、2019Q1等。
展望未来，让我描述所有可能的状态。 在PI Planning做出最终承诺后，成功投入工作的计划将移至“
实施”状态，而那些“不合格”的计划将处于“
停滞”状态，并可能在下个季度考虑。 已交付的计划已移至“已
完成”状态。
结果，我们在看板板上有以下图片：
当然，我们还没有走到中间，但是目前，我已经可以注意到，由于Portfolio Backlog的实现
- 企业主已开始详细研究其倡议，并为审查做好充分准备。
- 评论以一种很好的方式变得更加细致。
- 团队有更多时间进行预发现。
- 我不会输掉旧的倡议-我总是可以回到停放的，未交付或忘记的倡议上，并进一步开展工作。
此阶段使用的工具：
- Atlassian Jira软件服务器
- Jira的插件颜色-用于突出业务和建筑计划
- “结构-大规模项目管理”插件-可视化倡议和所属项目的结构以及WSJF的优先级
- Atlassian Confluence-内部文档来源
- Lucidchart及其Jira和Confluence插件-用于绘制图
第一部分：PI计划的准备
最繁忙的时间来到PI Planning的一个月。 需要考虑太多事情，为了不遗漏任何东西，我必须创建一个多页的“物流” Google表单。 让我描述一下此表单中最重要的选项卡及其周围的活动。
意见反馈 在每次PI规划之后的几天，我们都会进行一次回顾，以帮助我们不要忘记得出的结论以及我们如何调整路线。 这是持续改进的重要组成部分。
技术准备。 随着向远程计划的过渡，出现了特定的请求，例如Internet连接的质量（JIRA和Confluence的优先级和路由优化）以及视频和音频显示（我们使用Logitec Group套件，Jabbra麦克风和个人耳机的各种组合） ，网络摄像头，用于视频会议的Zoom软件）。
主持人。 它是负责每个工作组中促进工作的雇员列表，指示他们的位置以及到工作组永久性Zoom通道的链接。
听众 所有被邀请者的完整列表。
检查清单 重要任务的完整列表，包括截止日期和负责人。 为了在下面提供一些见解，您可以找到几个与每个PI计划相关的最典型和最重要任务的示例：辅导员培训（已经编写了培训手册，其中包括所有必要步骤，例如组织工作团队，安排会议时间和将倡议分解为功能列表）； 更新每个办公室的工作组位置图； 控制所有开发团队的Velocity更新； 点餐； 创建前几个季度的报告； 计划和时间表清单的打印输出。
第二部分 PI计划和承诺过程
经过所有准备工作之后，这一刻终于到来-PI Planning的开始。 在两天内，我们必须发现所有倡议，确保信息足够并提交。 经过几次鼓舞人心的谈话之后，工作组前往了他们的所在地并开始了业务。 目前，组的数量以4x4x2的形式分布在三个办公室中，并且远程用户通过专用的缩放通道连接到所需的组。
完成上述每项举措的发现后，协调人将确保获得所有必要的数据，例如验收标准，技术解决方案，风险，依存关系，新基础架构的必要性，并以“ IT”标记该举措。会话完成”复选框，可轻松跟踪进度。 之后，工作组可以继续进行下一个计划。
在进行了十几次PI Plannings之后，从一开始就伴随着我们不断受到压力和时间压力的感觉已经大大减弱，现在，这一切都变得像往常一样。 在计划的第一天和第二天的下午，是时候根据优先级做出不懈的承诺了。 为了履行承诺，我有几个单独的结构。 第一个是一个结构，其中包含为承诺而安排的功能和故事的列表：
不幸的是，屏幕截图上的此结构仅包含不符合当前季度承诺的任务，因此该示例没有代表性。 无论如何，我都可以在搜索字段中按编号优先级选择需要的计划，将其放置在每个功能和故事的单独字段中，将问题的状态从“计划”更改为“已提交”，然后将其进行所需的迭代，从而为他们承诺：
结果，该问题将从此结构中消失，并以新的形式出现，这反映出越来越多的承诺：
如您在屏幕快照中所见，在这种结构中，故事落入了它们所属的开发团队的文件夹中，并按迭代进行分组。 在这里，我可以在文件夹名称中看到团队的总速度，此外，在“承诺”列中，可以使用自定义公式自动确定每个团队的超额投入并突出显示。
当然，如果将最优先和最高优先级的计划轻松地包含在承诺中，随着越来越多的团队将其积压的工作积压到最后，那么在经过某些论点和讨论之后，某些计划可能会存在各自的问题。结果推迟（停放）。
在这个相当简单的过程结束时，团队发誓要履行对公司旗帜的承诺（好吧，不是真的），并赶紧回家（好吧，又不是，实际上，他们大多逃到某个酒吧庆祝）。
此阶段使用的工具：
- Atlassian Jira软件服务器
- “结构-大规模项目管理”插件-监视发现过程以及在执行承诺期间。
第三部分 将问题克隆到公司的可用JIRA生态系统中
当每个人都在喝酒时，RTE致力于制定承诺，使其可以分发到开发团队的积压清单中，并在整个季度进行监控。 为此，我使用了“用于Jira的批量克隆专家”插件-它向“批量更改”菜单添加了一个进行集体克隆的项目，并具有诸如链接克隆，更新新创建的克隆之间的链接，更新Epic链接，添加摘要之类的必要功能。前缀和自动标记：
我将状态作为前缀添加，因为状态在计划阶段反映了计划的完成迭代。 结果，当我们计划完成功能或故事时，可以立即在摘要中看到。
首先，由于我们将史诗保存在其中，因此我将所有问题完全克隆到一个单独的Global Backlog项目中，并且在新克隆的任务中我需要具有实际的史诗故事连接。 作为第二步，我已经分别为每个开发团队提出了JQL请求，并将这些故事移至团队的工作项目中。
结果，我创建了一个反映当前承诺并包含最终故事的结构，然后将其用于监视：
通常，此方法的优点如下：
- 对于IT人员而言，键入新功能和故事比在粘滞便笺上用荧光笔写下新功能和故事要容易得多。
- 使用自定义公式会自动计算出很多内容，例如，剩余容量和根据报道估计而进行的WSJF更新。
- 多亏了克隆，原始的“承诺”被保留下来以备历史之用，我们可以随时返回。
- 在计划准备阶段可以节省我们的时间和精力-纸张处理需要精力。
- 当然，非常棒的是，我们不再需要通过输入便笺向JIRA添加问题。
此阶段使用的工具：
- Atlassian Jira软件服务器
- “用于Jira的批量克隆专家”插件-用于将功能和故事克隆到正在运行的JIRA项目中。
- “结构-大规模项目管理”插件-用于创建最终的承诺结构。
结语
亲爱的朋友们，我当然知道上面的概述是很肤浅的，并且可以用更详细的方式揭示很多事情-监视业务和体系结构计划和操作任务之间的容量分配，计算结构中的自定义公式，管理风险还有更多。 但是我仍然不知道这个话题对听众是否有趣，如果是的话，还不算什么。 如果我有任何兴趣，我将很高兴分享我对相关主题的见解。
还有一件事-很难相信这是有可能的，但是我仍然很想避免在评论中避免与敏捷，框架，有效和“有效”的经理相关的批评。 请记住，我描述了整个过程的技术部分，希望引起熟悉该主题的人们的兴趣，并且我希望进行相关的讨论。
在评论中见！