假设:使用规模化敏捷框架(SAFe)在整个组织中扩展敏捷开发的公司; 10个开发团队,组成一个大团队(根据SAFe的术语,敏捷发布培训),提供一种通用产品; 需要两天的季度计划(PI计划)来确定IT团队接下来三个月的工作计划*; 三个开发办公室,最远的办公室之间的距离超过6000公里,相应的工作时间相差5个小时; 以前的规划经验,涉及关键同事在同一房间的实际存在以及使用模拟板/白板/标记/粘滞便笺。
*重量级的结构“未来3个月的IT团队工作计划”可能会严重增加文本的数量,因此将来我打算写简单的“评论”来代替。 因此,起草并通过一项工作计划-“提交”。
为什么需要这个?
1)模拟工作方式的疲劳。 当宇宙飞船在空旷的地方耕作,而Elon Musk在挖掘隧道时,我们IT专家坚持不懈地在粘纸上书写标记并将它们刻在木板上-这是一种不和谐。 这是我们不久前的评论:

是的,这是一张约2x5米的纸,经过规划,每张纸都应该变成吉拉的一项任务...
2)游牧民族的疲劳。 尽管我们的总部位于一个温暖而温暖的国家,但令我惊讶的是,去年我发现他们对这样的游牧生活一点都不满意,而我的论点是“来吧,在海里游泳,您会在阳光下温暖自己”,这是我的轻描淡写,我对此并不十分热情-并不是每个人都准备好经常出差,他们的家庭并不总是对此表示欢迎,有人对频繁的航班反应不佳。
3)将更多的IT同事与计划流程联系起来。 从上一段可以清楚地看出,我们无力将整个办公室派人进行规划,因此,我们只派出了选择的人,从而将其余人员从流程中排除了,这没有增加总体道德。
4)优化财务成本。 是的,这是一个敏感的时刻-有很多关键人物,每年来回携带四次是很繁重的。
零部分或投资组合积压
这一切都开始得很早-为了在计划过程中有效地处理评论,有必要提交一些东西。 为确保这一点,我必须尽早“让”企业所有者从事拟议举措的工作(或者用SAFe术语Epicam,但我会使用我熟悉的术语)。 理想情况下,此过程应完全脱离季度计划的周期性,并采用自己的看板方式。 作为基础,我们采用SAFe投资组合看板:

我们有一个单独的JIRA项目,其中包含三种任务:史诗,业务计划和体系结构计划; 以及相应的看板。 该计划的业务所有者的算法很简单:他将任务添加到该项目中,并且默认情况下它属于Backlog-这是我们看板的第一状态
-Funnel:
它存储尚未准备好进行审查的计划。 企业所有者正在研究计划的内容,直到他准备下一步为止。 在此阶段所需的最低要求是完整的“问题陈述”,“期望的结果”和“成功的度量”字段,以及稍微更详细但简单明了的演示。 在此阶段,重要的是要避免提及技术解决方案,而将重点放在业务参数上。 收集完所有数据后,所有者将任务移至下一个状态-
审阅。我们每周都会对业务计划和架构计划进行一次审查。 理想情况下,这是一个五分钟的演示,并随后回答问题。 审查的结果决定了该倡议的命运。 她可以:
- 回到积压进行修订
- 废除,没有机会继续生活(为此,我使用了单独的“ 过期”状态,隐藏在看板中)
- 获得批准并进入下一阶段- 分析。
在这个阶段,我们很高兴! -我们可以从IT部门吸引员工:分析师,架构师,主管,任何人。 “我们”是指我自己是发布培训工程师,但是在理想情况下,企业所有者已经获得了一定的经验和独立性,可以吸引合适的团队并自行启动分析过程。 我正在写一个理想的案例,因为我们同事的自我组织水平是浮动的,在某些情况下,他们以特别任命的协调人的形式寻求帮助,但是我尝试从这种做法中退缩一点。
此阶段的目的是进行初步分析,或者我们称之为预发现。 在出口处,我们应该获得允许我们进行承诺的最低限度:建议的解决方案,风险和依赖性,非功能性和基础设施要求,用户地图,体系结构方案。 此外,我们要求团队在功能层面对故事点进行初步评估-这将使我们能够在季度末确定优先级。
对于每个计划,都会创建一个个人看板板,在您创建看板时,您可以看到功能和故事,并具有对特定迭代的初始绑定,该绑定由某个单独的工作流以将来的迭代形式提供。 在董事会中,根据开发团队配置自定义团队。 由于JIRA生态系统非常复杂,因此在预发现和发现期间,我们在单独的项目中创建任务,以免使命令的积压工作变得混乱:

同样,在分析阶段,架构师参与了此过程,或者,按照最近的惯例,他们信任的人是“大使”(EA大使)。 他们的任务是向流程的参与者传达架构部门的远见,以帮助找到最佳的解决方案,并最终与公司的首席架构师(企业架构负责人)协调此决定。
当团队认为该计划已经很好地制定并准备下一步时,他们会将其移至下一个状态
-Portfolio Backlog。
在此阶段,重要的一步是执行WSJF优先级(
加权最短作业优先 )。 为此,在计划开始前3周,我们召开了一次大型会议,不幸的是,该会议耗时数小时,并且在本次会议期间,使用斐波那契扑克评分,管理委员会成员评估了业务价值,时间紧迫性(时间紧迫性),潜在的风险降低和机会实现:

为了能够跟踪计划的历史,我在夹具中为每个计划添加了一个标签,其中包含本季度的数据:2018Q4、2019Q1等。
展望未来,我将描述以下可能的状态。 承诺完成后,成功采取的举措将变为“
实施”状态,而“
不适应 ”状态将变为“
停滞”状态,将来有机会在下个季度进行考虑。 已交付的举措已
完成 。
结果,看板上大约有以下图片:

当然,我们还没有走到中间,但是目前我已经注意到,由于在Portfolio-Backlog级别使用了看板
- 企业主开始详细制定计划并认真准备审查
- 审查变得更加细致了
- 团队有更多的发现前时间
- 我不会输掉旧的计划-您随时可以返回停放,未交付或忘记的计划,并进一步进行处理
此阶段使用的工具:
- Atlassian Jira软件服务器
- Jira插件的颜色-用于突出业务和建筑计划
- 插件“结构-大规模项目管理”-用于可视化活动的结构及其相关功能及其WSJF优先级
- Atlassian合流-内部文档来源
- Lucidchart及其Jira和Confluence插件-用于制图
第一部分:计划准备
在计划一个月前的某个地方,这是准备工作的热门时间。 要考虑的事情太多了,为了不忘任何事情,您必须创建一个多页的“后勤” Google表格。 我将尝试描述此表中最重要的选项卡及其周围的活动。
反馈。 在每次计划后的几天,我们进行回顾,并调整路线,重要的是不要忘记我们得出的结论以及我们需要如何调整路线。 这是持续改进流程的重要组成部分。
技术培训。 随着向远程计划的过渡,出现了一些特定的请求,例如Internet连接的质量(JIRA和Confluence的优先级和路由优化)以及电视和音频显示(我们使用Logitec Group套件,Jabbra麦克风和个人耳机的各种组合,网络摄像头,视频会议缩放软件)。
主持人。 这是负责每个工作组中促进工作的雇员列表,指示他们的位置以及到工作组永久Zoom频道的链接。
听众 因此,所有受邀者的完整列表。
清单。 具有截止日期和负责人的重要任务的完整列表。 为了让您更加沉浸其中,我将给出几个针对每个计划重复执行的最典型和最重要任务的示例:协调员培训(已经为协调员准备了培训手册,其中包括组织工作团队,安排会议以探讨技术解决方案的选项以及将计划分解为功能列表的过程的所有必要步骤) ; 更新每个办公室的工作组选址计划; 控制所有开发团队的Velocity更新; 午餐订单; 前几个季度的报告; 计划清单(即将出版)和时间表的打印输出。
第二部分 规划和评论
经过所有准备工作之后,终于到了这一刻-季度计划的开始。 在两天内,我们应该有时间整理所有计划,确保有足够的信息并提交。 在简短但激烈的演讲后,工作组分散了自己的位置,开始工作。 目前,组的数量根据4x4x4公式在三个办公室之间分配,并且远程用户通过专用的Zoom通道连接到必要的表。
在发现每个计划的最后,协调人确保存在所有必要的数据,例如验收标准,技术解决方案的描述,风险,依赖关系,对新基础架构的需求,并通过“ IT会话完成”复选框记录了该计划,以确保进度和工作组的透明度可能会继续前进。
经过十几个计划,从一开始就伴随着我们的持续紧张感和暂时的时间压力已基本得到解决,现在的气氛更像是安静的工作。 在第一天和第二天的后半段,是时候根据优先级发表悠闲的评论了。 为了执行提交,我有几个单独的结构。 其中第一个是一个结构,其中包含计划进行注释的功能和路径的列表:

不幸的是,该结构包含的剩余材料与当前季度的评论不符,因此该示例不具有代表性。 无论如何,在搜索中,我都可以按编号优先级选择感兴趣的计划,在发现过程中将其按每个功能和故事放在一个单独的字段中,将必要任务的状态从``计划''更改为``已提交'',并进行正确的迭代,从而进行提交:

结果,该任务将从该结构中消失,并出现在新结构中,反映出越来越多的评论:

正如您在屏幕快照中看到的那样,在这种结构中,故事进入它们所属的开发团队的文件夹中,并按迭代进行分组。 在这里,我可以使用以下公式在文件夹名称以及“承诺”列中看到整个团队的速度,自动确定每个组的超额评价并以红色向我们发出信号。
当然,如果对第一个也是最优先的计划毫无问题地发表意见,那么很快,随着第一批队伍的积压导致失败,问题就开始了,有些计划并非毫无争议,但必须推迟。
在此简单过程结束时,公司旗帜上的团队郑重宣誓发表评论(开个玩笑)并散布在家里(这也是个开玩笑-每个人都散布在酒吧里)。
此阶段使用的工具:
- Atlassian Jira软件服务器
- 插件“结构-大规模项目管理”-用于监视发现过程和落实提交期间。
第三部分 将任务克隆到公司的可用JIRA生态系统中
当每个人都喝伏特加酒时,RTE致力于以一种形式创建评论,该评论可以分发给开发团队的积压工作并在整个季度进行监控。 为此,我使用了“用于Jira的Bulk Clone Professional”插件-它在Bulk Change菜单中添加了一个提供集体克隆的项目,并具有诸如克隆链接,更新新创建的克隆之间的链接,更新史诗链接,添加等功能。标头中的前缀并自动添加快捷方式:

我将状态作为前缀添加,因为状态在计划阶段反映了计划的完成迭代,因此,当我们计划完成功能或故事时,我会立即在标题中看到。
首先,由于我们将史诗存储在其中,因此我绝对将所有任务克隆到一个单独的Global Backlog项目中,并且我需要在新克隆的任务中具有相关的史诗故事连接。 第二步,我分别向每个开发团队提出要求,并将故事移至团队的最终项目。
结果,我创建了一个反映当前注释并包含最终任务的结构,然后将其用于监视:

通常,此方法带来的好处如下:
- 听起来有些老套,但是IT专业人员打印新功能和故事要比在粘纸上写一个标记要容易得多。
- 使用等级自动计算许多事情,例如容量平衡和WSJF更新(取决于等级)。
- 多亏了克隆,该提交的原始演员表被保留为该故事,您可以随时返回。
- 在准备计划时可以节省大量时间和精力-用纸做事需要力量。
- 当然,非常棒的是,您不再需要在gira中塞满拼图游戏。
此阶段使用的工具:
- Atlassian Jira软件服务器
- 插件“用于Jira的批量克隆专家”-用于将功能和故事克隆到最终的JIRA项目中。
- 插件“结构-大规模项目管理”-创建最终结构。
结语
朋友,当然,我知道描述是很肤浅的,并且可以更详细地揭示很多事情-监视业务和体系结构计划与运营任务之间的资本分配,计算结构公式,风险管理等等。 但是我尚不清楚这个主题是否对观众很有趣,如果真的那么有趣。 如果我有兴趣,我将准备展示必要的主题。
还有一件事-很难相信这是可能的,但是我想避免Edge,框架,有效和“高效”的管理者周围的所有麻烦。 请记住,我描述了整个过程是为了希望有兴趣的人能够在技术上接近它,并且我非常期待相关的讨论。
在评论中见!