2.4 敏捷实施法则13条

定义最佳实践需要先明确环境,即明确什么样的组织在什么流程下如何有纪律地交付后,讨论“最佳”或者“误区”才有意义。下面基于IBM的实践和经验教训来分享敏捷实施的13条经验。

1.及时清理产品工作清单

当团队持续更新产品的工作清单(product backlog)时,产品负责人和团队负责人需要密切关注列表项目中高优先级的工作,并使其比重始终处于一个健康的范围(1:10~1:3)。在迭代计划阶段,需要审阅产品列表,并根据经验和承受能力调整产品清单数量。

根据收集到的需求、用户的最新反馈和经验知识,我们可能决定把一些对当前版本没有附加价值的用户故事从产品清单中删掉。或者,有些用户故事经过重新审阅,尽管对当前版本有意义,但因为不那么紧急,产品负责人仍然可以将这些故事和任务的优先级降低。

产品清单不应该成为一个储藏间,将所有可能会穿但又不想现在尝试的新旧衣服全部堆进去。当产品负责人将一个优先级不高的故事放进产品列表时,必须有充足的理由。

其实,产品清单中用户故事的数量将与这个敏捷团队的生产能力、承受能力密切相关。累赘的产品清单会对团队积极性产生负面影响,进而压抑生产力。当工作趋于轻松、团队趋于稳定时,产品负责人可以加入几个新的用户故事;但当团队的需求产生了比较大的变化、团队工作节奏紧张时,产品列表最好仅仅保留一两个月的工作量,而且,请果断地将不适合留下的工作项从产品列表里删掉,如果它真的是个好故事,你一定会在其他场合再次听到,到时候再把它放回来吧。

2.迭代规划会议不宜超过1小时

IBM有很多组织迭代计划会议的方式。有些团队会每个迭代组织一次独立的会议,一次性规划好所有迭代任务;还有些团队会每周组织一次会议,或者随时需要随时会晤,清理产品列表并制定迭代计划。后者的优势是让团队经过每周的必经日程,很快养成适宜的工作节奏,减少因调整用户故事大小、细分任务所带来的不可避免的打扰。

规划会议的时长不宜太长,人往往只有40~60分钟的关注度,所以,应该给每次规划会议一个时间限制,保障团队对规划事宜的专注。Scrum的先驱者之一Peter Deemer有一个普遍的建议,就是团队使用5%~10%的迭代长度来设定迭代规划时间。例如,周期为一个月的迭代规划会议长度加起来不要超过1天。

IBM在柏林的STG(System Technology Group)团队每个迭代只会晤一次,用来决策迭代规划:“我们每两个星期有一次规划会议,这样使得规划会议的时间比较短。我们的审查和规划会议在隔周周一举行。在周三之前,有一个可以称为“设计”的会议,但是它不是真正的设计会议。我们聚在一起,打碎用户故事,架构师也会参加这次会议,但他们并不总是参与迭代规划会议。”

HongXue Han,一位杰出的IBM STG的研发工程师,也提及了有关规划和“设计”的会议:“在我们的工作环境中,团队负责人与产品负责人将决策要在迭代中实现什么目标,以及要做哪些工作。然后,他们会召集团队开上一个设计会议,产品负责人将向团队介绍他们想要做的内容。这个设计会议只是为了产出一个高阶设计,旨在了解研发阶段可能的外在依赖和技术风险。当团队知道要做的是什么后,团队会坐在一起讨论迭代规划。”

然而,不是所有的团队都有一个独立的会议来确定迭代计划和调整产品任务列表。事实上,我们是否需要坐在一起讨论迭代规划取决于是否有新的任务和项目将要放入或取出产品任务列表。显然,倘若计划被频繁更改,产品负责人经常召集团队参与会议将会严重影响团队的生产力。

3.迭代规划会议只做该做的

迭代规划会议的目的是让团队思考在下一个迭代里完成什么工作以及怎样完成这项工作,并达成一个共识。整个团队需要为迭代规划,并为之做准备。这需要我们重新梳理当前的产品清单,了解整个团队的工作效率,并整理在迭代之前收集的信息。在IBM,迭代规划会议由两个连续的会议组成,在第一个会议里,团队决定要做什么,包括:

·讨论产品愿景。

·讨论并确定哪些用户故事在清单列表里具有最高优先级。

·确定哪些用户故事需要在这个迭代里面完成。

·确定迭代的目标。

在另外一个会议里,整个团队要决定怎样完成这些工作,包括:

·设计工作途径。

·细分和估计期待完成的工作项(细分粒度要适当)。

·同每个成员确认能够完成的工作任务。

·提交到迭代任务列表。

事实上,团队成员的地理位置分布以及团队规模都会对迭代计划产生影响。IBM的项目规划中,因为全部成员通常不在一个时区,两个会议也并不是紧接着进行的。而对于规模较大的团队来说,IBM的迭代规划也是不一样的。因为有更多的成员来开发产品,我们必须考虑到团队之间的依赖,而且应该比规模小且集中的团队有更多的迭代。规模较大的团队应该促进小组之间的深度合作,以及特殊技术方面的交流和共享。产品负责人,甚至产品负责人团队需要在不同小组的产品清单之间协调优先级。只有这样,小组之间才能配合起来,到迭代结束时,团队才能交付一个可以发布的且稳定的产品。

为了有效地完成这个重要会议,IBM的团队在迭代规划之前都会收集和了解如下信息:

·产品负责人应该有一个需求(用户故事)列表,并且按优先级由高到低排序。这个列表会放在团队可以访问的数据库或者“产品清单”的最前面,供整个团队使用。

·理想情况下,用户故事会有一个基本的行文格式:“作为一位……,我需要做……,因为……”,经过迭代规划会议讨论用户故事的内容以及它们在交付时能够被用户或者利益关系人接受的条件。整个团队必须充分理解用户故事。

·用户故事应该有一个相对准确的工作量估计,如果需要,还应该把用户故事工作量拆解成适合在这个迭代内完成的量,再进入迭代会议进行讨论。

充分的准备是平稳、成功的迭代规划会议的基础,能避免令人沮丧且漫长的会议活动。但是,如果不幸失去了上面这些提前准备的要素,也并不意味着世界末日的到来,只是会使规划会议的时间变得更长,而且会给大家增加更多的挑战。

4.团队在迭代规划中的自我管理

所有成员必须在一起探讨并承诺能够完成的工作,确定团队的工作任务,以及怎样一起完成这些工作。仅仅由一些代表来承诺团队的工作是不合理的。所有成员都应该自己提交各自能够承诺的那部分工作规划。

对于规模较大的团队,确保每一个对工作有责任感的成员都能参加迭代规划会议是很重要的。无论在不在同一地区,当下最重要的就是团队自己能够获得认领工作的全部权利和责任,当团队成员认同并承诺了这部分任务后,就意味着团队要对这项任务负责。

IBM确实有一些实际的例子,不同时区的小组或许会选择一些代表来参加迭代规划会议,但整个小组都需要参加迭代规划。假设有3个组,每个组有9个组员,从一个一般产品的最高优先级的任务列表清单里选取任务。开始,这3个组委任代表在迭代规划会议上提供了最初的工作估计,然后,代表回去和组内成员讨论这些任务是否合理,并确定是否需要修改。所以对于这次迭代规划会议,确实27个小组成员都参与其中了。

对于一些独立的组,每个组还应该遵从各自的迭代规划会议。

5.不同时区组的迭代规划会议

不同时区的组需要找一个整个组都能参加的时间来进行迭代计划(Sprint Planning)。对于不同时区的组,有时候工作时间是没有重叠的,因此,有一些组员就需要在他们的正常工作时间外来参加这个会议。

开启一个Scrum项目后,通过一个大家都能访问的计划工具可以帮助不同时区的同事沟通。每一个参加迭代计划会议的人都可以看到产品清单、用户故事、迭代任务清单和工作量的估计。另外,通过访问这个分布式的工具,不同时区的组还希望有一个桌面共享工具。一般我们还可以指定一个同事每次记录下组内的讨论或者达成的共识,并且更新到计划工具里。

6.与远程团队的会议

当团队人数超过10人时,我们的每日站立会议就会显得很熬人,一人一分钟陈述,即使不被打断,时间就已经近15分钟。所以,我们提出了采用“Scrum of Scrum”的方式组织会议,即每7~9人组成一个Scrum团队,每个团队再选取1~2名代表参加高阶的Scrum会议。

IBM的研发项目中,超过100人的团队非常之多,尤其是分布式环境下,某一地区可能集中了属于某Scrum团队的20名成员,而Scrum会议的形式基本是全团队参与。

位于分布式环境下的大型团队,让来自世界各地的团队成员参与一个会议,尤其是当不同地区之间没有相互交叠的工作时间时,绝非易事,况且,团队还需要接受文化差异、语言障碍带来的挑战。当很多不同国家、地区的同事参与到项目中来,我们要面对的一个大挑战就是寻找一个最佳的会晤时间,并期望这个会议时间是大多数同事愿意的、或者可能愿意的。

分布式会议需要远程会议设备,这种会议的效果通常远不如面对面的会议,因为除了耳朵以外,还需要眼睛、肢体参与沟通。事实上,有几条分布式团队的电话会议实践经验可以分享:

·至少提前2天发出会议邀请,如果没有会议系统,那么会议时间的格式最好有完整的年、月、日、时、分等。因为,2014年1月7日,在美国是1/7/14,在日本是14/1/7,而在西班牙是7/1/14。所以,如果时间戳是“1/7”,那么将会误导与会者。并且,还要在会议前30~120分钟发出会议提醒,提醒大家会议将准点进行。

·提前5分钟拨打电话会议,这样不会因为你的拨入打断正在进行中的讨论,也会有足够的时间处理可能出现的技术故障。

·在“Yes/No”之后,跟随一个完整的陈述/否定句来表达正确的用意。实际上,许多国家对于“Yes”和“No”有不同的理解。例如,你的问题是:“你不希望开发这个功能,是吗?”如果答案真实,且的确不希望开发,那么,通常美国人的回答会是“No,I don’t.”而我们中国人会说:“是,我不希望”。所以,在“Yes/No”后面要跟随一个完整的称述/否定句来清晰表达你的意愿。

·让语言尽量简单,不要使用过长或俚语、成语等丰富的句子。当我们用非母语沟通时,一定不希望对方使用俚语或者某个电视剧上的笑话来活跃气氛。

·给每个人一个表达机会。在会议中,那些外向的同事常常积极发言,迫切成为中心人物;而内向的同事似乎非常适合做总结,我们应该安排这些同事在最后发言。

·如果几个人在一个会议室,使用一台电话拨打进入电话会议,那么,请在他人讲话的时候避免交头接耳。在必须沟通的时候,也请对准话筒,大声说出他的名字,就像他也在电话另一头样,这样做会让所有与会的人感到被尊重。而在无需发言的时候,尽量将自己的电话静音。

·当你没有听清楚,或者觉得有必要澄清时,请尽可能地提出来:“我的电话出现了些噪音/我的电话网络应该出了问题,能请您重复一遍刚刚提出的观点吗?”

·使用协同工具,分享开发文件,使用对话机制将某一话题的探讨用文字表达出来。事实上,越是分布式、远程对话的团队,文档和文字的沟通越为重要。

7.处理工作间的依赖关系

开发团队成员需要寻找合理的方式最小化产品列表中用户故事的相互依赖。一个完整的、优秀的用户故事是独立的,无需任何依赖。在复杂领域和分布式团队项目中,去除依赖性更为重要。如果团队在工作上彼此有了依赖性,就很可能需要一些额外时间和精力来协调不同团队的配合。如果处理不当,还很可能因为彼此工作任务的依赖性导致其中一个团队不能够完成计划任务,或工作遇到障碍。

IBM建议将依赖性划分成三类问题来处理(见图2-12):

00131.jpeg

图2-12 三类依赖性问题

·简单依赖。

·外部依赖。

·复合依赖。

简单依赖关系即一个用户故事依赖于另外一个能够独立的用户故事。消除这种单向依赖关系的一种方法是合并或拆分用户故事,使之成为新的用户故事集。如果这么做是不可能的,替代方案是为独立的用户故事设置比依赖于它的用户故事更高的优先级。那么团队将在迭代早期解决独立的用户故事,之后再解决相关的用户故事。

外部依赖关系即一个用户故事依赖于外界团队的工作。在这种情况下,团队需要协商整合和交付日期,并调整该用户故事的优先级。负责该用户故事的小组不应该在外界团队还未完成其交付的前提下,承诺在当下迭代内完成这个用户故事。在特殊情况下,受依赖影响的团队可以安排虚构的接口,模拟外部组件的数据、数据通信或者Web服务,但这是有风险的。因为系统在真正的外部组件整合进来之前,是潜在不可交付的。外部依赖关系的例子包括:接口、数据馈送和Web服务。另外,在处理外部依赖关系的工作时,团队往往需要在迭代规划前考察和评估外部团队完成工作的能力与时长,这将对我们的迭代规划产生影响。

交织在一起的相互依赖关系即两个或多个用户故事是相互依存的,每个用户故事都不可以独善其身完成而不依靠其他故事的推进。理想的情况下,团队应该想办法打破所有的依赖连接或寻找方法把交织在一起的依赖关系转化为简单依赖关系。实际上,IBM的项目中,产品负责人和团队负责人还有架构负责人肩负了分解复杂依赖关系的责任。

8.有效的团队协作

没有人能独奏交响乐,它需要整个乐团的合作。

——H.E.Luccock

在大规模分布式的企业环境中,对于团队来讲,尽早交付有商业价值的解决方案是极为显著的变化之一。以前,开发团队的成员需要几个月的时间才能完成最后的交付;而现在,他们每两周就要交付出可运行的软件。

产品经理转变为产品负责人,他们每天都要积极地协调利益关系人与开发团队之间的沟通与工作,从而完成每个迭代周期的有价值的软件交付。开发团队、产品负责人、团队负责人以及其他的利益关系人要在整个开发过程中一起认真地考虑产品的商业价值,而不是仅仅在项目的开始和结束。

以前,经理可能会容忍阻碍项目进展的问题持续几天甚至几周的时间;而现在,在每两周的软件交付周期中,这种现象不可能再出现。因为团队负责人和产品负责人提出的问题往往要求他们在24小时之内解决。

所有这些显著的变化促使团队交付的软件可以满足利益关系人最小化失败风险的需求,这个过程也对团队高效协作提出了更高标准。

IBM团队总结出3种非常有价值的实践方法,可促进在迭代周期中的分布式协作,并帮助团队按时完成任务:持续集成(Continuous Integration),自动化测试(Test Automation)和代码审核开发(Code-Review Development)。下一章将会分享一个主人公的故事,通过这个故事详细介绍这3种实践方法,以及它们如何帮助分布式团队快速定位、分析和解决问题,如何提高团队成员之间的协作和效率。

9.用文档克服距离

很少、甚至没有重合工作时间的分布式团队可能需要更多的邮件和其他书面文档来保持成员之间的有效沟通。IBM的团队经验告诉我们,文档能使团队更快达成一致并保持共识。

当团队会议中某一种语言不是所有成员的母语时,书面语言也许是更加可靠和精准的沟通方式。非母语发言人更容易理解的是书面语言,这也是为什么我们应在口头讨论中加入一些文本沟通方式作为补充,如聊天工具或文档。

很多团队会使用在线聊天工具或者屏幕共享工具来记录、分享会议的讨论要点。这不仅能保留讨论内容,也有助于非母语成员更好地理解和掌握要点。随着会议的深入,团队负责人应该以文本方式记录下所有要点,并试着问自己:

·我是否精确地记录了大家关心的问题?

·我是否精准地掌握了大家将要做的事情?

10.使用合适的工具

Scrum更加重视个人、人与人的协作,而不是流程和工具。尽管工具可以帮助团队完成任务,但它不能创建一个高效的团队。在分布式环境中,虽然工具和有效的实践方法可以帮助团队成员更有效地沟通,但更重要的是要确保引入的工具可以帮助大家完成必须的工作。

比如,一个分布式团队正考虑在日常迭代会议中引入分布式协作工具,首先要评估工具带来的价值与花费的合理性。使用虚拟会议室进行日常Scrum会议虽然看起来很酷,但如果进入会议室都要花上几分钟,那么它也就没有什么使用价值。因为,通常的日常Scrum会议只有15分钟左右。一个简单的电话会议就足以解决问题,为什么还要寻求那么昂贵的方式呢?

所以,设计一种最合适团队协作的敏捷开发工具,需要从活动价值出发,以人为本地进行工作效率改进,将价值作为灵魂,将方法框架融入工具,延展工具的功能,特别是提供定制和扩展的空间,使得工具既能够满足当下工作的需求,保障团队的敏捷性,又可以整合敏捷研发全生命周期中各个有价值的活动交付过程,充分体现项目开发的透明度。

总之,关注的重点应在DAD的核心原则上,千万不要因为拥有工具而一定要使用它们。

11.重视团队精神

所有的团队成员,包括产品负责人、利益关系人,通过协作共同交付一个产品或解决方案。每一个团队都应该是一个完整的多功能团队。这些团队应该分别工作在尽可能多的、各自独立的产品功能点上,而不是产品的组件上。从而可以最小化依赖关系以避免开发进程拖延的风险。

在一个全球化分布式开发环境中,由于沟通的延迟,团队成员无法在同一时间段工作,容易出现状况。这使得大家不得不更加努力地工作以防止出现“我们”与“他们”的观点,造成不必要的分歧。为此,可以尝试问自己一些问题:

·你是否联系过在不同国家、不同时区的同事?

·你是否尝试过通过电话交流,而不仅仅依赖延迟的邮件?

·假如你是一个相对集中分布的小组中的一员,而整个团队还包含一些分布在其他地区的成员,你是否尝试过邀请这些“边缘”成员加入到即将举行的临时会议中?

·在你决议要缺席某一天的会议时,你是否提前给其他组员提供了有用的最新信息呢?

·由于时区的问题,你是否让在另一个时区工作的同事总是留到很晚?

·休息时候的临时讨论,团队的其他成员是否参与进来了?

·你采取何种措施来验证团队成员是否如预期地掌握了交流中的要点?

·当谈及到在不同地区的团队成员时,在语言上,是否有使用“其他国家的团队”或者“其他团队”等词汇的习惯呢?

·是否给团队成员贴过标签(如“在罗马的成员经常迟到”或者“他们从来都没做对过”)?

·是否不同地区组员之间的依赖关系过于紧密,以至于每天交流过于频繁?

12.缩短迭代周期

如果利益关系人不断地催促团队并经常打断团队工作,一个比较好的解决办法是缩短迭代周期。在一个周期为4周的迭代中,利益关系人需要平均等待2周,团队才能完成他们的需求(如果这个需求优先级足够高的话)。而在一个周期为2周的迭代中,利益关系人平均只需要等待1周的时间。

沟通方面的不同步可能会致使分布式团队需要一个稍长的迭代周期。这显然降低了工作效率。而较短的开发周期可以使团队成员把每一次的交流沟通都当成紧要事情处理。

开发周期越短,团队就有越多机会改进整个开发流程,并迅速适应。较短的开发周期同样意味着当利益关系人增加新的需求时,团队完成任务所需的时间更少。

总之,较短的迭代周期不仅能使团队更迅捷的响应利益关系人、产品负责人的需求,还能使团队更迅速地适应变化。

团队应该尽量找到符合自身的迭代周期。当周期过长时,会妨碍讨论新的高优先级任务;当周期过短时,除了成员间的任务说明之外几乎做不了其他事情。选择时最好考虑不产生需求变化的最长时间,即能够保护团队迭代工作不被打扰的时间。

13.思而不学则殆

有些敏捷理论犹如风筝一般,表面高大上,实际却脱离实际,难以自圆其说。因为没有足够支撑其理论的经验和实践,这种会议、课程、咨询活动常常会陷入彼此争论的苦战,浪费了大量时间。记得常有朋友抱怨一些“教练式”的培训,培训师的思想“高度”远远超出了企业、团队能够接受的水平,痛斥组织之臃肿腐败、抨击人性之不古,内容理想有余,但不接地气。一段时间下来,咨询、培训都无法顺利进行。于是,培训师就开始指责和推诿,认为接受培训或咨询的人员素质不高,领导支持也远远不足,所以只能做成现在这个样子……

其实,很多培训师掌握了“足够”的敏捷知识,但是,敏捷培训师更要具备多年的实践经验,不仅做过敏捷开发、测试、业务分析、需求设计、团队管理等,最好也做过传统的研发和管理工作,厚积而薄发才是培训师的根本。而对于希望成为培训师的朋友而言,即使目前没有这么多的经历,至少要在一线技术岗位奋战过,拥有一定的知识并通过不断的学习和实践来累积经验。

关于知识和经验,心理学认为,人的大脑不善于对二者进行区分。换句话说,读书、学习是非常好的事情,但是如果我们没有经历过,学习也未必会有成效,甚至会因为学习阻碍了我们的成长。

举个例子,假设我们在阅读一本书,并且从书中获得了知识。之后,当我们看另外一本书时,虽然文笔不同,但是内容几乎相同,于是我们会这样说:“这些我明白,在另一本书里,谁谁说过……”甚至还会说:“这本书写的什么嘛,不怎么样啊,其实我告诉你是这样的……”无论是否亲身经历过,可能都会有这种反应,这恐怕就是大脑制造的麻烦。我们通过阅读、学习获得了知识,但是却使我们失去了成长的机会,听起来真是讽刺。读书太多,知识和经验的平衡就将被打破(见图2-13)。因此,有一种智慧会要求我们通过增长经验或者输出知识,即“倒空”的方式来重新建立平衡。正如罗曼·罗兰在《约翰·克利斯朵夫》写道:“我们从小到现在被各种谎言灌满了,当他成熟起来的第一个标志就是他要呕吐,重新用理性去认识世界。”

00070.jpeg

图2-13 知识和经验的失衡

对于敏捷培训师而言,在知识和经验失衡的情况下,培训者的感受恐怕就会像上面那个朋友抱怨的一样了,最终,也只是浪费了公司的时间和金钱。