敏捷项目执行

敏捷项目执行

作者/Jonathan Rasmusson

{%}

我将带你们到幕后看看,学习敏捷项目是如何利用迭代来搞定之前的美好愿景,为客户提供能够使用的可运行的软件。其中,你会看到一个典型的敏捷迭代是如何发挥作用的,以及敏捷团队是如何使用各种会议和同步点来推动项目向前发展的。

每周都交付一些有价值的东西

规划好项目计划之后,接下来就应该考虑怎样才能将只有简单几句话的索引卡转化为生产就绪和可运行的软件?

首先,你没时间把所有东西都记下来。你需要一种轻型而准确的分析方式,在必要时能完全地满足需求。

其次,开发实践必须要坚如磐石。我们没时间不断回头修改问题代码,问题要消灭在萌芽状态。这就要求随着工作的进行,就有设计好、测试好并且完全集成的代码。

再次,测试必须要与开发步调一致。你不能等到项目结束时再检查是否一切正常,从项目一开始就必须保证系统的健康与完整。

{%}

如果做到上述三点,或许每周可以生产出一些有价值的东西来。但我们还可以利用一种强大且规序分明的方法——敏捷迭代。

敏捷迭代

也许此刻,你的头脑中有了一个很好的敏捷迭代形象。这里有必要再次声明,敏捷迭代就是在限定的时间内(一到两周),选取首要的用户故事,将其转化为可运行的软件。

{%}

它就好比完成敏捷项目的发动机。我们的目标就是曲柄每转动一次,就可以生产出一些有价值的东西。这也就是说,不管怎样都要在一次迭代中生产出可运行的、测试过的软件。

迭代也可以让我们在必要时进行调整。如果优先级有所变化或者现实情况出乎预料,可以在每次迭代的结尾进行调整。一般不会在迭代中间改变故事(因为这样团队会受到很大干扰)。但是如果真有需要,还是有机会重新调整的。

{%}

讨论就到此为止。检查迭代如何运行的最佳方式就是用实践进行验证。现在来选取一个用户故事,看一看要将其转化为生产就绪且可运行的软件都需付出什么努力。

寻求帮助

来人啊!BigCo的建筑项目已经开始一个月了,我们的好朋友凯利先生需要有一个网站,可以让他的承包商登录,制作建筑安全工作许可证。

{%}

很显然,不可能用一次迭代就将整个网站建好,但是如果能在接下去两周内交付如下两个故事,凯利先生会非常满意。

{%}

为此,所有的用户故事都要经历三个步骤才能转化为可运行的软件。

(1)分析和设计(为开工做准备)。

(2)开发(做工作)。

(3)测试(检查工作)。

现在,我们要进一步审视和观察这些步骤所涉及的内容。

第一步:分析和设计——为开工做准备

敏捷分析有两个关键概念:适量和适时。适量分析就是不管付出什么样的代价都要为开工做好准备,既不用多,也不能少。

{%}

小型、集中办公并有现场客户的团队不会太依赖于正式的文档。通常,一张卡片和一番交流(辅以少许精挑细选的示意图和图画)就足够了。

中等规模团队会稍微有些分散(但相互之间的距离仍可以步行到达),要求会稍微多一些。带有简短的描述、任务分解和测试标准列表的单页可能更适合他们。

{%}

很明显,如果一个大型项目的团队分布于芝加哥、伦敦和新加坡,所需的东西会更多一些,这样才能确保大家沿着正确的方向前进并保持一致。

有一点很重要:对于敏捷分析来说,没有衡量细节统一的正确标准。只有针对你和项目来说正确的东西。

如有必要,可以在后期不断加码,但背负任何额外负担都会降低速度。因此,轻装上阵,只在必要时加码。

所以,敏捷分析的另一个关键就是要适时。

{%}

适时分析就是要在刚好需要用户故事时(通常是在迭代之前)对其进行深入分析。

我们无法得知从现在起一个月后这个世界会是什么样子。事情总会发生变化。因此,如果只顾闷头向前冲,并且企图将一切事情都提前安排好,通常最终都会引发巨大的浪费。相反,你要hold住,坚持到最后时刻,就在你正好需要时再做深入的分析。

这样做可以确保:

  • 分析时所用的信息是最新、最好的;

  • 你与客户让你自己有了一个边工作边学习和创新的机会;

  • 避免了大量的重复工作。

如果所从事的工作确实很复杂,需要更多的准备时间,那就多预留一些。不管付出多大的代价都要为开工做好准备。只是不能提前准备太久,否则时过境迁,你最终还得将其舍弃。

那么,对于“创建工作许可证”这样的故事来说,我们应该怎样进行分析呢?

嗯,对于启动项目来说,一个优秀的流程图再好不过了。

{%}

流程图之所以很强大,原因就在于它们能通过一种简单而可视的方式展示出系统的工作方式以及人们所需要经历的步骤。人们还可以对其进行注解,从处理流程的角度来展示需要捕捉的东西。

这时,你可以通过角色模型,洞察并理解谁是系统用户以及他们想要做些什么。

{%}

角色模型是对软件使用者的不同角色进行的一种简单描述或印象,能为系统带来一些性格特征。他们是真实的人物,面临真实的问题,了解这些角色会极有助于解决他们的问题。

然后,当进入实质设计时,我们就可以“随心所欲”了!不要拘泥于你想出的首个设计,我们可以用廉价的纸上原型来将许多不同的设计和选项进行快速原型化。

{%}

从理论上来讲,将团队聚在一起并在纸上演练合作会有很多益处,三个臭皮匠总会赛过一个诸葛亮嘛!

一旦设计完成,就可以与客户共同写下一些测试标准,这时你能非常清楚地了解到这个用户故事成功后会是什么样子。

{%}

此时可以向客户提出问题:“我们怎样才能知道这个东西能运行了呢?”

你可以按照自己的意愿,对细节或多或少进行检查。起点可以设置得高一些,但团队要明白哪些主要功能块必须运行才能确保故事成功。

或者,如果故事本来技术性就很强,并拥有很多的业务规则和细节,你可能就得花费更多时间,并要将它记录下来(如果你能以某种自动化测试的形式将其收集起来,那就更好了)。

结对编程怎么样

很少能有敏捷/XP(极限编程)实践比结对编程更加引发人们的注意和争议。

结对编程就是两个程序员坐在同一台电脑前,合力解决同一故事。

任何经理见到两位宝贵的“资源”坐在一台电脑面前都会感到紧张,这可以理解。他们会认为团队的生产率被减半了,而如果程序员只是在敲字,那可能就真是这样了。

但事实并非如此。一次好灵感或者创意可以省却团队巨大的工作量以及后期的返工。通过结对编程,你可以将宝贵的知识和实践在团队内散播开来,尽早发现bug,而让两个人对代码进行逐行检查也可以提高编码质量。

当然,这不适合所有的人,因此你要尊重每个人的工作方式。但如果你的团队喜欢结对编程(这也适用于分析和测试),那么这种做法就会带来超值的回报。

有没有其他可供我们分析使用的工具和技巧呢?当然有了!你可以选择大家所熟知的故事板、并发图、进程图、线框图以及所有其他有用的分析和用户经验技巧。

记住!谁也不会去学校学习如何做这项工作。要有创造性。绝对正确的方式是不存在的。

哦耶!如果你不知道怎样打印故事,那证明我们还不需要它。通过浏览器来打印许可证对于第一个发布来说就足够好了,因此我们可以不予考虑。我们不会浪费任何用于分析的宝贵时间。

搞定分析后,现在要准备开工了。

第二步:开发

现在拿出适时分析,将其转化为下面的金块(对我们来说就是,生产就绪的、可运行的软件)。

{%}

生产就绪的软件像金子一般并不能唾手可得,它需要我们努力工作,训练有素,技术出众。

例如,在敏捷项目中,需要完成如下这些任务。

  • 编写自动化测试。

  • 不断地演进并提高我们的设计。

  • 持续集成代码,生产可运行的软件。

  • 确保我们的代码符合客户谈论系统时使用的语言。

我们没时间或精力将所有的优秀软件工程实践都涉足一遍,需要涉足的是那些被我称之为“没得商量”的东西(要是没有这些东西,你会发疯的)。

不过就目前而言,你得明白,如果没有幕后那些核心软件工程实践的支持,任何敏捷奇迹都是无法实现的。

所以,现在让我们来看一下项目中迭代的特殊案例——首个迭代(也被称作第0个迭代)。

使用第0个迭代启动项目

第0个迭代就是你的首个迭代,或者说是实际开工前的迭代,你怎么说都行。总之,就是有关设置的。

如果项目进行到了一半,我们通常都是在做完分析后才开始深入开展基于已知故事的工作。但是如果一个新项目刚刚启动,我们则会希望将一些事情在开工前就理顺。我们将这个开始阶段称为第0个迭代。

{%}

第0个迭代阶段要让各方井井有条。这也就是说,我们要启动一些东西,比如说版本控制、创建自动化构建,以及使开发和测试(如有可能,还包括生产)环境有效运转,这样才能有针对性地去部署。

如果你实在想炫耀一番,可以再做一下接下来故事的基础版本(相对完整又可检验架构的事情)。

一旦开发工作完成,目标几乎就实现了。这时剩下的就只是检查工作了。

第三步:检查工作

如果完成了所有的主要任务,却没能乘胜追击使一切正常运转,这会相当尴尬。检查工作就是要保证我们的工作符合要求,同时又能从客户那里得到一些反馈。

集体代码所有权

在敏捷项目中,代码的所有权不属于任何人,它属于团队。也就是说,为了完成工作,任何人在任何时候都可以做出任何必要的改变。

XP将此称为集体代码所有权, 敏捷项目会以这种方式来促进交流,达成一致的架构,并改进代码库的编码标准。

{%}

根据测试标准逐项检验的同时为客户演示软件,让他们看到软件是可以运行的。如果能让客户亲自运行演示软件,而你坐在旁边观察他们如何使用软件,效果就更好了。

我知道你现在正想什么。如果一个敏捷项目始终贯穿有测试,那么在将软件投入到生产环境时,是否还需要一个正式的用户验收测试(UAT)呢?

作为一个敏捷开发者(开发团队的任何人),你的目标就是要使UAT变得可有可无。这就是说,测试工作要完成得非常漂亮,并且在交付的过程中能不断地从客户那里获得反馈,这样一来最后做UAT时,人们才很难从系统挑出一点儿错误。

很少有团队能在第一次就达到这么高的质量(多数团队压根就没做到过)。除非你能让自己和项目发起人相信,你们团队的软件质量很高,根本用不着正式且成熟的UAT,否则,我建议你还是要保留它。

{%}

绝对的!有一种敏捷方法更适用于运营型/支持型的工作。人们将这种敏捷方法称为看板。

看板

看板是一种由丰田公司开发的、基于卡片的信号系统,目的是协调装配生产线上的零件补给。它与我们的故事板很类似,但有几个关键的区别。

{%}

首先,在看板中,工作受制于一个概念:在制品(WIP)。团队每次只能处理一定数量的工作。

如果不允许追踪bug怎么办

设想一下如果情况不允许追踪项目中的bug,那又该如何变通处理呢?

首先,由于无法再追踪bug,所以必须要对它们进行即时处理。

其次,你要用一种快速且廉价的回归测试来确保彻底消除bug,保证它们不会死灰复燃。

再次,如果出现了太多的bug,应该把速度降下来,找出问题的症结所在,然后采取措施将其修复。

要在团队中鼓励这种态度和行为。这与使用何种bug追踪系统没有关系,只要考虑一下该如何编写软件,避免过度依赖bug追踪器。

比如,如果团队一次只能处理4件事情,那么他们的WIP就变成了4。任何其他需要完成的事情都要暂且放一放,然后按优先级对它们排序,只有轮到它们时团队才开始处理。

另一点区别就是看板无需迭代。当团队做好准备后,人们只需从清单中依次拿出最重要的事情,就能牵引工作不断进展。

看板的目标是 “流动”。通过每次只处理几项工作,让看板内的事项尽快地流动起来。下面是这种工作方式的一些优势。

  • 无需对迭代担忧

    如果你既要做运营型工作,又要做项目工作,那就不必再担心在一次迭代中受到干扰了,因为根本就不存在迭代。你只需在做好准备后继续下一项目,无需重新设置迭代期望值。

  • 不用局限于只完成单个迭代内的任务

    通常将大块头拆散是个不错的主意,但有时有些任务就是非常大,需要几周时间才能处理完。那就别拆了吧。

  • 这种方式对管理期望值非常不错

    多数团队仍会做某种形式的估算,或者起码要根据相对规模,对其看板的任务进行估算(当你要接手某项任务,想要对其设置某种类型的期望值时,建议你这么做)。

但看板还是有其特定的简洁性。这就好比在说:“嗨,哥们儿!我们干得正带劲儿呢。我们会给你想要的东西,但是我们每次只能处理四件事。”不需要说点数,也无需对估算进行解释,就像日常生活中一样,每次只能处理这么多。

前面我们已在用了很多篇幅来讨论迭代有如何强大,所以上述论调听起来多少会有些疯狂,但别在意。

敏捷迭代威力巨大,如果你正在做基于项目的工作,但又受到时间和资金这些条件的限制,在当今时兴年度预算的工业化世界中,迭代是一种正确之选。

但敏捷不止是迭代。敏捷意味着只要对你有效,任何方式都可以。因此,如果没有迭代会更好,那就不用迭代。看板非常适合于运营型/支持型的团队,他们反应要迅速,无法采用固定长度的迭代。

我的建议还是要坚持固定长度的迭代。如果只是刚开始做基于项目的工作,你一定会从每周必须定期向客户交付可运行软件的严谨作风中获益良多。

如果你正在做运营型的工作,可以试一下看板。原理都是一样的,只是执行的方式会有稍许差异。

想要了解看板的最新动态,查看下面这个网址:http://finance.groups.yahoo.com/group/kanbandev/messages

现在准备好与大师的会话吧。

{%}

学生:大师,我正在做一个数据仓库项目,并负责为高层提供财务报告。因为仅是数据仓库就至少需要一个月才能建立起来,我们不可能每周都生产出一些有价值的东西。我该如何管理迭代?

大师:交付有价值东西的窍门就是要注意那些贯穿于应用内的小型功能块。无需建立整体的数据仓库,只要从报告中拿出一小部分,构建需要的基础设施块就行。

学生:但是,如果我们这样做了,仍然遇到某些大块头,无法将它放到一个迭代中,我们应当怎么办?

大师:如果没法放入,那就不必强求放入一个迭代。根据需要来选用多次迭代来开发这个基础设施,再继续前行。记住你需要客户的参与。如果需要张罗这一切的时候,你消失3个月,这会让客户兴致全无。如果能找到某种方式逐步交付,依次迭代,那么你和客户无疑都能好过得多。

学生:谢谢您,大师。我再仔细考虑考虑。

现在已有了分析、开发和测试,把所有这些部分综合起来就可以每周交付一些有价值的东西。但方法不止一个,你的工作产出和方法要根据项目的不同有所变化。因此,要勇于试验,尝试不同的做法。

创建敏捷沟通计划

除了建议团队要集中办公并定期向客户交付可运行的软件外,敏捷在如何组织迭代工作方面并没给出太多的指导。因此,如何进行组织、沟通、接受反馈并将这些东西糅合在一起,完全由你和团队来定。

任何敏捷项目都要做两件事:设置期望值、获取反馈。

一定要持续设置期望值,因为事情总是在变化。你应该养成这样一种习惯:定期与客户见面,时常检查项目状态。

因为将可运行的软件交到客户手中这种简单的行为都会引发需求的改变,所以你会希望能有一个强有力的反馈链,保证正中靶心。

为此,如果想掌握一些迭代中的规则和套路,就要完成下面四项工作。

  • 确保下一迭代工作准备就绪(故事计划会议)

  • 从上一迭代故事中得到反馈(展示活动)

  • 制定下一迭代的工作安排(迭代计划会议)

  • 不断找出需要改进的部分(小型回顾)

我们先看一看如何确保下次迭代的工作准备就绪。

故事计划会议

{%}

这就是适时分析检查点会议。在SPM期间,我们将与客户一起对接下来的用户故事的测试标准进行检查,与开发者一起对估算进行检查,从总体上来保证已经完成了下一批次迭代故事的准备工作。

你肯定会出错——别担心

我曾经从事一个建筑项目的打印故事工作,采取斯巴达勇士之方式(交付基础部分)。演示的时候,我立刻就发现客户对演示内容不怎么感冒。

他们不好意思说什么,但我能感觉得到,我也知道我做得还不够好。

当时我只能强作镇定,请求再试一下。他们答应了。

如果没有之前的七周内果断交付,他们可能就不会这么给面子了。如果客户见到你为他们每周都在辛苦劳作,他们会谅解你,偶尔没做好时,他们也会放你一马。

因此,不要害怕尝试。尝试、失败和主动出击都是“游戏”的一部分。

有时你会发现故事比预想的要大一些。这没什么,只需将它拆散,使其适合于一个单独迭代就可以了,然后更新计划后继续工作。不过所幸事物都有两面性(我们发现有些故事也会比预想的小一些)。

在正式的敏捷方法中是不存在SPM的。我和其他一些人都发现SPM这种机制可以用来规避浪费(这种浪费是由于未对故事进行分析就开始迭代)。

但这就是敏捷的魅力所在。完成任务的方式不止一种。如果你需要某种实践,那就创建这些实践,或者自己动手实现你的实践(不管别的作者或别的书上怎么说)。

在每次的迭代过程中,你还要做另外一件事就是从客户那里得到反馈。

展示活动

{%}

成功了!你交付了一些有价值的东西。你知道吗?有很多项目进行了几周、几个月有时甚至几年,都没有交付出任何有价值的东西来!

借此展示活动机会,你可以向全世界炫耀你和团队所从事的伟大工作,并从客户那里得到一些非常中肯的反馈。

在展示活动中,你与整个团队要展示上一次迭代完成的故事。这就是说要将部署在测试服务器上的实际代码展示出来,而并不是什么漂亮图片或者美好愿景。这个东西要在真正需要时立即投入战斗并部署好。它应该是成品。

展示活动肯定会相当好玩,能够很好地揭示我们上一次迭代的工作。狂欢吧!带上一些点心和糖果,开始炫耀吧!获取反馈。让客户来运行演示软件,然后观察他们使用软件的情况。

现在我们看一看连Scrum和XP这样的敏捷方法都极力推荐的一种会议——迭代计划会议(IPM)。

计划下一次迭代

{%}

所谓IPM就是与你的客户一起为下次迭代的工作做计划。你要检查团队的速率,检查接下来的故事,然后共同确定出你和团队在下一次迭代中所承诺完成的工作量。

借IPM时机,也可以对项目做一次小型体检。

{%}

在此,你可以快速地预报一下项目的进展情况。如果需要些什么或者希望讨论一下某个特别棘手的问题,你可以借此机会提出问题,并提供选择方案,然后拿出处理意见。

如果要讨论日期,可以使用燃尽图。这种方式非常可靠,不带任何感情色彩,它可以让你和客户了解实际进展应当是什么样子。

{%}

如何给出建设性反馈

给出反馈的方式有两种。你可以直接而客观地提出来。

  • “苏茜,我发现你在上次迭代中的打印模块做得很不错,但是你的单元测试确实还欠火候。”

或者也可以嘴巴甜一些:

  • “苏茜,打印模块做得真不错。如果你的单元测试也能有这样的水平,你将很快成为超一流的选手。”

看到差异了吗?去掉“但是”这个词,语调完全变了,但信息同样传递了出去。

这并不是说你要为所有东西都包上一件糖衣。但有时信息的改变确实可以促使行为产生极大的改变。

想要全面了解如何进行有效的沟通,可以读一下戴尔·卡耐基的经典著作《人性的弱点》。

这是敏捷看得见的部分。我们对客户和利益相关方要尽最大可能坦诚相待。要让他们尽早了解坏消息,这也是敏捷方式。

在任何迭代完成前,最后要做的都是扪心自问:是否还可以做得更好?

如何主持小型回顾活动

我们当然可以在主要发布结束或者项目接近尾声时,将回顾活动搞成大型的全天候活动。但这并非是我要讨论的内容。

这里指的回顾是一种快捷而集中的讨论,时间限定在10~15分钟之内。讨论期间,你和团队要定期聚在一起,探讨哪些地方做得不错,哪些地方还需改进。

主持一个优秀回顾活动的首要准则就是要让大家有安全感。如果你认为在这方面还有问题,那就拿出回顾活动基本指导原则,提醒大家注意。

回顾活动基本指导原则

不管发现了什么,我们都理解并坚信:每个人对自己的工作都已全力以赴,都充分考虑了当时的情况,施展了自己的技能,调动了可用的资源。

换句话说,回顾活动不是政治迫害。

然后你可以提出第一个问题来暖场。

(1)我们在哪些方面做得确实不错?

“吉米,你的单元测试搞得的确不错。”

“苏茜,你创建的风格指南和对样式表的重构做得真棒,我们很容易就使应用程序保持了观感的一致性。”

对那些理应受到赞誉的人来说,公布其优秀行为并给予表扬会让其更加动力十足,并能鼓励更多的此类行为。

另一方面就是要讨论哪些方面需要提升。

(2)我们怎样才能做得更好?

“大家在上一批次的故事中还有很多的bug。我们可以慢一些,把事情做得更严实一些,但要保证能进行足够的单元测试。”

“我们发现代码库中有很多的重复。后续工作中记得要花些时间对代码进行重构。”

“我彻底搞砸了那个打印故事。对不起。让我在这次迭代中再试一把,我保证下一版会好很多。”

不管怎样,举行一场回顾活动并与团队成员分享思想都是很不错的,这可以让团队关注有待提高的领域。然后你可以为下几次迭代创建一个主题,对希望改进的领域加以强调和追踪。

对于主持回顾活动的确切指导,可以参考《敏捷回顾:使团队更强大》。

好东西!最后,我们来学习如何快速地让大家每天都可以从一开始就密切合作——召开日常站立会议。

如何召开日常站立会议

{%}

日常站立会议说的是要与你的团队迅速分享重要信息。有了这种会议,我们还需要其他会议干嘛?会议的时长在5到10分钟之间,无需座椅(这就能提醒人们发言要尽量简短),成员简要说一下自己最新的工作内容,把其他团队成员需要了解的东西分享一下。

目前,多数敏捷教材都会告诉你,进行日常站立会议时,大家要站成一圈,每个人都汇报以下几项内容。

  • 昨天做了些什么。

  • 今天要做什么。

  • 工作中有哪些障碍。

这种报告虽然不错,但就是不太让人受启发,也改变不了大家的行为。

相反,应当每天早上将团队召集在一起,然后告诉大家——

  • 你昨天为改变现状做了些什么。

  • 你今天打算如何将其完成。

  • 你打算如何清除那些挡在前进道路上的障碍。

回答这类问题会完全改变站立会议的态势。以前你只是站在那儿介绍一些近况,现在是在向全世界宣布你的意图。

这样会带来两种结果:或者你能跟进并完成交付,或者你不能。而这完全取决于你自己。

但我可以告诉你:如果每天你都到场,公开向同事们承诺自己将在这一天做些什么,那么你搞定工作的几率也会大增。

怎么有效怎么来

假如你不清楚是需要单独开会还是合起来只开一个会,请不用担心,一切都由你自己来定。

为了尽量减少会议的数量,有些团队喜欢将展示活动、下一次迭代计划会议和回顾活动都综合为一个会议,时间控制在一个小时(我就喜欢这样,所以我把这几项都列在一个IPM里了)。

还有些人则喜欢将计划与展示活动区别开来,而把回顾活动当做周五的一种乐事。

也有的团队与客户的关系非常好,因此他们也无需专门的故事计划会议(SPM)。每天都会讨论,只要有必要,他们马上就召开一次设计会议。

记住,这样做的方法不止一个。如果某样东西不能增加价值,就要丢掉它。要多番尝试,才能确定它是否对你有效。

但要保证在迭代期间抽出时间,站在客户面前,展示一些可运行的软件,设置期望值,并寻求改进的方式。

喔!看起来大师想要检验一下你是否理解了这些东西。我们最好赶紧到柔道学校一试身手,看一看这些东西是否管用。祝你好运!

{%}

同学,欢迎回来。我已备好了几个生动的迭代场景用来检验一下你的潜质。在回答问题前,请仔细阅读。

场景一:不完整的故事

大师:在某一天的IPM期间,有一个故事很明显只完成了一半。为了显示进展,年轻的项目经理希望将半个故事点计入其迭代的团队速率,然后当故事在下一迭代中完成时再计入另一半。这主意可行吗?

学生:嗯,如果故事真的只完成了一半,将这半个故事计入迭代速率并将另一半留待下次迭代处理,我觉得也没什么不好,毕竟它还能精确地反映出故事的实际状态嘛。

大师:是这样吗?那么请回答下列问题:如果车子只剩下一个轮子,农夫能用它来运输粮食吗?人可以用一只筷子吃饭吗?客户能用不完整的功能进行生产吗?

学生:不能吧!?先生。

大师:对于敏捷武士来说,没有什么只完成1/2、3/4或者4/5的用户故事。要么是完整的,要么就是缺损的。因此,敏捷武士只会将经过完全测试的完整故事计入其团队速率。任何不完整的故事都要留待下次迭代解决。

场景二:日常站立会议意义不大

大师:曾经有一个团队在让其成员参加日常站立会议时遇到了麻烦。团队成员认为会议并没有什么意义,并且必要时他们可以一边工作一边互相讨论。这时团队应当怎样做?

学生:团队的领导应提醒大家步调一致的重要性,以及日常站立会议在此过程中所起的重要作用。

大师:是的。团队可以审核日常站立会议的目标,以及为什么会产生日常站立会议。但是,如果即使这样团队成员仍然觉得会议没什么必要,我们应当怎么办?

学生:我没明白,大师。将大家每天都迅速地召集在一起,并且让每个人都加紧项目工作,怎么还可能会被认为是浪费时间呢?

大师:尽管站立会议有这样那样的好处,但它也不是唯一的方法。如果团队是集中式办公,规模较小,并且一天到晚无论是彼此之间还是与客户都配合紧密,那就不太需要召开日常站立会议了。

学生:您的意思是有些团队并不需要日常站立会议?

大师:我是说团队应当保留那些有价值的实践。如果没有价值,他们就应该修改或者干脆抛弃它。

场景三:不能产生任何价值的迭代

大师:曾经有一个团队在进行完一个迭代后没有交付任何有价值的东西。此次失败他们完全是咎由自取。他们没能计划好,开始的时间也晚了,并且大家都比较懒散。他们知道这对交付来说是不利的,所以决定取消对客户的展示。这是明智之举吗?

学生:虽然我个人感觉团队应当对其不能交付任何有价值的东西承担后果,但我认为如果他们没有什么东西可以展示,取消展示活动也是可以接受的。不过我觉得他们最好能向客户陈以实情。

大师:啊哈……你现在变得聪明了。不能交付任何有价值的东西这种现象时有发生,但通常都不是团队有意为之或者缺乏努力。团队如何才能纠正此类懒惰行为?

学生:大师,您的意思是他们还应保留演示活动? 即使没有什么有价值的东西可以演示,也得面对客户?

大师:哈!有时羞臊感的刺激会成为最好的老师。面对客户而没什么可以展示会使人无地自容,团队绝不会再想经历第二次。

学生:谢谢您,大师。我会再认真考虑考虑。

不要妄想规避项目中的不愉快经历。它们有时会成为你最好的老师。要承认错误,分享你从他人那里学到的东西,继续前进。

 

{%}

《敏捷武士:看敏捷高手交付卓越软件》是一本贴近实战的指导书,将敏捷的思想与原则贯穿在如何交付卓越软件的讲解中,旨在向读者展示如何玩转敏捷项目,内容涉及软件开发过程中的诸多要素,如客户、需求、沟通、计划、估算、协作、团队等。

本书适合所有对敏捷感兴趣的软件从业人员。