原创

敏捷团队实践

业务实践介绍完了,现在该聊聊团队实践了。团队实践支配着团队成员之间的关系,以及团队成员与他们所创造的产品之间的关系。这些实践有助于小型团队表现得像真正的团队。他们帮助团队建立交流的语言,使团队成员对彼此、对正在构建的项目的期望保持一致。

隐喻

ubiquitous_language

隐喻是一个看名字你根本不明白这是啥的实践,即使是看了它的概念,你也许还是会这么想:为了有效地进行沟通,团队需要一个受限制的、有几率的词汇表,其中包含项目中的术语和概念。这个实践的目的是为了将项目与团队具备的共同知识关联到一起。

这个隐晦的实践直到领域驱动设计的出现迎来了曙光。埃里克·埃文斯(Eric Evans) 在《领域驱动设计:软件核心复杂性应对之道》中创造了一个概念 - 统一语言(Ubiquitous Language)。这才是隐喻该有的名字。

在某一个项目中团队需要对问题域进行建模,描述这个模型的词汇表需要得到所有人的认同,是的,包括利益相关者。这样做有一个好处,当大家在讨论问题时,不用做过多解释,大家都在同一个上下文里。举个例子:

在某项目中需要用一个词语来指代系统的客户,在项目前期并没有统一语言(或者说没有很好地实践隐喻),大家对客户一词有无数个词语来指代 - person,client,customer...于是在讨论问题时,他在说person,我在说client。在代码里也是同样的情景,同样的实体,有无数个变量名,但其实他们都是同一样东西。

统一语言过后,大家指定一个用词,摒弃其他所有词语,不论是在代码中还是在讨论的时候大家都能在同一个上下文里。

可持续节奏

work_overtime

跑得快的不一定赢。

加班

加班是程序员们绕不开的话题,我们需要达成一个共识 - 永远不加班是不现实的,低频率的偶尔加班是合理的,一直在加班是不可接受的。

长期加班或者说是加班到深夜,会给我们带来什么?以我自己为例,我的脑子里一团浆糊,平时简单的问题我需要更多的时间来思考;我更容易做出错误的决策,第二天上班发现自己昨天写了一坨无法描述的代码;代码质量也得不到保证。

加班只有两种原因

  • 需要解决复杂问题
  • 需要赶工期保证项目完成

这两种问题可以通过很多方式解决,但长期加班绝不是唯一一种,在第一篇文章中,我们已经有了一些不错的解决方案,或许还有很多别的方案,你必须非常清醒地意识到加班的成本可能远远超过节省的时间。

当然,在国内背景下,有一些项目需要迅速抢占市场以获得第一批用户,这些项目的同学需要无休止地加班,在这种问题上,每个人都有不同的选择。

马拉松

不管是项目管理者还是程序员或者别的什么角色,都应该意识到软件项目是一场马拉松,而不是冲刺,更不是一系列的连续冲刺。你的奔跑必须能长时间坚持。你必须以“可持续节奏”来奔跑。

一旦冲刺,你就必须减速或者休息(换句话说就是996都在划水),这样一来,你的平均速度将慢于“可持续节奏”。马拉松的冲刺,应该只发生在快接近重点且你还有足够的能量。

请你记住,加班工作并不能向雇主展现你的奉献精神。相反,如果你自己天天在加班,而同事没有加班,说明你的计划做的很糟糕,你答应了不该答应的截止日期,承诺了做不了的事情,你只是一个可被操纵的劳工而非专业人士。

睡眠

不管怎样,请保持你充足的睡眠,这是人类最好的养生之道。每个人所需的睡眠时长不一样,尽快认识自己的身体,找到自己到底需要多久的睡眠。请不要让工作吞噬你的睡眠时间,否则你的生产力会直线下降。

代码集体所有

codebase

敏捷项目中没有人独占代码,代码归集体所有。任何团队成员都可以随时改善项目中的任意模块。团队集体拥有代码。这样做的好处是知识会分散在团队中。每个团队成员都能够更好地理解模块之间的界限,以及系统的整体工作方式。这极大地提高了团队沟通和决策的能力。

代码集体所有并不意味着你不能有所专长。你需要做的是既要在自己擅长的领域工作,还要与其他领域的代码打交道。

一些公司的规则与这完全相反。每个程序员拥有自己的代码,并且要对自己的代码负责。程序出现 bug,要通过代码追责;别人需要修改自己的代码,需要告知你,由你来修改;业绩和地位由代码来决定,关键业务代码的程序员地位高于其他程序员。

整个代码库无法复用,模块封闭,壁垒坚固。

持续集成

CI_firmware

在早年的敏捷中,持续集成意味着开发人员每隔一两个小时就签入一次源代码的修改,并将其合并入主干。所有单元测试和验收测试都应该是通过状态。不存在任何未集成的特性分支。部署时不应激活的所有变更都要通过开关(toggle)来处理。

这个时候所谓的集成其实都是开发人员自觉在本地实施的,是否真的破坏了集成,需要开发人员自觉地修复或是等到 QA 来发现问题。

2001年,ThoughtWorks 创造了 CruiseControl,第一个持续构建工具。这个工具可以将签入时间缩短至几分钟。它能够监视源代码控制系统,一旦发生任何签入就会启动构建,自动运行系统的大部分测试,并将构建结果发给团队中的每一个人。

后来出现了许多大家耳熟能详的构建工具 - Jenkins、Bamboo 等等。因为签入源代码的时间已经被缩短到几分钟,持续构建变成了持续签入,每一次签入都将触发一次构建。

纪律

持续构建应该永不失败,每个程序员都要在提交代码前运行所有测试。如果构建失败了,那说明有奇怪的事情发生了,毕竟你在本地的构建时成功的。

失败的构建是一次紧急事件,应该有物理措施立马通知所有人,所有人应该用最高优先级来处理这个事件,所有程序员应该停止手头的工作,合力将构建修复成功。构建必须永不失败。

代价

如果对构建失败熟视无睹会发生什么?简单来说,这是在作死,所有人都会自动屏蔽构建服务器发来的失败通知。经受不住骚扰的人还可能删去失败的测试,觉得以后加上就好了。往往这样的以后会变成永不。

日复一日,构建看起来都是完美的,但是大家都忘了其实我们删除了一大堆测试,既然测试失败了,那么也就意味着我们的系统已经被破坏了。

但是无所谓,构建时绿色的,它在告诉大家,系统现在可以被部署,于是,一个不堪重用的系统上线了。

站会

stand_up

站会的思路很简单,团队成员站成一个圈,回答3个问题:

  1. 上次站会之后我做了什么?
  2. 下次站会之前我要做什么?
  3. 什么阻碍了我的工作?

在站会上不要讨论,不要深入解释,不要藏着掖着或者带情绪的表达,也不要发牢骚或聊八卦。每人30秒,会议结束,该干活的干活,该讨论的自己下去讨论。

虽然思路简单,但是在实践的过程中大家依旧会产生很多困惑,这些回答或许可以解答你的困惑:

  • 该会议是可选的。许多团队不开这个会议也能过得很好。
  • 不一定每天都开。但需要选择合理的时间间隔。
  • 即使是大型团队,站会时间也只应该在10分钟以内。
  • 这个会议只遵循上述的简单议程,不要多加任何东西。

猪和鸡的寓言

猪和鸡的寓言讲的是:

一只猪和一只鸡走在路上。 鸡说:"嘿,猪,我们开一家餐馆吧!" 猪回答说:"嗯,可以啊,我们叫什么名字呢?" 鸡答道:"叫火腿蛋怎么样?" 猪想了一下,说:"滚!你要我的肉,但你就下个蛋!"

问:在培根加鸡蛋的早餐中,鸡和猪有什么区别? 答案:鸡只是参与,但猪需要牺牲!

这个故事应用在站会里面的意思是:理论上来说,只有开发人员才能在站会上讲话,经理和其他人可以旁听,但不应该插话。但其实这不是一条铁律,只要议程还是那样的议程,如果需要,其他人也可以发言。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 规模化敏捷LeSS(二):LeSS团队实践指南

    Scrum 能够帮助一个5-9人的小团队以迭代增量的方式开发产品,在每一迭代结束时,交付潜在的可交付的产品增量。正是由于其灵活性,Scrum 方法现已成为团队软...

    敏捷开发
  • 敏捷团队工作流

    站会中的内容是每天工作的开始,也是对昨天工作的回顾。一般会由团队的某位成员主持,这位主持人有责任让电子系统上的story卡片和看板上的保持一致。站会上,大家依看...

    lambeta
  • 你们是敏捷团队吗?

    最近常看到有些人说他们是敏捷团队,但仔细了解一下他们的工作方式和环境,确实不敢恭维为敏捷团队。 我觉得考量是否为敏捷团队可以问一下几个问题,如果你都能回答的话,...

    麦克-堂
  • 【敏捷1.4】敏捷开发环境:领导与团队

    敏捷中,最重要的是什么呢?基本上所有的教材都会说,敏捷是以人为本的,以团队为核心的。第一,敏捷不提倡加班,第二,敏捷让团队自管理,第三,敏捷中的领导都是服务员而...

    硬核项目经理
  • 流程, 敏捷实践 (框架), 团队成员的三边关系

    前言: 流程是轨道, 敏捷实践 (框架) 是行驶在这轨道上的火车, 团队成员便乘著这列火车, 迈向版本交付的终点◦ 本文: 企业内推行敏捷变革时, 往往将敏捷...

    Ken Fang 方俊贤
  • 敏捷团队的最佳测试实践:自动化金字塔

    自动化测试和敏捷软件开发常常是成对出现,但敏捷中的自动化往往说起来容易做起来难。大多数开发人员都已经认识到测试自动化的好处:它加快了测试速度、降低了成本、增加了...

    陈琦聊测试
  • 团队空间:敏捷团队的办公室设计

    Martin Fowler在他的一篇博客(Team Room)中介绍了ThoughtWorks对敏捷软件开发团队所应采用的“团队空间”的观点:团队空间内部应当完...

    ThoughtWorks
  • 沙龙报名 | 敏捷总动员,6月9日上海

    携程技术
  • 首度揭秘:腾讯敏捷研发和极速交付破局之道

     导读  腾讯到底是怎么进行敏捷研发和极速产品交付的呢? 腾讯研发管理部高级产品经理、敏捷教练张贺,受邀在DevOpsDays深圳站中进行了相关分享。 他从“...

    TAPD敏捷研发
  • 我们真正该关注的应该是产品开发的效率与质量, 而不是工程实践或敏捷的价值

    2017.5.12, 深圳, Ken Fang 2014 年, 我设计了产品级敏捷。 2015 年, 我设计了微服务产品级敏捷。 有人问我: 产品级敏捷、微...

    Ken Fang 方俊贤
  • 首度揭秘:腾讯敏捷研发和极速交付破局之道

     导读  腾讯到底是怎么进行敏捷研发和极速产品交付的呢? 腾讯研发管理部高级产品经理、敏捷教练张贺,受邀在DevOpsDays深圳站中进行了相关分享。 他从“...

    腾讯技术工程官方号
  • 敏捷 | 如何正确推进敏捷?

    无论你的公司是在做敏捷转型还是一开始就使用敏捷,在推进敏捷的过程中往往都碰到了很多的问题。今天和大家分享一下业界认可的正确推进敏捷的三个步骤:评估诊断、敏捷试点...

    Edison Zhou
  • 企业敏捷转型道路|洞见

    企业不敏捷就out了 很多企业已经走在敏捷转型的路上,首先始于电信和互联网公司,然后是金融行业,现在连零售这样的传统行业都在尝试转向敏捷。 从2001年敏捷...

    ThoughtWorks
  • 敏捷 | 如何填好推进的坑?

    无论你的公司是在做敏捷转型还是一开始就使用敏捷,在推进敏捷的过程中往往都碰到了很多的问题。今天和大家分享几个在推进过程中常见的坑,以及如何填坑。

    Edison Zhou
  • (二)如何选择生命周期?

    项目有多种形式,也有多种实施方式,项目团队需要认识到相关特征和方案,以选择可能使项目成功的方法。

    砖家认证
  • 33.【Kevin聊敏捷】敏捷项目管理APM-Agile Project Management(二)

    「持续创新」是对现在客户需求的交付;「产品自适应」是对未来客户需求的交付;「团队和流程自适应」是对产品或者商业变化的迅速反应;「减少交付周期」是为了快速交付可工...

    开心的Kevin
  • Scrum需要一个双刃团队

    1993年,Jeff和Ken开创了Scrum,至今已经有25年之久。如今敏捷开发也不是什么流行词儿,不少IT组织已经走在敏捷转型的路上,还有一部分组织则刚痛下决...

    袁慎建@ThoughtWorks
  • 敏捷实践指南

    yeedomliu
  • 32.【Kevin聊敏捷】敏捷项目管理APM-Agile Project Management(一)

    Agile Project Management的创始人也是敏捷宣言的十七大佬之一,Jim Highsmith。

    开心的Kevin

扫码关注云+社区

领取腾讯云代金券