透明这回事

前言

透明向来是敏捷强调的,Scrum 更是把透明列为三大支柱之一,今天想跟大家分享一下我对透明的看法。

为什麽要透明

从敏捷看起,在其宣言原则当中,或多或少藏有透明的隐喻,包含:

  • 宣言第一条「个人与互动重於流程与工具」,透过良好的沟通互动使透明能够正向循环
  • 宣言第二条「可用的软件重於详尽的文件」
  • 宣言第三条「与客户合作重於合约协商」
  • 原则第四条「业务人员与开发者必须在专案全程中天天一起工作。」
  • 原则第五条「面对面的沟通是传递资讯给开发团队及团队成员之间效率最高且效果最佳的方法。」

从 Scrum 的三大枝柱来看,「透明」位居首位,在其运作过程中,有个最具体、最直接可见的透明度展现就是 Scrum 看板,那个可能以实体或虚拟方式存在,承载着团队现况的看板。

良好的透明有助於团队内外掌握现况,并能够从中观察到问题加以解决,这应该是大家都同意的,但它就是如此宽广,有没有更实际的阐述,好让团队重视透明?更不要抗拒透明?必竟透明可能会暴露自己的缺点,这感觉似乎不太好。

有的!让我们继续谈。

透明是保护自己与团队的

我认为这是个重要的概念,多数人习惯隐藏不光彩的一面,在事情可能偏差时自己就先下了「错了」、「不好」或「很糟」的定论,并加强力道盖着这些迹像,让它不显露出来。熟悉吗?这也许是过去团队进度报告常见的情况。

虽然 Scrum Guide 2020 版本已经去除 Daily Scrum 当中经典的 3 个提问,即昨天做了什麽?今天要做什麽?有什麽障碍?但是 Daily 用来同步现况并发现问题的本意还是存在的。

为什麽要说明自己遇到什麽问题?积极来看,不外乎是让团队成员了解现况,让团队思索有何解方、有谁可以提供协助与资源;消极来看,它可能是一种卸责,用来解译自己为什麽不在状态上,但无论如何,障碍、困难、问题总是被曝露出来了,团队以「开放」的心态面对,并努力排解它,让目标实现的道路更为稳健。

若问题不在自身,而在他人,恰好被自己敏锐的观察给发现了,若碍於面子不敢提出,於是问题继续延烧,直到其他有「勇气」的人站出来。这在高度风险的工作场域中是不允许的,或许软件开发通常情况下没这麽严重,但若你的产品服务是与生命安全相关的呢?或着退一步,与钱相关的呢?必竟现代社会视钱如命啊…。

基於藏拙心理,如果是自己的能力不足,要公开求援可能也非易事。这不能怪任何人,每个人多少有自己的人设,可能源於自我认定的成功之处,例如向来在团队中表现亮眼,那又怎麽能够示弱呢?一直都考第一名的人,会有不会的题目?社会至今已经产生了不少刻板认知,默默助长了不愿表态的行为。对於这种情况,无论它是否正发生在你我身上,我建议思考:「我在团队里做什麽?」,希望你我都能发现到,我们正是实现目标的一份子,所以别让自己的能力障碍了它,该去补足的、该求助的,在第一时间做。

作为实际案例,身为 ScrumMaster,我不止一次感受到团队成员的创意,以及面对问题能够提出最适切的方案,这让我相信一种可能,就是问题与困难是可以抛出来,集思广益,一同解决的,团队不就是为此而生吗?

最後,透明也会成为各种统计分析的基础,管理层可以从中获取进度、效率与成本资讯,也可能与绩效产生关联。谈钱、谈绩效伤感情,若这正是团队不敢、不想、不愿透明的原因,那实在是太可惜了,请把它当作一种机会,一种展现成果的机会。

透明比想像中的广大

透明是个浩大的工程。

以「完成的定义」(DoD) 来延伸,这是在导入 Scrum 常见的一种共识凝聚的产物,让团队成员清楚怎样才算是完成,避免在沟通时有意无意扭曲了现况,是一种消除资讯不对称的工具。我们大概知道,成员在回答「进度」时内心会经历些什麽。

团队运作需要透明且精确的资讯,以一项功能的完成与否而言,牵动不仅是团队本身,不同部门如业务、行销也会需要这些资讯,来作为市场推展的後盾。而在团队内,与你合作的夥伴也需要你真正的状况,好评估己自需要做什麽准备,或提供什麽支援。

一个「不透明」可能带来的危害远比想像中的还多,最後受冲击还是整体利益,因小失大。

此外,透明还有更多展现的方面。

例如,我们对客户透明吗?敏捷宣言第二「可用的软件重於详尽的文件」,在 Scrum 当中的体现则是我们是否在每次冲刺都交付真正可用的软件,让客户看得到、用得到,这种可以被提早审视的做法,背後也带有透明度的展现,让客户在整个专案的进展过程可以时时确认。类似的道理,宣言第三「与客户合作重於合约协商」依然有透明的成分存在。

而公司内部的制度与流程是否也是透明的?这会也影响到团的执行,若制度不明容易引发过多的猜测,且无从依循,流程不明确更会造成许多执行上的错乱。

甚至小到团队进行程序码审查 (Code Review) 的标准与规则是否透明?今天有谁休假?这场会议有谁会出席等,方方面面都是团队展现透明度的时机。

透明的正向影响

前面多少讨论了一些透明在团队内带来的好处,而透明的展现也会在利害关系人当中产生一些奇妙的作用,例如:

  1. 团队越透明,越能够呈现整体动起来的情况,对於整体士气的鼓舞有帮助。
  2. 团队越透明,老板越放心,受蒙蔽的程度降低了。
  3. 团队越透明,误会相对减少。
  4. 团队越透明,自主排除问题的能力越强。

透明的负面挑战

虽然很不想以这种非黑即白的概念来呈现,但现阶段这样比较简单。前面讲了不少透明带来的好处,现在来看一下透明可能面对的挑战。

以现在的资讯系统而言,要达成透明不算困难,但有哪些东西需要透明?又要有多透明?

我认为这不用过度钻牛角尖,团队运作所需的指标自然需要透明,例如 Scrum 看板与 Burndown chart 上面的工作现况、Github / Gitlab 上面的 Issue 记录;又如远距工作时可能得知道成员的上下班情况,避免无效或不必要的打扰,所以上下班资讯也需要透明。

真正需要透明的资讯,团队自然会知道,因为这些不透明自然会对整体运作带来一些困难,因此一些不重要的资讯可以被排除,一方面避免过多的资讯量、二方面也减少资料搜集带来的额外成本 (如追加的作业程序、多花时间去记录)。

而最容易让透明「黑化」的就是它的运用方式了。团队可以用它表扬好的表现,但不宜用来指责失误,失误与问题是顶多是团队需要努力的下个目标,看到了,就去排解它!团队若让透明与指责产生关联,那透明之路将备受阻碍。


<<:  Day 7 - 计算属性和监听器

>>:  Day7-JDK查看正在运行的Java进程工具:jps

进击的软件工程师之路-软件战斗营 第十五周

学习进度 设计模式 迭代器模式 观察者模式 Android Studio SQLite Room 心...

[Day10] 如何实现图片填色功能 (完结)

#733 - Flood Fill 连结: https://leetcode.com/proble...

【Day 12】Python os._exit()和 sys.exit()

Python的程序有2种退出方式:os._exit(), sys.exit() os._exit()...

[Day 3] Reactive Programming - Functional Programming

前言 并不是说Reactive 一定要搭配Functional,只是搭配起来更好用,而後面介绍到的R...

[Day 04] 测试驱动开发

接下来要讨论的问题是, 什麽时候开始写测试, 很多人会觉得应该在整个软件开发完之後开始写测试, 但是...