创建完整团队的艺术：敏捷如何改变我们与客户的工作方式
来源：Ackarlix博客【http://www.ackarlix.com】
十年前，《敏捷宣言》的作者们希望我们重新思考：我们作为程序员与客户协作的方式。我和我的博士学位顾问Robert Biddle以及James Noble都深受启发，充满希望，并渴望了解如何在实践中让这种协作发挥作用。不是人们常说的它应该如何起作用，而是它如何真正有效果。接下来的6年中，我们努力了解这一点，访问了5个国家的11个敏捷团队【注1】。这些团队处于多个不同行业，大小从5人到60人不等。
那么是什么让敏捷如此与众不同？首先，时间盒（也被称为迭代或是sprint，看你喜欢哪种术语）让客户能够随时间推移了解自己对软件的真实需求：要开发的“真正的东西”到底是什么。我们研究的一个客户是这么说的：
“如果我们在一开始就深入到底层需求，我觉得那将会非常困难，因为我从未接触过新的软件和业务流程，因此很多时候，我也是一边前进一边学习。看到真正的东西之后，就能很容易地指导下一个层面要做什么样的详细决策了。”
——KiwiCorp客户
敏捷也鼓励我们这些程序员与客户每天互动，并获取反馈，而且将其视为常态。我们不应该指望“从墙那边”扔过来一个文档，其中描述了客户的完美系统。实际上，我们应该成为客户了解系统真实需求这个过程的一部分。在我们的研究中有一个好消息，我们发现客户喜欢这种软件开发的新方法：
“总体来说，我喜欢这种开发方法，而且在未来我能够参与的所有项目中，我也非常愿意再次使用这种方法。”
——KiwiCorp客户
客户还特别提到：他们非常珍视与程序员建立起来的新型协作关系。比如：
“以前，你撰写文档，然后在文档上获得反馈，这就变成了传统瀑布流程中的技术设计规范，不到产品最后产出的时候，你不会知道：有人搞砸了一些东西……但是在极限编程中，你可以及时在正确时机定义产品，并与之产生非常非常紧密的关系……极限编程之于我，最有力的一点在于：我能够调动和我一起工作的、整个开发人员小组的集体智慧……”
——EagleCorp客户
在我们研究的团队中，是不是一切都非常完美？并非如此。我们都是人。人是不完美的，不管我们多么希望他们完美。人也能够非常出色地解决问题，在本文中，我们讲述两种实践，这两种实践显现在我们研究的成功完整团队之中。
第一个完整团队实践，我们称之为“客户的学徒（Customer’s Apprentice）”。讲一个我们最初遇到的团队的故事，这个故事能完美阐述这个实践。在这个团队中，客户让程序员们感到越来越郁闷。客户没有提供足够的用户故事，程序员常常很空闲。几个月之后，有一个程序员实在是太郁闷了，他自愿帮助客户撰写用户故事。团队的教练是这么说的：
“那个程序员说：我还不如花上一天与客户一起写用户故事呢，这能在以下几个方面帮助客户：首先，多一个人写用户故事；其次，可以回答客户任何技术问题；第三，让我知道项目困难程度到底如何。如果真得很简单，我们就可以继续不断敲打客户，以了解他们的真实情况。但是事情不是这样。程序员回来之后，他说：还真是有一个与写用户故事相关的流程，要去挖掘需求，然后找到业务相关人士，让他们解释需要什么东西，以及类似的过程。这让程序员们变得谦虚了，而且与客户的关系也变得更有效率。事情因此变得完全不同。了解了一些情况后，开发人员们对客户的痛苦也有了一些深入的了解。”
——SwiftCorp团队教练
花费两个迭代成为客户的学徒，这的确让程序员帮助客户取得了进展。但是，也许更重要的是，对于客户的任务范畴，他有了更深入的了解和理解。在这个故事中，客户方面的两家公司刚刚合并，要开发的系统即将成为咨询公司的标准系统。客户遇到了很多公司政治层面问题。较大的业务组织非常害怕改变会影响他们的工作。程序员也看到了客户为了开发系统所处的困难境地，他可以把这个理解带回团队，让大家感同身受。
在另一个故事中，客户没有让程序员们感到郁闷，可是他们的工作过于繁重，程序员们注意到了这一点。两个程序员自愿在一个迭代之内成为客户的学徒。程序员与客户紧密工作，帮助客户完成每天的工作，帮他们扛一些担子。
这就是程序员所能提供的典型帮助，有助于创造出将客户包括在内的完整团队。将上两个故事与接下来这个对比：在一个团队中，客户在过去的12月中，每周都要工作70到80个小时。此案例中，程序员（还有教练）将自己每周工作40个小时的权利奉若神明，根本没有意识到客户已经超负荷工作很久了。
有时，作为程序员，我们常常不知道客户为什么对我们生气，或是为什么他们那么忙，无法满足我们的要求。这个实践可以让程序员“穿上客户的鞋子”，只是一小段时间，就可以深入了解和感受客户的工作状况。我们作为程序员，每天工作，是无法了解这些情况的。我们发现：最高效的团队至少每三个月就要使用一次该实践。它不必是一个过于正式的实践，程序员只要自愿“帮忙”，就可以起到非常好的效果。
第二个完整团队实践，我们称之为“现场程序员（Programmer On-site）”。我们用故事来讲述这个实践。此案例选自我最近指导的一个团队。其中一个程序员非常担心应用的用户界面。他觉得这个界面的设计非常糟糕：在界面中，呼叫中心的操作员在接电话时，需要翻滚好几页数据。现场的呼叫中心代表不管说什么，都无法说服他这个设计很有效。程序员在接下来的一个月中多次提出他的担心。在程序员和呼叫中心操作员之间的紧张情绪不断升温，原本有效的协作陷于停滞。
一个机会出现了，程序员可以访问呼叫中心。呼叫中心位于项目办公室三个小时火车车程之外。当他到达呼叫中心后，有人让这个程序员去观察一个操作员的工作。开始时，程序员告诉操作员：用户界面一定“很难用”。年轻的操作员说：“不是这样的，我来告诉你为什么。”程序员接下来用了一个小时观察操作员接听电话，使用应用，他突然明白了为什么用户界面要这样设计。尽管过去有多次讨论，对他来说，只有亲眼见到实际使用情况，他才能明白。但是，我们的故事没有就此结束。程序员在观察操作员使用应用的过程中，他观察到一个步骤，认为自己可以通过自动化手段免去这个步骤。操作员在过去的研讨会中没有提起这一点。在程序员离开呼叫中心之前，他与操作员一起编写了一个用户故事，把想法记录下来。团队在接下来的迭代中开发了这个用户故事，一个月之后，这个功能发布了，而且节省了操作员在每次通话中耗费的时间。
仅仅跟最终用户“谈话”还不够。我们有时会忘记：要构建什么样的东西，是软件开发中最难的部分：
“构建软件系统最困难的工作，就是精确判断出要构建什么……软件开发人员为客户所做的最重要的事情，就是对产品需求的反复抽象和修正。因为真相在于：客户不知道自己要什么。他们常常不知道要回答什么样的问题，而且他们几乎从未想过待解决问题的细节如何。”
Fred Brooks，1995，《人月神话·周年纪念版》，Addison-Wesley出版社。
现场程序员是一个很简单的实践，与时间盒或迭代开发一起使用，帮助客户与我们一起工作，判断什么是我们要构建的“正确的东西”。在实际中，组织程序员观察最终用户实际工作，要比想象中简单。有时我们需要一点非常规的想法。比如，一个在能源交易领域中的团队，他们最初认为自己无法观察交易员，因为交易场地在交易时间内是禁止进入的。然而，跟交易员简单聊过几句之后，他们制定出一个能让大家都满足的计划。交易员后来受邀与程序员共同参加一个午餐会议，会上，在程序员观看视频的时候，交易员向大家解释自己当时在做什么，想什么。交易员跟人说：他当时觉得自己像一个“明星”。他喜欢得到的注意力。更重要的是，他突然可以与程序员说明：为什么他认为系统如此难以使用。他有特定的例子可以讨论，而程序员也可以看到他说到的问题产生的直接影响。最终，大家达成了一致，并且可以协作，产生解决方案。
作为总结，《敏捷宣言》的作者们在10年前希望我们重新思考：我们作为软件开发人员与业务人员交互的方式。在创建协作伙伴关系方面，我们已经有了很大的进步。但这还不够完美，其中涉及到人与人之间的关系。很重要的一点，是要记住：我们“身处同一条战线”，这不是“我们”与“他们”之间的对抗。本文列出的两个实践，有助于我们记住这一点。我们使用敏捷开发，就是要开发出出色的软件，解决最终用户的问题，让世界更美好。
关于作者
Angela Martin在新西兰惠灵顿的Victoria大学完成了自己的博士论文《客户在极限编程项目中的职责》。本文基于她的论文完成。她目前是新西兰汉密尔顿Waikato大学的讲师。她也在英国的牛津大学教授软件工程系列科目中的敏捷方法课程。她有14年行业经验，包括敏捷教练的经历，并曾担任两年敏捷联盟董事会成员。
注1：我们引用了访谈中受访者的一些原话，以展示我们的发现；为体现匿名性，真实姓名已经隐去。
创建完整团队的艺术：敏捷如何改变我们与客户的工作方式相关推荐
- 【学习笔记】《如何构建敏捷项目管理团队》第四章 改变自己的风格
改变自己的风格 团队在不同的发展阶段有不同的特点.作为一个指导团队发展的敏捷教练要识别出团队当前所处阶段,采用针对性的指导风格. 团队的发展阶段 武术学习有三个阶段:守.破.离. 守:服从规则,从一招 ...
- 你的团队推行「敏捷」遇到多少坑？来看团队敏捷转型之旅必经12阶段
作者:史蒂夫丹宁.新书"敏捷时代"由HarperCollins于2018年出版.与世界各地的组织就领导力,创新,管理和商业叙述进行磋商.在世界银行工作,包括知识管理主任(1996- ...
- Leangoo_多团队，大规模敏捷开发实现过程
通过敏捷看板来实现需求.迭代(支持燃尽图)和缺陷管理:此类型项目提供了单团队敏捷开发和大规模敏捷模板,适用于Scrum敏捷项目管理及产品研发. 本场景描述的是针对多个Scrum团队/敏捷团队,开发同一 ...
- 用Leangoo项目管理工具怎么做多团队大规模Scrum敏捷开发？
概述 本场景描述的是针对多个Scrum团队/敏捷团队,开发同一款大型产品,或者大型项目的敏捷应用场景.Leangoo多团队大规模敏捷开发模板是基于大规模敏捷模型定义的,可以适配基于Scrum of S ...
- 团队如何实施敏捷开发以及Scrum电子看板工具
概述 本场景描述的是针对10以下小型产品研发团队或小型项目的敏捷应用场景.Leangoo单团队敏捷开发项目模板是基于Scrum模型定义的,所以这里所说的单团队是指只有一个Scrum团队的场景. Scr ...
- 七步教你从0到1创建客户服务团队
建立客户服务团队就像安装书架一样, 每个书架各有不同,安装方式也各不相同,但是有一些可以借鉴的"说明书",如果没有计划与策略支持,可能会导致方向上的错误.无论你是从头开始创建用户服 ...
- 如何把团队拉回到敏捷正轨︱瑞友科技项目群经理徐天岗
北京瑞友科技股份有限公司工业互联网项目群经理徐天岗受邀为由PMO评论主办的2022首届中国敏捷大会(线上会议)演讲嘉宾,演讲议题为:如何把团队拉回到敏捷正轨.大会将于12月17-18日通过云端面向全国 ...
- 敏捷转型——团队如何变敏捷？
敏捷的原则倾向于一些常识和一系列艰苦的工作,通常,我们会听到很多关于敏捷的信息,比如敏捷转型是团队尝试成为敏捷的一种流行方式.很多团队会聘请敏捷顾问,花几个月的时间帮助团队进行敏捷转型,这个过程只需要 ...
- mysql2005备份_创建完整数据库备份 - SQL Server | Microsoft Docs
完整数据库备份Create a Full Database Backup 09/12/2019 本文内容 适用于:Applies to: SQL ServerSQL Server(所有支持的版本)SQ ...
最新文章
- 查询表中的所有字段名
- Linux学习笔记（一）：常用命令（2）
- 通过FxCop来验证.NET编码规范
- Http协议中的方法
- CDH Kerberos 认证下Kafka 消费方式
- 8.使用Exists监控ZNode的三大Change事件
- (转载)equals与==
- java数据库查询类
- java私塾设计模式_Java私塾：研磨设计模式 之 访问者模式（Visitor）
- 协同过滤推荐算法详解
- 谷歌浏览器xp32位_如何正确的配置系统的浏览器系列篇（五）——合同管理系统...
- 百度与谷歌地图坐标转换
- 入侵mssql2000
- JavaScript 和 Macromedia Flash 之间的通信示例
- date类型在日期增加或者减少几天
- You should consider either expiring and/or testing connection validity before use in your applicat
- Encoded password does not look like bcrypt
- Font Awesome所有图标
- ubuntu16.04 安装拼音输入法
- 数据集收集-包含《COVID-19》，《英国在线零售业务》，《电商行业用户行为分析数据集》，《电商婴儿用户》，《亚马逊手机》等17个数据集，用于数据分析挖掘，kaggle比赛练习