敏捷教练培养的“守、破、离”

敏捷转型是一个长期的任务,需要一个教练的角色,要关注和推动持续改进。

其实我们每个咨询顾问本身也是一个敏捷教练。我想从自己的成长和近些年的一些指导经验,给大家一些启发。

nqu8ubgmadim5tktxcn1

敏捷教练的定义

首先看看什么是教练。 WiKI上的解释是’who supports a learner in achieving a specific personal or professional goal’

古文:“师者,传道授业解惑者也。”

套用到敏捷教练『通过传达敏捷精神,教授敏捷实践,帮助组织或团队扩大产品业务价值』

为了能达到教练的目标,教练应该具备以下主要能力:积极的客户引导能力,严密的逻辑思维能力,清晰的语言沟通能力。

  • 客户引导能力:团队就是客户,虽然是教练,但是教练的目标是自组织团队,如果过分教授,团队的自组织的能力会变得很慢,有时候甚至会越来越被动。教练更应该采用的方式是引导的方式,通过问问题,实例分析,通过教授学习方法和思维方式,激发团队成员的积极性,来组成团队逐步成为自组织团队。
  • 逻辑思维能力:不同的团队会遇到不同的问题,教练需要不断的思考,举一反三,把以前工作的经验结合当前的问题,再有就是结合敏捷的核心价值观,能够给出经得起推敲的回答。说的不好听一点,没有正确答案,只有逻辑清晰,令人信服的答案。
  • 语言沟通能力:教练最根本的目标是让团队理解,团队进步,不是为了吵架争个输赢。这样就需要具备一些最基本的沟通能力,总结能力,语言表达,演讲等能力。

从教练需要具备的能力来看,敏捷教练需要具备的两个维度的能力,一个是基于敏捷价值观和体系的敏捷知识;另外一半主要是转型,教练,演讲,演讲等软技能。而“实践”又是敏捷价值观的来源,接下来就谈谈教练如何通过“守、破、离”来成长的。

武术中照着姿势做,学毛笔字临摹字帖,学古文背诵范文,其实都是找了个model,先要照着做。

“三人行必有我师焉”。要学人所长,不一定只选择一个导师,而是要是学习导师的擅长领域。从我的成长经历中,也是这样做的,刚开始当项目经理的时候,我把项目群经理的邮件都整理在一个文件夹里,每次给客户发信,都要找出相类似的邮件,照着写。刚开始当内部教练的时候,每次主持会议的时候,就会想想外部教练是如何做的。找个导师的另一个好处是,帮你解惑,当你遇到问题的时候,对方的一句点拨,会比你自己想几天都管用。

没有最好,只有更适合,一定要找适应你自己风格的导师。原来木桶理论希望我们去补短板,现在时代变了,更希望每个人发挥我们的长处,没必要去找个不适合自己风格的导师。但是换另一句话说,即使不适合的导师,只不过稍微痛苦一些,需要调整的比较大。在这个阶段关键是照着做,通过实践来体会背后的价值。

对于教练的要求是,必须找个导师,必须模仿着导师做,但是导师可以自己选。对于团队,如果选择一种敏捷实践,开始的时候要严格遵守实践的准则。

在这个阶段就是要广泛实践,尝试解决不同的问题,遇到问题自己要先思考,尝试举一反三,发现新问题的解决方式。

从我的成长经验来说,这个阶段非常重要,很幸运的是,当时作为敏捷教练,整个产品线有10个团队,在开始转型的半年内,有了充分的实践机会,目前我咨询的大部分经验都是来自那个时期自己的实践经验。有利有弊,当初我个人是没有外部咨询师长期驻场的,在自己摸索的半年中,曾两次想辞职放弃。这个阶段最重要的是实践和坚持,通过PDCA的方法,不断尝试,总结,调整。对于这个阶段的教练,应该是充分去尝试,思考,改进。只有在充分思考,实践后,再去尝试问你的导师,否则会对外部有很强的依赖性。

对于教练的要求是,按照PDCA的方式,短周期反馈,要亲身体会敏捷的思想。最好是每周总结上周的实施内容,然后作出调整制定这周的实践计划。

如果真正到了这个阶段,应该是处理任何事情,都不会超出所信仰的理论,这里就是指做实践都不违背敏捷宣言的价值观。

这里介绍一下怎样到达这个状态,有丰富的经验以后,再通过阅读,思考,总结等任何方式,把理论体系化。

想要到达这个阶段,教练应该已经具备一些培养别人的经验了,那么自己更应该身体力行的去实践自己的理论。我个人形成自己体系的方式是通过大量的阅读,毕竟自己遇到的场景还是不够,通过阅读别人的案例,来思考到底应该怎样解决,不断验证自己的体系。

这个阶段,教练应该已经具备自我成长的能力,自己应该找到合适的方法。这里只是给大家一些建议作参考,多读书,多读论文,同时也要多总结,实时验证自己的体系。

最后,想强调的一点,敏捷不是只能运用到团队项目中,可以运用到个人成长,甚至家庭中的,大家一定要充分实践,既然信服它,就要身体力行的去执行他。

Share

敏捷宣言到底有几句?

“Hi,A同学,敏捷宣言有几句?”

“4句呀,分别是个体和互动…”

如果你的答案和A同学一样,也认为是4句,那么请你继续往下读,相信此文章会对你有所帮助;

如果你的答案和A同学不一样,认为不是4句或者不知道,那么可以选择性阅读,它不一定会对你有所帮助:)

为什么写此文

当我还是一名敏捷实践的试行者,接触到的第一个信息就是敏捷宣言(非4句),虽然不能完全领悟,但当时的教练让我把它熟记于心,说这个就是敏捷。我想:我终于知道敏捷了;

当我还是敏捷教练时,向大家介绍敏捷,询问都有谁知道敏捷宣言的时候,有部分同学举手,他们的答案和A同学一样。我想:有的喷了;

现在我是敏捷咨询师,接触到了一些企业内部的敏捷实践者,问他们同样的问题,他们的答案也和A同学一样。我想:你该请我们做咨询了;

就在前不久,我听了一些敏捷培训,讲师提到敏捷宣言的时候,竟然都介绍的也只是4句敏捷宣言,之后我饶有兴趣的百度了下“敏捷宣言”的关键字,也询问了周围的敏捷实践者,得到的答复是敏捷宣言就是4句呀,大家都知道的…我忽然意识到此事的严重性。我想:该写篇文章了。

宣言到底有几句

让我们来看一下原版的敏捷宣言。以下是官方的翻译:

敏捷软件开发宣言

我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人。由此我们建立了如下价值观:

个体和互动 高于 流程和工具

工作的软件 高于 详尽的文档

客户合作 高于 合同谈判

响应变化 高于 遵循计划

也就是说,尽管右项有其价值,我们更重视左项的价值。

数一数有几句?6句。此文并不想纠结于数字,你也许会说敏捷宣言中有4句价值观,这似乎也没错,但问题是你了解其余2句吗?敏捷宣言流传至今,我们心中似乎只记住了那4句,其余的2句被我们天然的屏蔽了,甚至我们还一直在做“敏捷宣言只有4句”这样的知识传递!难道那两句不重要吗?答案肯定是否定的(不重要为什么要写在宣言里…),两句的偏差带给我们的是敏捷转型方向上的错误。让我们来看一下这两句告诉我们了些什么。

我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人。由此我们建立了如下价值观。

通过这句我们了解到敏捷宣言是通过不断实践总结出的价值观。价值观不是具体详细的目标及实践,它是在我们心里的一种根深蒂固的思维取向,它会影响我们做出的每一件事情。所以有团队会说,我们现在已经敏捷了,因为我们做了迭代开发,这种单纯的实践=敏捷是不成立的,我们需要多维度的去了解团队的价值观是否符合敏捷的价值观。

虽然右项也具有价值,但我们认为左项具有更大的价值。

这句是敏捷宣言里最重要的一句话。如果你丢了第一句,说宣言有5句,这个还可以原谅。但如果你丢了这一句,那绝对是个错误!在做敏捷转型的过程中常遇到这样的现象:“敏捷说了不需要文档,太好了,我们以后就不用写文档了”,“敏捷说了不需要计划,我为什么要给你计划”,这样实施的后果可想而知,这样的案例比比皆是,这就是敏捷转型方向上的错误。

为什么会有这样的错误呢?原因就是忽视了宣言中的最后一句话。宣言的价值观中英文用了“over”中文翻译是“高于”,A高于B,多数人的理解就是A比B好,那么为了敏捷转型我们就只用A舍弃B,这似乎是字面上的正常的理解,但这不是宣言中要表达的意思。想必当初17位大牛早已预见了这样问题,他们用最后这句强调,给大家正确的引导。告诉大家宣言中的价值观不能理解为取A舍B这样的二分。敏捷的价值观是承认右项是有价值的,不过我们要更重视左项的价值,这不是二分!当初软件开发在不断发展的过程中,大家越来越的重视右项的价值,这时敏捷站了出来,提出在这个过程中我们要更加重视左项的价值,它并不是让我们要放弃右项实施左项。

在我们实际做敏捷转型的过程中,左右两项通常情况下也是共存的,不过我们更重视左项。例如你在帮一个团队在做敏捷转型,你发现产品把需求都录入系统中,告诉大家他的任务已经完成,之后研发按照系统中录入的需求进行研发,期间他们无任何沟通。这时你应该做的是加强他们之间的互动,例如让产品给研发对着系统的需求讲一遍,研发在过程中发现问题立刻和产品沟通,不过度的依赖系统中的描述等,你不能认为宣言里说了互动比工具更重要,就让他们停止使用系统只靠互动,这样团队会“手忙脚乱”,就算团队勉强坚持下来了(且不说效果好坏),最后你会发现数据统计的工作如果没有工具,对团队来说就是一场噩梦。这样的例子还有很多。

总结

作为敏捷实践者、教练、甚至咨询师。敏捷宣言作为基础,我们不能“断章取义”的只记住那4句,甚至还在做只有4句这样的知识传递,我们需要把敏捷宣言中的6句话都“掰开了揉碎了”去理解清晰,尤其是最后一句,来给自己给别人树立正确的敏捷价值观。所以敏捷宣言到底有几句?6句,一句都不能少!

最后我想到了两句话:“天才就是99%的汗水+1%的灵感”和“知识就是力量”,这两句作为的名言警句被流传至今,但如果你只记住了这两句,恐怕无法正确的理解爱迪生及培根当时想表达的意思,因为它们都有后半句:)

ps:感谢我刚接触敏捷时候的教练,他对我正确的引导。他曾也是一名ThoughtWorks的咨询师。

Share

敏捷实践中的利益相关者管理

利益相关者理论诞生于1984年。在认识到不仅投资者可能影响到成功的同时,此理论主张持续沟通更广泛的受众 – 即企业的利益相关者。自那以后,该理论在各行业广为接受,这其中也包括了IT项目的实践者们。它有助于加强客户关系,维持健康的项目环境,以培养更为满意的交付产物。

为了进一步说明,我们将以其在一个专业服务自动化(PSA)项目中的应用举例。该目标组织是一家提供定制化的技术解决方案的全球机构。它拥有超过三千名技术顾问,工作于数百个客户项目;很多项目是分散式团队,其成员可能分布在多个不同的时区。是时的战略是以保持业务可持续发展为目标实现财务的自动化。但问题同时被揭示 – 如何于如此复杂的用户群体中开展企业变革?本文希望就此问题进行解答。

利益相关者在哪?

首先,我们需要知道应该包括哪些人。尽管网络上陈数了很多方法,我们采用了全新的方式,即是将利益相关者理论与敏捷实践相结合,揭示出项目的利害关系人。敏捷方法中的用户头像能够帮助识别潜在的用户以及他们如何与系统进行交互;进而将类似交互或行为的用户进行分组。

系统用户和他们身边的人可以很容易地干预到项目进程。通过绘制业务价值链和沿着它与用户的每次交互的背后关联的人员。遵循这个流程,我们能够同时识别我们的用户Personae与项目利益相关者。

pasted image 0

他们相同吗?

答案可能不是一个简单’不’,但他们为什么又是如何不同于彼此呢?非常流行的利益相关者矩阵建议从兴趣(Interest)和影响(Influence)两方面进行分析。在敏捷项目中,我们可以进一步分析更细致的因素。在我们的示例中,我们认为当用户更频繁地与我们的系统进行交互,以及当他们愈加依赖系统才能完成自己的任务时,他们会表现出对项目成果更强的兴趣。另一方面,每个用户组的人数,和他们与其他各种用户的沟通数量,可以帮助理解影响的层面。然后,将我们在PSA项目中识别出的利益相关者进一步归结如下:

pastedImage_10

有了这样的认识,我们就可以将辨识出的利益相关绘制入矩阵:

pasted image 0 (1)

依优先排序沟通

就像我们在迭代计划时对故事卡进行优先排序一样,为了更好地利用有限的时间和资源,利益相关者相关的活动也要排优先级。幸运的是,在提供以上全面附图的同时,利益相关者矩阵也对沟通方式也提供了指导。

核心成员 Key Player

同时具备高兴趣和高影响力的利益相关者往往与系统的目标用户有所重叠。他们常需要及时和详细的信息共享,因为有很高的几率,他们的兴趣直接来自系统的使用情况。在PSA项目中,各大区的财务和CP团队是这个小组的主要成员。系统提供自动化开票功能于他们的工作内容有很大益助。他们不仅关心系统在出票当日是否可用,而且包括用户路径是否简单易用。

为了确保核心成员对项目的支持和联盟,与他们保持强有力的工作关系甚至邀请他们参与到大多数的开发流程中来显得尤为重要。财务和CP用户被邀请与开发团队紧密合作,参与最初的产品设计,并对新功能于上线部署前提供反馈,以提高产品性能对用户的契合。

随时沟通 Keep Infomred

项目的指导委员会(Steering Committee)的成员 – 如金融赞助商和运营领袖 – 通常归于这一部分。他们可能对项目的日常表现出较低的兴趣,但常具备更改基础假设和用户路径的强大影响力,进而使项目目标转变。

这些利益相关者往往倾向于接收汇总信息,并可以包括了客观和主观观点的讨论。在我们每两周一次的指导会议中,常对里程碑事件的进展和宏观发展方向进行讨论;最终用户的整体体验,也几乎每次都会被谈及。运营领袖往往能对产品地图和区域性功能的优先级平衡提出深入的指导意见。

值得注意的是,此类成员通常比较忙,所以关键是要建立共同的期望并尽力减少惊奇(surprise)。与他们安排会议,提前预约很重要;或者,我们可以申请他们建立代表小组,以提升沟通效率。建议约定定期的代表会议,同时提前对指导内容和升级讨论的级别达成共识。

保持满意 Keep Satisfied

表现出高度兴趣,却有较低影响力的成员,很可能是项目某项功能的受益者。此类型中个人的“声音”可能较弱,难以影响产品设计或优先级。因此要保护他们的利益可能需要一些有着重性的措施。

在我们的案例中,庞大的顾问角色群体属于这一部分。它由3000多名分布在全球6大洲的30多个城市的员工构成。他们各人的角色,资历,文化背景,以及当地商业惯例,都促使他们对系统的功能要求产生成百上千的分支。为了听到需求背后的故事,我们邀请志愿者加入到用户咨询委员会,并精心选拔了可以充分体现上述不同条件的代表团。我们共享虚拟板来收集意见,并在每月开线上会议进一步讨论。这个实践有效地改善了采集和交换广大用户意见,也有助于让用户代表们自由商议功能开发的优先顺序。

该用户咨询委员会也会受邀测试产品原型并提出早期的反馈,他们的建议也经常会被采用到之后的正式版本中。并且,当我们最终推行版本上线时,这些“超级用户”大多为产品在各自办公室推行给予了培训和宣传方面的大力支持。

观察 Monitor

低兴趣和较小影响力的人们常在项目沟通中给予较低优先级。在我们的例子里,这里可能包含了相关职能者,如人力资源和销售用户。他们没有与目标系统的直接交互,而是把关键数据通过系统集成的方式间接影响到我们的系统中的数据完整性。就此,我们也通过被集成系统的维护团队进行间接接触。这样在资源共享的同时也可以将风险降到最小化。

变化的因素

敏捷宣言主张通过及时重新定义产品路线图的方式响应变化。这些个重新定义的过程也常常会导致利益相关者的兴趣和影响力水平的转变,所以我们的沟通策略也应该进行相应的调整。

pasted image 0 (2)

在我们的PSA产品推出几个月后,CP角色对发票的制作产生障碍,进而从该用户组中被剥离出来。由于他们新的用户旅程并不要求他们登录到系统,而可以只通过检查电子邮件数据完成,他们对项目的兴趣也开始大幅下降。作为回应,我们也开始减少与他们的沟通频率。这个调整随后被证明更加有利于设计师和分析师,使他们在之后的工作中可以专注于唯一的核心用户群,大幅提高了改进此用户旅程的效率,由此避免了运营中的实质性业务损失。

结语

为确保敏捷开发项目的顺利进行,利益相关者管理至关重要。他们可以通过用户画像被轻松辨识出来,并不需要额外的努力。通过分析他们的兴趣和影响力,我们可以在不同层次,以他们容易接受的方式进行引导 – 有些需要沟通目标而另一些需要我们帮助解决更细致的问题。正如在敏捷项目中我们经常需要修正的产品地图一样,利益相关者策略也需要考虑到环境变化因素,这样才能持续巩固他们对项目的赞助与合作关系。

Share

孙子兵法的智慧——拯救死亡行军

entersunzi

我们看了太多失败的和即将失败的项目,在软件领域更是如此。每天早上醒来在朋友圈里看到半夜更新的,不是身在国外的朋友,就是在办公室为了项目上线而加班的朋友。

Edward Yourdon为那种项目约束与目标之间相差一倍以上的软件项目专门写了一本书,叫《死亡行军(Death march)》。

我曾经亲眼见证过几个“死亡行军”项目的立项过程。

其中一个项目,那时候我才工作不久,一个项目从无到有,“大领导”希望在21天之后上线,这个日期包含了周六和周日。但是按我们的预估——当然我们也不会盲目乐观到每天只工作8小时,这个项目按现有资源起码需要3个月到4个月。在产品立项过程中,“大领导”坚决不肯让步,时间、范围均压得死死的。就这样,我们在会议室里博弈了整整两天,最后的结果是我忧心忡忡地走出会议室,问我身边的同事:你觉得咱们能办到吗?同事的表情我至今印象深刻,那是一种释然和轻松——他笑着说:怎么可能嘛。

最后的结果,项目延期了半年。


如何能够让自己的项目稳定运行并得到期望的结果呢,避免死亡行军,打一场胜仗呢?

几千年前的孙子兵法已经给我们提供了思路:

故知胜有五:知可以战与不可以战者胜,识众寡之用者胜,上下同欲者胜,以虞待不虞者胜,将能而君不御者胜。

我们只做高价值的事情

价值驱动作为敏捷开发的两根支柱之一,为软件开发提供了一种全新的思路。在上世纪八十年代之前,软件开发的时候还有这样的等式:功能=价值。
所以奇怪的一幕出现了:软件开发这个行业一边承受着巨大的进度压力,一边在生产着没有人用的功能。

微软曾经发起office 2003用户调查,希望调查用户希望 Office 2007实现哪些新特性,结果收获了让人吃惊的消息。产品总经理 Takeshi Numoto 如是说:“超过90%的特性请求早已存在于 Office 中可供使用”。

更何况对于所有的软件开发组织来讲,资源不足都是常态,识别出来哪些可以不做,我们才知道应该去做什么。

知可以战与不可以战者胜。

通过限制在制品的方式来缩短前置时间

对于缩短产品交付周期,一向是很多客户都会提到的问题,特别是电信级的产品,动辄一年的交付周期。当前市场环境已经变得越来越快,根据波士顿咨询公司的调查,最近的20年已经成为变化最剧烈的20年。

22484-8eb1d728c83ca707

《经典战略工具过时了?BCG矩阵新解》

在这样的市场环境下,“响应速度”就被提到越来越高的位置上,而衡量响应速度最直接的指标就是“前置时间”(lead time)。一个需求从产生到变为现实,究竟可以有多短?

利特尔法则是一个神奇的公式,它简单到甚至可以被10岁的孩子所理解:平均吞吐率=在制品数量/平均前置时间。对于一般的组织来讲,平均吞吐率约等于团队的产能,把它视作常量的话,我们想得到更短的平均前置时间,就需要控制在制品数量,小批量地快速流动。

要么不做,要么快完。

识众寡之用者胜。

团队所有人目标一致

“我们所处的项目,目标是什么?”有没有保证项目有着一个清晰而具体的目标?有没有保证所有成员都能够理解并执行?

在客户现场的时候,我经常听到的问题是:“作为一个管理者,我如何能够准确看到员工的人员利用率?你有没有办法让团队里所有的人都忙起来?”每听到一次这个问题,我在心里就会默念:“你可以让闲着的人都出去跑圈啊,这样大家都忙起来了。”

软件开发的项目,绝大多数(保守了,其实可以说“所有”)的目标都不是“所有人都忙起来”,而是“快速交付价值”。也就是说我们做任何的努力,都是为了能够让需求尽快上线。

而敏捷开发中的各种可视化手段,包括故事墙、故事地图,都起到了这样的作用——目标可视化。特别是树立在团队中间的物理看板,我们真正的目标都清晰地挂在上面,所有人的工作和努力,都是在推动着一张张卡片从板子的左边挪向右边,如果你做的事情对于推动卡片没有起到直接或者间接的作用,那就要好好思考一下了:我们的目标究竟是什么?

至于说人员利用率——谁知道一个正在端着咖啡面对窗外发呆的知识工作者(译作Thought Worker)是不是在为接下来消灭更多卡片而在布局呢?

上下同欲者胜。

做好风险管理

在客户现场待了一年,看的项目虽然不多,但也发现了一些共通的问题,其中最大的一个就是风险管理。

有不少项目在前期根本就没有做风险识别,或者识别的风险缺乏跟踪,到项目执行中仍然会像放炮仗一样一个接一个的爆炸。其实风险管理作为PMBOK九大知识领域之一,管理和应对手段都很成熟了。

应对的思路就有“转移、接受、缓解、消除”四种,而我看到的情况通常都以“接受”为应对手段,赌这个风险不会发生,或者等一个Risk变成了Issue再去想应对方案。

风险识别不论是在需求优先级排序还是在架构设计上都是非常重要的一环,我们之所以把高价值、高风险的需求视作第一优先级,是因为我们希望尽早识别风险,尽早释放风险。我们提的“简单设计”简单到什么程度,也是由是否能够涵盖最大的风险作为边界的。

以虞待不虞者胜。

团队应当自组织,领导者应当负起管理者的责任

客户现场另外经常被提及的问题就是:“如何打造自组织团队?”“团队自组织了,我们经理怎么办?”

我的答案通常是:团队自组织应当是一个逐步打造的过程,而领导者更应该负起管理者的责任。《管理3.0》中提到,授权有七个级别:从不信任到信任,或者说团队成熟度从低到高分别是:告知→贩卖→咨询→商定→建议→征询→委托。

作为管理者,打造自组织团队的过程也是逐步团队赋能的过程,团队成熟度不高而采取放任的做法,对于自组织的打造百害而无一利,反之亦然。所以作为管理者,最重要的责任就是在对团队赋能,当上面的四条团队都掌握了玩法,管理者就可以采取更高层次的授权了。

而所谓自由,就是团队的事务管理者不要管,团队外的事务管理者尽量多去做。区分管理者水平高低的点就在于如何判断一件事属于团队“内”还是“外”。

将能而君不御者胜。

我们总结一下

故知胜有五:知可以战与不可以战者胜,识众寡之用者胜,上下同欲者胜,以虞待不虞者胜,将能而君不御者胜。

 

Share

我怎么看敏捷

去年11月份的时候,我进到了ThoughWorks实习,开始了我的TW生涯,从现在除去今年年初由于毕业论文断断续续的10天左右的请假,我已经到ThoughtWorks1年了,现在我想来我聊聊我眼中的敏捷和我对敏捷的看法。它是比较主观的看法。
首先,我必须得说敏捷并不是完美无缺的,当然也不是所有行业,所有软件项目都适合使用敏捷来开发和管理的。很明显的一个例子就是,你不能用敏捷来开发NASA的航天飞机的软件系统。从敏捷的理念我们会说,我们让开发航天飞机的起飞系统,然后交付给NASA使用,之后再继续交付降落等其他系统,显示这是行不通的,航天飞机不能在仅仅拥有起飞功能的时候就上天啊。敏捷里强调快速交付,快速响应,及时修复bug,因此我们会允许软件存在潜在少量bug的时候让其上线,使用。这在航天飞行系统里面也是行不通的,因为涉及到人的生命,航天飞行系统应该是不允许任何bug的。

但我依然会说,敏捷是一种很好的理念和实践,适合大部分IT企业使用,特别是互联网企业和运行互联网产品的企业使用。

在现在互联网时代,天下武功唯快不破。采用敏捷的实践,初期开发MVP(Minimal Valuable Product)产品,快速上线,根据用户的反馈不断更新、改进自己的产品,开发新的功能,这样周而复始,产品把用户最喜欢,优先级最高的功能永远都放在第一时间开发、上线。根据用户的反馈、统计数据的结果不断调整产品的策略,这样才能立于当今互联网。在我们身边也许Github、 Flickr等都是很好的成功例子。
下面是我对于一些是非的意见:

  • 结对编程能够明显提升代码的质量,让团队成员对代码的熟悉度大幅提升,但是我不赞成至始至终都是结对编程,应该留时间进行单独编程,这样虽然代码质量也许会有一些下降,但是如果伴以TDD对进行辅佐,是不会下降太多,单独编程有助于让dev独立思考,发挥创造力,很多时候会达到意想不到的结果。另外一点结果编程通常达不到两个dev独立编写代码的效率,就像在《人月神话》中讲到的那样,1一个人如果需要开发一个软件需要100填,那么10个程序员10天肯定不能完成任务的,因为期间还需要算上沟通的成本。
  • 关于TDD,确有遇到过几次绞尽脑汁也没想明白怎么测试的case。但是我们如果使用 隔离依赖(即mock依赖,stub行为,如使用mockito中的:given().willReturn();或者when().thenReturn()等)的原则来编写测试,绝大多数情况都会变得豁然开朗,就Java而言,遇到静态方法,我们可以通过间接的调用去测试,对于无返回值的方法(void)我们可以采用验证行为的方法去测试(如使用mockito中的verify()函数)。使用TDD的好处是不言而喻的,用测试代码描述你的需求,表达你想要的结果,既保证了质量也不用担心会做出多余的功能。不过在开发自己的小点子、小创意时,我通常选择Rails和Node.js进行开发因此TDD做得并不好,通产只是选择性的对重要的部分进行测试保证。
  • 沟通胜于一切,跟项目中所有的人频繁沟通,在实际项目中有一次是这样的,对于story中一个对于生效时间信息的描述有些模糊,我没有多想久自己认为肯定的全局的生效时间,但是不曾想到,当多个子产品出现时,就不能依赖全局生效时间,因为全局生效时间是其中最大第一个,而不一定是当前所需准确的生效时间,因此这个sotry在最后给BA 检查的时候才发现这个bug,试想最初如果我没有随便假设,而是马上给BA发邮件沟通,问清楚生效时间,也不会出现返工的情况。我个人认为良好、高效的沟通甚至比写好代码优先级更高。
  • 站会(stand up)既是一种对团队成员工作的可视化,了解彼此的进度等情况,也是锻炼表达能力、增强自信心的好机会。为何这样讲,因为在站会上每个人需要用几句话来概括自己前一天所做的一切,当你讲到你前一天做的一些进步时,团队为你真心叫好,难道不会让你你增强自信心吗?对于站会进行的方式,有团队会选择每个人依次讲解前一天的工作内容;也有人会选择采用按照故事墙的方式来进行,依次对每个列(analysis, ready for dev, in development, test, sign off等)进行浏览等,当讲到自己的那个story时,每个人需要更新自己前一天在这个story上的工作,这样的好处是可以对每个story的情况进行可视化。但是我个人更喜欢前者,这样更加自由,但是目前在工作中基本尝试的都是后者。
  • 另外一点是尽早集成,这点感触很深,大三的时候在一家公司实习,当时做一个原型系统,两三个人做一个模块,到最后快要演示的时候,才把几个模块尝试连到一起做集成测试。结果就是,所有人坐在一起进行的进行各种接口的连接、调用,bug修补。一旦连接成功就兴奋到难以言表,仿佛很长一段时间的工作都没有这一下来得兴奋。系统可以集成后,一直都提心吊胆,担心其中某个东西会不会莫名挂掉,因为集成测试都是使用人肉测试的啊。在展示的时候,各种紧张,安排专人时时刻刻注意到服务器。在敏捷中,我们要求及早进行系统集成和和创建部署环境的脚本,每次CI的运行都是一次集成测试,都是一次服务器的部署。因此不用担心在realse的时候不能部署的情况。不过有一件事情是需要注意的,那就是数据库的迁移,在开发机器,测试服务器你还能每次部署的时候都干掉之前的数据库,重新创建,但是在部署到产品服务器的时候就需要小心了,在Java中我们可以用Flyway 达到类似Rails中的 rake db migrate的效果。

另外,我认为 switch pair(变还你结对同事)、 code review(团队成员坐到一起对团队前一天提交的代码进行浏览、解读),这些都可以让整个团队共享更多的上下文,还可以检查出不到的代码,学习好的代码。
也许明年这个时候我对敏捷的看法又有不少新的见解,到时候再来分享。

Share