使用Jira+Portfolio+Xray玩转SAFe Essential敏捷项目管理

应Atlassian的邀请，6月11日晚做了一场线上分享。好事多磨，明明下午测试过的网络会议，晚上却出奇的卡～～顿！在美女主持人Kylie无比耐心和机智的协调之下，我也是尝试了各种办法，最后竟然还借助身边一位帅锅的热点才完成了这一次的直播，历时2个半小时 ！

首先，我是一名落地规模化敏捷爱好者，分享知识和经验一直是我的爱好。如何定义“规模化敏捷”？说来话长，可以参考下面这一段2016年的对话和图示，引自《福布斯》(Forbes) 领导力 (Leadership) 专栏。

我个人做了十年敏捷项目管理和敏捷咨询项目，用一句话总结经验和感悟：

目前最普及的项目(产品)级敏捷、软件开发和IT部门敏捷主要是为了让Team of Teams做正确的事情以及正确地做事，并且能够让每个人融入到为最终用户交付价值的成就感之中。

Bob Hartman: As a company of trainers and coaches, we come across this question all the time. We recognized a long time ago that the word “scaling” was used for a lot of different situations. So we tried to encapsulate that in pictures with different meanings of scaling.

What we found was in the first instance a very simple type of scaling relating to the scaling of the practices of Agility across multiple teams. We saw that there were really two flavors of that. One was multiple teams working on a project (“Product”). Then there were multiple teams working on multiple products that were part of a suite of products (“Platform”). We felt that those were just different enough to make them into the figures we call “Product” and “Platform.”

We knew there were a number of scaling frameworks available, such as SAFe and LeSS. When we analyzed them, we saw them as essentially operating in the Product or Platform space (although the creators of SAFe and LeSS might take a different view). They seemed to us to be about how to get teams doing the right work and have them fully integrated.

In our firm, that’s not a very interesting problem to solve. How you do that is fairly straightforward so long as you apply common sense to it.

So we said: those aren’t really the spaces where we want to play. What we’ve found is that there are two other types of scaling, involving scaling the concepts of Agility, across (“Horizontal”) and up (“Vertical”) through an organization. We started seeing this in our clients. We would hear them say, “How can I do Agile and Scrum outside software development?” We realized that you can’t really do Scrum per se outside software, but you can do a lot with an Agile mindset and Lean thinking. So we put together courses on Agility outside of software. We call it “Agile Beyond Software,” and we will be presenting it in July at Agile 2016.

“Horizontal” scaling is about: how do we take the concepts of Agility into different segments of the organization, so that all of them can make their other processes Agile, and be on the same page as to how they are approaching business issues.

Then we saw that the biggest resistance often happens as we move up the chain of command, particularly as we start dealing with the director and VP positions and the C-suite. So we looked at that as a different scaling problem: It’s what we call “Vertical” scaling. While it’s similar to “Agile beyond software,” or Horizontal scaling, it’s not quite the same, because we are dealing with people who may have different goals in mind. Often it’s not about executing projects at all. It’s about coordination across a lot of different groups. It’s about representing shareholders. It’s about corporate governance and issues that don’t necessarily concern lower level groups. So we have developed that as a different model.

Of course the ultimate goal is to go both across and up. That would be a fully Agile organization. We saw that organizations need something beyond scaling frameworks like SAFe or LeSS. The C-suite is often talking in a completely different language from those frameworks. So if we start talking about “scaling the practices of Agility,” we are not going to have a conversation. We saw we had to come up with different language and models.

Denning: Tell me more about the Vertical model. How do you see that operating or evolving?

Hartman: We found that leaders of organizations need to be approached very differently. So we put together different ways of addressing them. We have quick-hit one-day courses where we say: “Let’s talk both about the mindset you have and the mindset that you need to have to enable the success of your organization and unleash the potential of your organization.” It’s about letting go of control, about trusting, and about using radical transparency to show results and setting people up for success. We say it is about “embracing complexity” versus “trying to control the uncontrollable.”

Some of it goes back to Eli Goldratt's book, The Goal: Can we match our capacity to our throughput in a way that’s meaningful, as compared to trying to burden people with overwork and having low-quality outcomes? We have hard discussions with those executives. Frankly, I have been pleasantly surprised as to how well they react. The one-day session contains an overview of Agile, but more importantly it introduces the different type of thinking about enablement and customer-focus that Agile is all about.

Then we try to follow that up with coaching, not just individual executive coaching but entire executive team coaching. We prefer to coach the executive team as a group so that we are covering not just leadership concepts but operations concepts and the fact that these executives have to work together and get beyond the turf-wars that are endemic at the top level of organizations. So we discuss: How can we get beyond turf-wars to come up with the goal that everyone can be striving for?

Some of this is business 101 but it somehow has gotten lost in the shuffle. And once we agree on the goal, how do we go about reaching that goal? So Agility at the leadership level is more about the thinking about the flow of value for customers and how to achieve that value. It’s not shareholder value of course, but value primarily from delighting customers and the difference that that makes. Obviously we got this thinking straight from your book, The Leader’s Guide To Radical Management.

It’s all about value for customers. Recently, I was doing a session for two days with a group and I must have used the word “value” 150 times in those two days. At the end, I asked them, “What’s the most important thing you learned in these two days?” I was pleased to hear them say: “We need to think more about delivering value.”

So we’re finding that this is connecting with senior leaders. We’re learning how to talk to people at that level. We haven’t “cracked the nut” in any final way. But we’re making progress and we are getting close.

下面是6月11日公开课的ppt，可以配合回放视频来学习和理解。

回放链接：https://us02web.zoom.us/rec/play/tcEtd-msqW83Ht3GuQSDU6MsW43uKK-sgyRKrqFemE63BnMHOwehNbsTauRHd0fQI9dcWUpDV75P1mK2?startTime=1591878020000

尽管当晚的分享一波三折，还是有不少朋友坚持到了最后，还有一些有趣的问题没有来得及答复，下面给出我的理解和建议！

jack ge 问 : 现在各个Team的Sprint用的不同的命名格式 整个公司的Sprint 有必要重新对齐么  这个重要么？

金毅 答：如果是开发一个产品，实施一个项目，或者一个关联紧密的组织，也就是针对一个Team of Teams的大团队，比如SAFe框架里的一个ART，或者Spotify部落制的一个部落，我建议使用统一的迭代节奏，这样便于自上而下对齐目标、计划和进度，我喜欢称之为集团军作战！团队间的依赖和协作可以在统一的时间窗里协商和承诺，这是使Team of Teams达到步调一致，降低额外的沟通协调成本的一种好方法。

caty 问：测试管理用的什么插件？

金毅 答：Jira的开放性使它的各种插件格外丰富。我这个项目使用了Xray管理测试。

张立军 问：请问金老师，你们每天的站会选在几点开？除了dashboard还有其他工具么？站会的关注点是什么？

金毅 答：这个项目的各个team可以选择不同时间段开站会，有的放在上午9点多，有的放在下午4、5点，还有远程团队成员参会。大家都逐渐养成了使用Jira Dashboard开站会的习惯。我和RTE以及几位scrum master一起制定了dashboard标准格式，便于team之间信息共享，以及每周周报数据的快速采集。除了几个标准视图之外，各个team也可以自己定制一些其它视图，只要便于信息共享，尤其让全体成员随时看到当前迭代以及当前MVP 的进度、风险和问题，并及时采取行动，就达到了站会的目的。

xiaoxue问：请问老师，使用了jira做敏捷管理，还有用到线下的工具吗？

金毅 答：使用电子工具要求团队各个成员都养成每天正确使用的好习惯，才能展示出正确的进度、风险和问题，分享给团队其他人，且便于分配、估算、跟踪、统计和回溯。项目前期非常需要scrum master的贴身辅导和随时纠偏。这个项目的内、外部依赖关系相当复杂，我们做了物理的Dependency Board，并在第一次PI Planning会上大家一起生成了Program Board，这些物理呈现方式很有视觉冲击效果，让团队成员和高层管理者都看到了项目的复杂度，进而针对风险大的topics再做细化和专项讨论和规划。

Jessie Li问：您是如何定制最细小的规则，我们才可以从不同的纬度显示dashboard。这个规则可以分享吗？

金毅 答：需求管理从Epic-Story-Subtask都有命名规范，test cases、test execution、test plan也有命名规范，各种依赖关系也用标准Labels标注，Sprint和MVP releases也用统一的定义。这些前期制定的规范使项目过程管理更加高效，尤其对于采集周报的数据、生成各种dashboard视图很有帮助。

金毅 答：1）下面是给整个项目各个team成员的操作规范，仅供参考：

• 申请Jira/Confluence账号

• 各个Feature Team的Jira Project和Owner

• 加入Jira Project后请更新你的头像照片

• 需求管理的三层架构

• 遵守统一的任务看板工作流

• 查看当前Sprint的工作任务并更新状态

• 在Jira里可视化Dependency

• 在Jira里创建或更新一个Story

• 每天下班前更新自己任务的Remaining Estimate

• 使用专用Label List

• 在Jira和Confluence之间建立链接关系

• 定义过滤条件查询某一类issues

• 使用Jira Dashboard监督整体进度和风险

• 基于AC和DoD估算一个故事

• 透明管理各组的风险和问题

• 批量上传测试用例

• 使用Xray创建测试用例

• 创建测试计划并执行测试

• 监控最新测试进展

• 报Bug以及更新状态

• 给出Bug的根因分析

• 在Backlog视图使用快捷过滤器查看Epic的迭代计划

• ………………
  

2）不需要每个人都花大量时间去学习jira插件的用法。我和scrum master们率先做出了所有范例和详细手册，然后sprint 0时我确实给每个team做了手把手的培训和辅导，而且我组织了SM的每日站会来随时了解各组的进展和问题，并且还利用每周的program meeting分享一些通用的good practice，当项目周报都从jira采集数据时，各个team必须要正确使用jira。

3）新手最好由老手带一带，学习工具就是动手。对于任何管理工具，其实是把整个管理流程和规范固化在了工具里面，所以需要有经验的教练和管理者统一定义规范和用法，并督促团队执行到位，而且要持续优化和调整，适合团队和项目的新需要，尤其要方便使用，方便信息共享。