写点什么

除了敏捷仪式,你更应该专注敏捷原则

  • 2016-06-19
  • 本文字数:4483 字

    阅读完需:约 15 分钟

尽管就职业而言我是一名质量分析师,但是我的特别爱好(和影响)已经通过我的工作推动了整个团队实践,而不是仅仅在测试内。自从专注团队实践的敏捷软件开发,而不是单独的开发实践创建以来,这应该是见怪不怪的事了。作为一名顾问,在过去 4 年里,我有幸在 4 个不同的组织内加入了 8 个团队,每个团队里共同的话题是——我们如何才能更有效地工作。本文提供了真实的案例(尽管有一点戏剧化):我们如何专注培养团队行为,而不是传统的团队仪式清单。

为什么从仪式转向行为

从本质上来讲仪式是不坏的,但是当对持续自我评估没有合适的框架时,盲目坚持仪式就会出现问题。一个可行的框架是 Shu Ha Ri,这一概念起源于日本传统武术,被 Alistair Cockburn 在其 2001 年出版的一本书 _Agile Software Development_ 中第一次拿来与敏捷实施进行比较。

Shu Ha Ri(大致翻译为守、破、离)是一种描述培训或者学习进展,最终有能力处理可变需求和变化的方式方法。在确定你或者你团队阶段时,你可以检查一下你需要多少结构才能让你觉得效率最高。在 Shu 阶段,团队或者个人的成功大部分是来自模仿或者遵循严格的仪式。在这个阶段,当面对冲突选项或者开放式请求时,会产生困惑。在 Ha 阶段操作的团队或者个人会尝试突破极限,就像一个小号手在一个更富有层次的乐曲中表演独奏。这个阶段有对直接命令的应变,但是此时仍是一个舒适的结构,可以从一些敏捷实践开始。例如回顾,在回顾中团队成员评估其有效性和规定具体的提高方法。Ri 阶段的特点是精通。团队或者个人在 Ri 阶段实践敏捷会受限于他人的预期。Ri 阶段的团队使自组织理念具体化,有响应变化的能力。他们有能力吸收变化同时保持专注开发实践的真实意图和业务目标。

长期以来通过仪式扩展敏捷原则的压力一直是一个重要的话题。早在 2006 年,Martin Fowler 就告诫将敏捷工作方法强加给团队是一种反模式。与此同时,在 Shu 或者 Ha 阶段,仪式为日常工作发挥着重要影响,并为日常工作提供非常高的价值。因此,不断地评估和发展这些仪式非常的重要。所以,当需要改变团队仪式的时候,你要如何实施变化和重新评估影响?如何最好地衡量发展的多样性表明——无论是 KPI 还是 SMART 目标,人们越来越接近实现这一目标的方法。我的经验证明科学方法是一种非常有效的实现途径。其核心是连续循环的观察、假设、测试和评估。当将其应用到你的团队情境中时,你可以观察人们对仪式或者团队实践生理和情感上的反应,和你希望看到什么改变,假设你能够为支持改变做的努力,对其进行测试,最后与新的行为和感受进行对比,来验证你的假设。

将理论付诸实践

没有哪两个团队是一模一样的,根据我的经验,我看到过各种各样的团队动力是如何推动将这些试验付诸实践的。我们来看一对真实的案例,并将它们与你的真实故事相结合。

假设你刚刚加入公司的一个新团队。你以前的团队已经实现了协同定位和开放式计划,你已经看到了它们带来的积极影响。几周前,高层管理人员要求这个新团队同样实现这种改变,但是这次事情的发展并不是一帆风顺。新的同伴不但表现出不信任和孤立,而且出现了生产率下降和较低的个人价值感知问题。同样这些感受都反映在生理反应上,比如带着耳机和移动纸板和其它物体来制造障碍和防护屏。

尽管你能够理解团队的感受,你也乐于分享你与之前团队的成功经验,但是你的“好哇好哇”欢呼并没有使情况发生变化。现在你需要试验,你需要一种方法用于提高协作。如果你参加言语交际以应对书面交流会怎么样?你不应该让邮件链和电话追逐游戏继续发展下去,相反你应该抽时间面对面解决同伴的问题。那可能意味着你需要用笔在白板上画出复杂的业务流程,或者提供一条建设性反馈,在邮件中该反馈可能因为太不近人情而被忽略。

采用这种方法一两周后,你发现人们因工作被中断而沮丧。太好了!现在你的第一次试验已经有了效果。不能因为效果不全是正面的就说试验是失败的。相反,现在你有了一个不同的问题需要通过新的试验解决。

在下一次的团队回顾中,你提出问题,希望继续面对面的交流,并消除对个人注意力和表现力的消极影响。你的一个同伴建议在核心工作时间里限制中断的容忍度。这个想法深受好评,所以你继续面对面交流,但是限制在一天的开始、午餐和一天的结束时间附近,以便限制在核心工作时间之外。经过一个或两个星期后,你开始发现不同!人们具有较好的响应,甚至开始采用相同的方法。就在昨天你的设计师甚至建议走路到营销团队,讨论不一致性和团队想要做什么,而不是发送邮件这种常见的做法。

试验没有就此打住。而是继续寻找方法使沟通更具有价值和包容性。另一个试验可能是创造平等的沟通空间。例如,当同伴过来问问题时,如果他没有座位,为了不让他感觉不舒服你应该选择站立。

在你所有的试验中,一定要寻找成功或者新挑战的指标。这些可能是以情感或者生理的反应形式表现出来。在这个案例中,我们看到了更多的协作,这些协作反过来加强了对需求和解决问题的好奇心。同时还有身体运动,比如为同伴创造空间和走路到相关部门。

针对更稳定团队的案例

在这个案例中,假设你已经加入团队有一段时间了。多数情况下团队都是成功的,并且能够把事情完成,但是你觉得它受限于“因为它一直都是以这种方式完成的”这种心态,你想寻找方法以团队形式拥抱变化。你的团队已经受过如何遵循敏捷的培训,所以他们早已每隔一段时间就会参加回顾会议。在现实中,虽然时间间隔不一致也不够频繁。但是重要的是,在回顾的最后,你注意到大家混合着防御和互相指责,以及分神——比如手机冲浪,和晚到。

所以现在怎么办?你如何帮助团队重新领会仪式的目的?

一个办法是承认问题。可以通过重新引入会议目标,甚至是利用最高指导原则来实现。当然这里的最高指导不是星际迷航里的最高指导原则,但是其宗旨仍然是明确指导原则。在这个案例中,我们引入了 Norman L. Kerth 在 2001 年出版的图书 Project Retrospectives: A Handbook for Team。在书中他写道:

“无论我们发现什么,考虑到当时他们的知识范畴,他们的技术和能力,可利用的资源和实际情况,我们理解并坚信,每个人都尽了最大的努力。”

通过在回顾开始时阅读这段文字,你发现相当一部分人眨了眨眼,但是人们倾听是因为至少它与以往不同,人们对此感到好奇。你将控制权还给引导者,跟往常一样继续开始活动和讨论。但是你在空气中闻到了一丝变化的味道。会议上原先勇于发言的人还是勇于发言,但是发言的时候多了一份免责,多了一份圆滑。你注意到尽管团队成员中原先神经紧绷的还是采取防御,但是你不需要跟往常一样频繁介入其中。部分原因可能是因为你在会议之前实施的引导。最高指导原则在提醒他们团队人为因素的同时,也在寻求解决方案而不是指责环境问题。这一转变远远没有达到一次完整的变革,但是你能够分辨出这是一个好的开端,因此你继续在每次会议前阅读最高指导原则,继续采取一个更有建设性、更开放的会议。

这时机会来了。平时负责主持会议的项目经理度假去了,并建议你来主持下一次的回顾会议。对你而言这是一次独特的机会,你可以在回顾中实施一些你见过的想法。目前为止你所看到的基本是 3 类讨论:哪些进展顺利,哪些进展不顺利和人们对哪些有疑问。这一趋势已经促使一些积极面出现在白板上(“伟大的团队点心”,“很高兴 Sarah 支持我们”)并发现, 问题和不那么积极的事情的数量是带有感情色彩的,很难提炼成精简、专注解决方案的交流。

你选择的形式很有趣。是 Akash Bhalla 博客中介绍的僵尸回顾( Zombie Retrospective)。它采用了上文 3 种分类思路,但是对它们进行了彻底的重新设计,使团队准备好接受更有建设性的想法。同时因为你们需要一起击退僵尸,所以还宣扬急需的团队友爱!现在,如果没有一点侧面跟踪和玩笑,几乎不可能通过僵尸讨论会,但是很快你就意识到它的价值,明显促进了团队的参与度。他们可能是私下交流,但是至少他们在讨论。一些团队成员可能错误地把组织内的其他人看作僵尸,但是他们同样在寻找如何缓解问题的方法,而不是互相指责。

每个团队遵循的旅程都可能受到人际互动和交付压力阶段的影响。重要的是不要反对这些变化,相反应该拥抱它们,以有效的方式平滑引导。针对疑难杂症量身定制的回顾能够达成这一目的。

事实证明这种回顾非常成功,以至于你被要求一直坚持下去。你有点紧张,担心这会凌驾于项目经理之上,但是大家似乎都不介意,因此你决定试一试。当你身处下次回顾中时,它就像一个灯泡突然在你的脑海中熄灭!你可能是引导者,但是很明显你的 PM 才是会议主管。当 PM 驳回这些想法时,你发现盾牌重新回到同伴身边。考虑到 PM 行使权力的方式,每次你想介入的时候,你同样无话可说并且不知道如何进展下去。

你感到沮丧,因为你知道这些回顾的潜力,但是你现在碰到了壁垒。因此你向另一个团队的朋友寻求帮助。他们建议你不应该让你的 PM 参加回顾。尽管这可能会解决目前的症状,但是肯定会引起新的问题。好的,下一个思路:你的朋友建议你“在团队里寻找一个可以跟 PM 叫板的人,因为我是一个不能容忍别人欺负同伴的人”。因此我决定,就是它了。你说服你的朋友成为下一个引导者。他们公正地对待议题,但是又能充分意识到团队动力,从而密切关注欺凌弱小或者害羞的行为。

在下次回顾中试验上线了,尽管过程有些坎坷(比如,你的朋友必须澄清许多条款和被提议问题的上下文),但是很明显这是朝着正确方向走的一步。考虑到你朋友使用的强硬的引导方法,PM 被给予表达担忧的机会,但是只有轮到他们的时候才行。这一中立引导者的使用提高了协作,并对团队的情感和讨论的议题给予了同等关注。

在这个过程中你已经试验了 4 或者 5 次回顾,需要进行重新评估。让我们回到成功的情感和生理特征的重要性。你已经亲眼目睹更多的人愿意在会议上发言。对提出问题的消极反应越来越少,相反专注解决方案而不是指责。在整个迭代过程中第一次提到了回顾讨论,甚至是在会议时间之前讨论的认同问题。看上去人们的参与度越来越高,因为他们准时参加会议,而且不太可能拿出他们的手机和笔记本电脑。

如何应用这些理念

这两个例子可能不能完全反映您的经历。例如,在团队会议中造成恐慌的可能是开发者而不是 PM,或者你可能工作在一个分布式团队中,因此无法亲自走到人们面前。如果这是你最大的收获,那么这篇文章可能不适合你,但是我要再次强调一下:

  • 无论礼仪或者实践,寻找一种背靠最初意图并专注努力的方法。
  • 清楚认识到你只能控制你自己。如果你发现仪式作用不大,想法设法使其对你更有价值,因为其他人会模仿。
  • 识别团队不是在仪式中寻找价值的触发条件,并使其更加明显。
  • 寻找简单但成熟的试验和改进技术,比如科学方法或者 SMART 目标,以帮助团队更容易实现变革。

关于受访者

从 2012 年开始,Abby Bangser就一直是 ThoughtWorks 的一名质量分析师,她的主要兴趣在缩小不同开发团队角色之间的差距和助力 QA 社区。她的精力包括起草并交付了内部和外部培训方案以及客户工作的多样化投资组合。来 ThoughtWorks 之前, Abby 曾在不动产投资工作,并且她继续活跃在青年曲棍球教练中。

查看英文原文: A Focus on Agile Principles over Agile Rituals

2016-06-19 19:392019
用户头像

发布了 92 篇内容, 共 25.0 次阅读, 收获喜欢 4 次。

关注

评论

发布
暂无评论
发现更多内容

XSS跨站脚本攻击漏洞修复技巧

喀拉峻

网络安全

Tapdata加入PolarDB开源数据库社区

阿里云数据库开源

数据库 阿里云 开源 开源数据库 polarDB

2022年作为一个中年程序员写给35岁的自己

Linux服务器开发

c++ 程序员 架构师 Linux服务器开发 Linux后台开发

初创企业CRM系统解决方案

低代码小观

初创公司 企业微信 企业管理系统 CRM系统 客户关系管理系统

阿里本地生活端智能架构设计与技术探索

阿里巴巴终端技术

端智能

模块一作业

HZ

架构实战营

新思科技加速安全软件开发,推出Code Sight插件标准版

InfoQ_434670063458

软件开发 新思科技 可信软件 IDE环境 Code Sight

想让DBA瞬间崩溃,那就让他去做SQL性能优化

华为云开发者联盟

数据库 sql 遍历 存储 优化SQL

谷歌云对象存储攻防

火线安全

安全攻防 对象存储 云安全

实现简易的 Vue 响应式

CRMEB

3步排查,3步优化,探针性能损耗直降44%

TakinTalks稳定性社区

Java 性能分析 探针 性能提升 性能损耗

架构实战营 第6期 模块一课后作业

火钳刘明

#架构实战营 「架构实战营」

高性能的连接管理和数据路由组件,OceanBase 生态工具 ODP 详解

OceanBase 数据库

oceanbase OceanBase 开源 OceanBase 社区版

如何搭建B端产品帮助中心

小炮

帮助中心 B端用户

关于黑帕云用户迁移明道云的详细说明

明道云

华为云企业级Redis揭秘第17期:集群搭载多DB,多租隔离更降本

华为云数据库小助手

GaussDB GaussDB ( for Redis )

CSDN 数据库Meetup|OceanBase 技术专家讲述 SQL 的一生

OceanBase 数据库

oceanbase OceanBase 开源 OceanBase 社区版 OceanBase社区

巧用对象存储回源绕过SSRF限制

火线安全

Web 云安全 web漏洞

不仅仅是一把瑞士军刀 —— Apifox的野望和不足

Liam

Java 程序员 Jmeter Postman swagger

网络安全 Kali web安全 基于SMB协议收集信息

学神来啦

Linux 运维 网络安全 WEB安全 kali Linux

KubeVela: 如何用 100 行代码快速引入 AWS 最受欢迎的 50 种云资源

阿里巴巴云原生

明确生态边界的钉钉,让ToB从业者们松了口气

ToB行业头条

Go Data Structures: Interfaces [中译]

hyx

源码 Go 语言

Go性能优化小技巧

jinjin

Go 性能优化

如何选择天翼云云硬盘

天翼云开发者社区

云硬盘

天翼云虚拟IP地址及其在高可用集群中的应用

天翼云开发者社区

虚拟机

【性能测试工具lmbench】快来测测你的系统可以打几分

优麒麟

Linux 开源 系统管理 优麒麟

直播预告 | PolarDB-X 动手实践系列——用 PolarDB-X + Flink 搭建实时数据大屏

阿里云数据库开源

数据库 阿里云 开源 分布式 polarDB

19 条有效的跨端 cpp 开发经验

阿里巴巴终端技术

cpp 跨端开发

物理裸机配置如何转换为天翼云云主机配置

天翼云开发者社区

云主机

【OpenHarmony移植案例与原理】XTS子系统之应用兼容性测试用例开发

华为云开发者联盟

测试 OpenHarmony XTS 应用兼容性测试

除了敏捷仪式,你更应该专注敏捷原则_文化 & 方法_Abby Bangser_InfoQ精选文章