Skip to main content

为什么你的Scrum会失败?(二)

前文说了Scrum三种角色的错误姿势,现在来说一下四个会议。注意是乱序,先看showcase。

Sprint评审会议/Demo/Showcase

如何评价评审会议(或者叫Demo, Showcase)的效果? 我听过的答案有客户满意、或收集到了反馈等。这都不够,且不说客户满不满意本就不应是评审会议追求的东西,就是收集到了反馈,都不够。

那如何评价评审会议的效果? 唯一的评价标准是, 会后有没有对product backlog做出调整

如果每次showcase完product backlog都没发生变化,那恭喜我们,我们的计划和预见能力很完美,完全可以按瀑布的方式工作,没必要迭代交付了。客户或stakeholder需要了解, 他们对showcase负有给出反馈的责任和义务,找对真正关心产品或项目的人来参加showcase。

但往往团队倾向于show好的一面,直接点就是掩饰问题,这是本末倒置,会后皆大欢喜就是失败的会议,会后没有调整product backlog也是失败的会议。

Sprint计划会议: 实际上应该是分开的两个会

很多团队都会抱怨Sprint计划会议的冗长和低效。抛开开会的技巧不谈,根本原因在于Scrum把两个不同目的,需要不同参会角色的会议融为一体了。在它的官方指南里明确说了计划会议有两个topic: what 和 how。

IPM

对于what,即下个sprint要做什么,某种程度上是不需要开发团队参与的。PO应该根据stakholder的输入,从业务优先级上选出下个sprint的backlog。这个过程可称之为IPM, iteration planning meeting,应该在本sprint开始前进行,也就是推荐在上个sprint的末尾进行,开发团队的参与是可选的,PO完全可以一个人搞定或者跟业务方的stakeholder来商定, 具体如何取决于PO。

  • 你说还没估算呢,PO怎么知道要选多少? PO可以根据之前Sprint完成的story个数,多选几张,比如多出个20%的量。
  • 你说开发团队不参与的话,可能漏掉一些技术依赖项。我们还有下个会呢,开发团队有机会给出反馈。

说到底,估算和技术方面的依赖,不是决定优先级的很重要的因素,仅供优先级参考而已。

IPM结束后,PO手里有了一小堆下个Sprint要做的功能,可能比开发团队正常能完成的量多了一点。这堆功能将作为下个会议的输入,可以微调。

IKM

下个会议称之为IKM, iteration kickoff meeting,在本Sprint开始时进行,主要目的是PO和开发团队对这个Sprint的目标进行交互解释、答疑、达成共识。开发团队对优先级,验收条件的任何疑问都可以提出来,PO来解释或调整任务。对what没有疑问之后可以开始估算,如果你非要估算的话。估的时候就按优先级估,估到累积的工作量达到团队的capacity为止。

IKM的解释,答疑和共识,依然是what,而不是how。对于how,开发团队自组织讨论就可以了,不需要PO参与。开发团队也完全可以在领到任务开始做的那一刹那,由领到任务的一对pair自己讨论how就可以。

总结一下就是 PO自己搞定planning,PO和团队一起kick off,团队自己搞定how。IPM不占开发团队时间,IKM 2个小时足够,其它的讨论分散在开发过程中

每日站会: 关注接力棒, 而不是运动员

站会到最后是最流于形式的会议,没有之一。原因很多,而一个比较普遍的原因是大部分站会关注在了错误的点上,引不起团队成员共鸣。这个错误的点就是关注每个人都干了啥,今天要干啥。站会对于团队成员就成了一项考核,考核你工作量饱不饱满。每个人挖空心思表明自己没闲着,说完自己的就完事,也不管别人的。

那么站会正确的关注点是什么? 进度,障碍,新知,及是否要进行调整。关注接力棒,而不是运动员

每日站会是进度报告会吗? 你可能会说不是。我只能说: 当然是了! 开完会对当前进度是什么样子都不知道,这会也太浪费时间了,甭管是半小时还是仅有10分钟。 (你说我们有其它方式了解进度,站会关注在其它方面,那是另外一回事)

站会首先是进度报告会,区别在于是向谁报告,报告的目的是什么。站会是向整个团队报告进度,目的是寻求帮助,提供新知,为可能的任务调整提供真实的输入。站会是以天为周期的PDCA环中重要的一步,负责Check和提出Action。Check时检查点不在谁闲着谁没闲着,而在于过去这一天有哪些新的信息会影响到任务交付。

评价站会效果的唯一方式是,会后有没有根据会上的信息做出相应调整。不排除不需要调整的情况,但很少。换句话说,如果你站会后没有调整,那你的站会是极有可能没什么效果的。

Sprint回顾会议

没什么可说的。只要回顾会议有效果,其它问题再大都是小问题。当回顾会议没有效果的时候,问题就大了去了。其它问题都可以在技巧层面针对问题本身改进。但回顾会议没效果的话,改进回顾会议本身是没有用的。

评价一项活动,不是看它过程,甚至不是看它结果,要看它对其它事务的影响。站会/回顾/评审会议,都涉及调整。开完会没什么调整, 会就白开了。

Share

为什么你的Scrum会失败?(一)

Scrum失败的原因有很多,很普遍的一个是:忽视其众多前提而仅仅把现在的基层开发组织按照Scrum要求的那三种角色改了一下,就算是上马了。很快Scrum也就像它的音译那样,变成死马了,仅留一身马皮。我们来看一下为什么仅仅把基层开发组织改组为Scrum团队是不奏效的。

角色一, PO: PO的任职资格

在我所见过的Scrum团队中, 绝大部分PO是不具备PO的资格的。不是说能力,而是资格。PO从职责上讲拥有Product Backlog,负责决定哪些功能进、哪些功能不进、优先级是什么。换句话说:PO负责产品的方向。Product Owner这个词从字面上也赋予了PO这种职责,但与这种职责相伴的是对应的资格,是必须有资格能够负责产品的方向,你才能负责产品的方向。那么通常都是什么样的人有资格负责产品的方向呢?

  • 如果你是一个定制化开发项目、企业应用,毫无疑问,客户才有资格负责产品的方向
  • 如果你是一个产品项目,面向多个潜在客户,那么你们组织里面谁对产品的成败负首要责任,谁就是PO。

换句话讲, PO通常是资方而不是劳方的人,PO要么是给项目提供资金的人, 要么是他的代言人。通常出钱的人是老板,很忙,在大的组织里不太可能直接出任PO,但他必须把他的职责代理给某个人,而这个人是要对产品的成败负责的,出了事之后他要负主要责任。

如果PO不需要对产品的成败负首要/主要责任,那么他/她关于Backlog的范围和优先级的决定是不可信任的,不是说他/她这个人不可信任,人可能是好人,找你借钱你也愿意借给他/她,但由于他/她不需要负责,他/她的决定是没有权威性的。

在我见过的运行的比较好的Scrum团队中,担任PO的人都满足上面的任职资格,包括客户本人,包括从头到尾负责一个产品很多年的人等。而运行的不好的Scrum团队中,PO通常由原先开发团队中的业务分析师担任,仅具备一定的业务能力,而没有商业上的资格和权威。

角色二, Scrum Master: Scrum Master的悖论

在我所见过的Scrum团队中,绝大部分Scrum Master是没有认识到自己的使命的。Scrum Master的使命就是把自己做没,不是做媒,是做没。

Scrum Master这个角色深深反映了Scrum内在的不一致性。我们只需考虑这么一个问题:如何评价Scrum Master的工作成果? 如何证明一个人是合格的Scrum Master? 你会发现如果Scrum Master做的好, 他会把自己的大部分工作做没,变得越来越轻松。因为Scrum Master按照定义,从根本上来说就是一个教练的角色,教会团队自组织、教育PO、教育开发团队、教育组织里其它Stakeholder。评价教练的唯一标准就是被教授的人不再需要他/她了。

也就是长久来看,Scrum运行的好的话,对Scrum Master的需求会越来越少,这个职位甚至不再需要专职的人了,而这在Scrum的教义中是不推荐的。有的团队Scrum Master是兼职的,平时还有一部分开发的职责,不知道是不是认识到这一点之后未雨绸缪…

然而如果Scrum Master认识不到这一点的话,对团队的破坏将是巨大的。他/她会不由自主的为自己找事做,无形中破坏了团队的自组织。所谓自组织其实很简单,就是不去干预。如果团队在众多内部关于流程/活动/角色/职责等事情上需要Scrum Master的干预,则离自组织还很远。

那为什么球队永远都需要一位教练? 答案很简单,因为球队教练的职责是赢球,而不是教会球员自组织。如果他通过让球员在场上自组织来赢球,那球队确实对他的依赖会减少。

角色三, 开发团队: 开发团队自组织的假象

在我所见过的Scrum团队中,不是自组织,而是没组织。原先的Project Manager/Business Analyst/Developer/Tester的职责随风而去,现在统一称Team Member了。每个人在新的组织方式中无所适从,而Scrum Master经验不足、机械的、一厢情愿的抹平角色的差异,导致工作分配/领取出现众多状况,影响进度。

那么我们来回答一下这个问题:在Scrum的开发团队中, 还有PM/BA/Dev/Tester等分工吗?

答案是, 可以有。

什么,这难道不是在Scrum教义中被明文禁止的吗?

Scrum确实禁止了,但谁让它又开了个”自组织”的口子呢?如果团队自组织起来,开了个讨论会,觉得这个Sprint,谁谁谁,你去负责跟PO接口,搞清楚需求细节;谁谁谁,帮忙把CI环境弄稳定点;谁谁谁,把上个Sprint的功能没来及测的再测一下, 剩下的人都去做开发…这个会开完之后, 团队在这段时间内有了明确的分工甚至角色,只要团队觉得合适,团队觉得这样是在当前约束下完成工作最合适的方法,又有何不可呢?

本文原文来源于>>>>http://liguanglei.name/blogs/2015/05/04/why-your-scrum-failed/?from=timeline&isappinstalled=0

Share

敏捷咨询日记——沟通问题

强调沟通和杜绝浪费是敏捷最核心的东西,这两项基本是贯穿我这次咨询活动的主线-任何细微的活动都需要用心审视两个问题:我做这件事情的前提是传递价值给团队另一个人,那么价值的传递过程中有没有沟通的阻碍?价值的传递过程有没有什么东西导致了传递损耗既是浪费?从一对一沟通谈起,逻辑是你不可能消除所有的沟通壁垒,譬如你的口齿不够清楚,那么至少发现那些你可以消除的壁垒,消除它,并告知和提醒你的听众那些你不能消除的。往往人们犯的错误是:

  • 察觉不到那些可能成为沟通壁垒的微小细节;
  • 对自己不能消除的壁垒过分乐观;
  • 对自己的听众过分乐观;

很多微不足道的东西都可能称为沟通壁垒。传统上,邮件和文档理所当然称为阻隔沟通的最大障碍。文字的修辞不如口头表达直白有效;文字很难达到及时的确认反馈;超过一定数量的文字考验被交流者的耐心;绝大部分的文档撰稿人无法理解文档是一种用户界面的思想,我所看到的情况,大部分的文档达不到可读(readable)的标准。

未曾想到的是,某种不经意的细节也许也能成为沟通的障碍,譬如,某个不及时统一的术语运用,因为小,更容易被听者忽略或者不愿意直接打断;或者某个图省事的英文缩写;或者一个白板上随意的箭头;或者某个夹在在中文里的英文单词。归根结底,任何沟通的承载物都是一种界面(interface),界面设计种盛行的”Don’t make me think”完全应该引入到你的任何一次沟通中来。就跟蹦出个对话框说“对不起,请耐心等待上传结果”的意义跟“对不起,我的普通话不标准,如果有听不清楚的地方,请打断我”一样,都是一种降低使用者(被沟通者)预期的方法,目的都是达到更好的沟通效果。

当然,更重要的是提升自身的沟通技巧。这里面有几种技巧是可以提供帮助的:

学会察觉沟通者的身体语言

据说有60%的沟通依靠身体语言,熟悉几种常见的身体语言和它们背后的故事会有帮助。譬如,说反馈的话却不对着你说而是对别人笑,代表他不确定自己的观点是不是受人支持,希望找到这种支持;双手护胸代表对你的内容有抵触,他有更多自己不同的看法;双手叉腰,虎口对你代表疲倦,虎口对内代表急于表达自己的看法;看着茶杯喝水代表对你说的内容不感兴趣,看着你喝水代表对你说的极感兴趣;低头看你代表不信任,把某一边耳朵倾向你代表很关注你的内容,扬起下巴两指拖着代表关注并思考,等等。

会展现你的观点

画图是最好形成共识的工具,相当于一个美的用户界面。居我观察,A公司的专家没很少有能够干净准确表达自己观点的,共同的问题是,要么就不画,要画也是不知道如何画,最后的结果是白板上什么都不是。因为国人的教育偏究其理而轻表其象,也许这种技能是无法在短时间内获得,但是,根据大熊这个把Parking Lot画成熊猫的同志的经验,画的时候不要着急,画一点是一点,对自己要求严一点没画好的地方擦掉重画。

要持续确认

敏捷最美的地方在于任何活动都遵守敏捷原则,在沟通的过程中需要持续地把各自的理解与对方确认,可以说:我是不是可以这样理解…等等。

要鼓励对方进行沟通而不是制造障碍

譬如,很多人在一个阐述的结尾喜欢加:你明白我什么意思吗?或者,你能理解我的意思吗?等等,这样的话很容易让人在每个“吗”字后面不自觉地加一个“笨蛋”,认为这时候说不明白会有一种羞耻感,因此,更换成:我不知道我是不是表达得很清楚?或者,我会不会说得有点不太明白?会起到更好的效果。

要把已经达成一致的东西展示出来

看!这又是敏捷原则之一-阶段性的showcase,对于不再需要重复已经达成一致的观点,应该及时写出来,因为接下来的某些言论如果是基于一个已经达成一致的观点,风险会降低很多。你可以使用身边的纸笔,最好是白板纪录下这些内容。

(编者按:五年后再看这个会议沟通海报,据说已经变成了文物展出)

关于沟通的问题,也许还有更多的话题可以探讨,更重要的还是实践中的体验。作为ThoughtWorks的面试人员,沟通可是我的第一加分点,一个乐于或者善于沟通的人往往离成功不远,是我最欣赏的品质没有之一。

Share

建设全功能团队——实践篇

上篇文章中我们一起回顾了分工历史,对于技术团队影响以及建设全功能团队的必要性 ,在实践篇中我将详细分享一些实践以及我们团队的经验数据。

吃自己的狗粮

当开发人员坐在测试工作站前,你将会诧异于多少开发人员因为繁琐的步骤而不会安装/升级自己参与制作的软件,多少人认为自己设计的复杂配置是荒唐的。在很多情况下,这都不是安装、配置的问题,而是设计问题,将开发和测试过程分离而把痛苦转嫁给了另一个团体(测试、用服、用户),开发人员丧失了亲身使用软件的机会,进而无法发现问题的存在。暴露并修正这些问题,是将开发人员和测试人员进行轮换的主要价值之一。从我们的经验数据看,开发人员可以在一周内掌握大多数的测试技巧,个人的建议是从经验丰富的开发人员开始轮换,一方面他们更能认识到测试的必要性,便于交流,也便于形成表率。另一方面丰富的经验更容易帮助他们察觉到问题的存在。其它的一些要点是:

  • 一对一的充分交流,让开发人员认识到进行测试工作的价值和目的。
  • 引导开发对痛点进行思考、改进。改变测试简单、重复的工作面貌,要对开发人员形成挑战。
  • 一周轮换2天持续数周或连续轮换2星期为宜。

睁开眼睛看大象

开发人员习惯于正确性驱动,然而正确的返回结果却不一定是必须的,有时甚至是一种浪费。我们项目所需要处理形如1001的期货时间戳,10代表2010年,01代表一月份。开发人员自然想到了如何区分1910年、2010年、2110年的问题。于是复杂的内部表达被设计出来,用于推断正确年份。这是必须的么?如果我们能了解到客户最大的压力在于半年后项目能否成功上线、替换掉现有无人能够维护的应用,而不是100年后才可能出现的问题,我们是否能在类似的技术决策中,做出更聪明的选择呢?帮助开发/测试角色获取更多的信息,让他们了解到制定需求的上下文,而不仅仅是需求是什么;让他们从更高的层面认清各个故事之间的关联,能够分辨可以给客户带来最大价值的任务,这是将开发角色/测试角色与分析角色对换的主要价值。一些要点是:

  • 在进行分析工作前,开发人员需要完成多个模块的开发,而测试人员最好完成开发轮岗,否则收效甚微。
  • 分析工作可以兼职进行,我们认为比较有效的方法是每天下午花40分钟让开发/测试人员在教练的带领有重点的分析一、两个故事。
  • 重点放在提供一套思考框架帮助新手梳理分析思路,我们发现一个有效的方法是结对工作、独立思考、演讲并点评。(参见结对工作,不止与结对一节)

根据我们的经验,两周全程跟踪式的结对分析足够帮助新手初步掌握分析思路,教练可以考虑逐渐减少在新手思考过程中的侵入,再经过大概2个月的练习,新手基本可以独立工作。

和客户对话

在进行过分析角色的轮换后,可以进一步利用需求管理作为主线让团队成员参与到客户交流中,慢慢削弱项目经理的客户联系人角色,其主要价值在于:

  • 提升交流质量,一线人员常常比项目经理更了解产品。
  • 展示开发人员的能力,增强客户信心。
  • 弱化项目经理在客户眼中的重要性,为未来平滑的取代项目管理者,减少开销作准备。
  • 帮助技术人员掌握交流技巧、提升团队能力。

个人建议是:

  • 从例行的功能展示会(showcase)开始,让每个成员练习从客户的角度进行思考(客户想看什么?),锻炼语言能力,消除与客户交流的恐惧感,并且让客户熟悉开发团队的每个成员,习惯开发团队的交流方式。
  • 由多人分别准备客户进行电话会议中需要讨论的议题,每人深入思考的一、两个问题,通过充分思考弥补经验、技巧上的不足。
  • 结对完成发给客户的邮件,让另一双眼睛检查有没有把该说的问题点到,表达方式、方法是否得当。
  • 提供一套与客户交流的思考框架,并在与客户的交流中不断强化它。我们采用的框架是“客户,交付,流程,员工”,团队成员在思考问题时,首先从这四个点出发再逐层展开。

这项练习需要贯穿项目始终,对于团队成员无差别的进行,我们的经验数据是经过5个月左右的练习,项目经理就不需要出现在与客户的例行电话交流中了。

写程序,我行么?

测试人员普遍编程技术能力欠缺,同时有常常对编程这一未知的经验产生恐惧。从经验看,如果测试人员不能编写、维护自动化测试,测试工作将很快成为交付瓶颈。通过编程,让测试人员掌握技术,避免瓶颈的出现是测试到开发角色转换的主要价值。我们所采取的步骤是:

  • 与测试人员结对完成简单的编码任务,不断树立信心。在这个团队中,我们从设计与实现自动测试框架开始,亲手设计的框架让测试人员更有能力来编写、维护测试,同时增强了编程的信心。
  • 在测试人员消除了编程恐惧、具备编程基础后,安排测试人员与开发人员结对进行功能开发。

在这个过程中,必须首先要帮助测试人员正视编写程序的必要性以及消除恐惧,同时针对每天的工作内容留一些家庭作业效果也非常好。必须承认的事实是即便在完成轮换后,测试人员较开发人员还有一定距离,然而我们得到了一个意外的收获:进行过轮换后,再讨论需求时,测试人员越来越熟练的使用开发术语与团队交流,越来越多得参与讨论,甚至主导讨论,她开始直接引用核心组件的设计思想来推导测试用例,不断质疑和挑战开发人员,极大的提升了交流的效率和功能实现的质量。从经验数据看,大致需要3个月的时间测试人员可以达到在辅导下完成功能的程度。

订最后一颗纽扣

前端开发有其独特的知识领域,但这并不意味着任何界面工作都要由前端开发工程师来完成。前后端的分离增加了开发过程中的瓶颈以及人员认知领域中”Unknown Unknown”的区域,降低了找到更优解决方案的可能性。前端开发能力的培养特别适合在全团队中无差别的展开:让后端开发人员进行前端开发可以减少瓶颈,积累知识,构造“T”型知识区。测试人员需要测试界面,所以了解界面是如何工作,可以帮助她们设计出更高质量的用例,对于需求分析人员来说,高保真原型可以用作高效的交流工具。一个有效的方法是全面铺开,引入专家,重点培养,我们所采取的步骤是:

  • 要求全团队在业余时间完成一组界面练习,在全团队普及Html, Css和Javascript知识。
  • 引入界面开发专家重点培养一名有兴趣进行界面开发的团队成员,对系统的界面结对进行改进,优化。
  • 在界面开发专家的带领下,全员重新完成之前的界面练习,专家每天用一个小时讲解对应的前端技术并点评作业。

从全面普及知识到引入界面专家再到培养出新人,总共花费3周时间。值得一提的是,在整个过程中,由于之前团队建设的铺垫,其它成员有能力完全分担工作,团队重点培养的开发人员可以不受任何干扰,全职投入到前端开发中,最大程度的利用了界面开发专家的价值,提升了学习效果。

上同一艘船

项目经理是和技术领袖是作为现场管理者存在的,他们必须能够理解现场,能够通过现场的痕迹找到团队的不足和改进方向。那么,没有什么比卷起袖子参与到一线的工作中更能帮助这些角色理解现场。形成对产品质量和进度的亲身体验。理解现场,有效的管理现场而不是管理数据,是这些角色轮换到开发,测试或者分析工作的主要价值所在。现场管理人员常常有太多的职责,既要对内负责也得对外负责,一个自然而然的问题是:”没有时间投入一线工作“。我认为现场管理人员的工作主要是两个部分:首先是职位责所赋予的管理性事务,譬如状态的汇报,客户的管理等;其次是能力所赋予的工作,作为团队中最有经验的成员,他们需要参与到需求分析、架构设计、决策的制定、培训等活动中。基层管理者应当有意识的主动的卸下身上的工作职责,完成到一线角色的转换,从另一个角度看,这个过程就是整个团队能力提升的过程,个人经验是:

  • 对职位责所赋予的工作,首先做到对团队的状态、开发的进度等尽量的做到自动化、透明化、可视化,让所有人都能获得这些信息,其次通过知识传递,把不涉及敏感内容的工作下放,重点培养一两名团队成员参与管理。
  • 对能力所赋予的工作,一是针对团队急需提升的能力组织培训,二是通过结对工作(参见结对工作,不止于结对)传递知识,提升能力,让团队习惯于自行决策,有意识的逐步弱化自己在团队中的重要程度。

我们的经验数据是大约需要4个星期,新人可以在指导下正确的进行管理实践(正确的做事),这已经可以保证基层管理角色参与一线工作的时间;而让新人具备辨别团队目前需要什么帮助(作正确的事),进一步将原有的管理角色基本弱化为开发角色,则需要6个月左右的引导和练习。

结对工作,不止于结对

我完全认可结对工作在知识传递、提升工作正确性方面的作用。我们几乎结对作所有的事情,某种程度上结对工作成为一种文化,成为了思维惯性和一种必然。长期的结对工作让我发现目前的结对方式对于培养新人还不够友好,这里,新人所指代的是广义的新人概念,不仅仅指毕业生,刚刚从事测试工作的开发达人也算是测试新人。目前结对方式的的缺点在于:

  • 培养了思维惰性,心理上依赖于别人的带领。
  • 无法从失败中学习。有经验的人常常会跳过很多陷阱,新人的工作经历全是各种成功,一旦独立工作就被这些陷阱打的措不及防。
  • 只见树木不见森林。譬如在TDD的过程中,新手可以看到一个个的方法是如何被设计的,如何从测试中被驱动出来,但很难从他的搭档那里学会如何想到要设计这些方法?从下向上驱动还是从上向下,各有什么分别?为什么这个方法要被放在这个类,而不是那个?

我认为结对工作其中一个被忽略的要点在于让新人在可控的状态下经历失败,获取经验,并且在工作中学会思考问题的方式(如何发现问题?从何处着手?怎么在不同的方案中取舍?从哪里开从哪里开始分析?),而不仅仅是思考问题本身(写什么测试?如何让测试通过?)。从我的观察看,培养新人比较有效的途径是从全程结对工作开始,通过对细节的指导让新人了解工作的主要方式和职责,进行必要的知识贮备,学会如何正确的做事。接下来应当让新人逐渐学会什么是正确的事情。我们的做法是:

  1. 新人接到任务后,自行思考。
  2. 在白板上写下完成任务的主要步骤
  3. 向教练讲解主要思路和考虑点,教练通过提问引导他(输入特殊字符会怎样?)
  4. 自行完善方案
  5. 和教练一起确认方案
  6. 教练对整个思考过程进行点评,告诉新人这类问题的思考要点

整个过程大致耗时半个小时,这种方式的优点是新人对方案非常了解,执行起来不容易跑偏;有机会在可控范围内犯错,成长更快; 新人可以通过不断的练习有能力通过多个任务逐渐总结出一套思维方式。教练利用这种方法可以通过代码检视和有选择的结对(譬如针对任务中的难度部分结对)同时帮助多人,更有效率。

结局

在咨询的过程中,我见过太多的团队把目标放在交付上,寄希望于工具、外部力量,期望快速的解决问题,往往对小步前进不够耐心,不关心团队的成员。在我们这个 90%以上成员没有.Net经验,50%是毕业生的团队中,那些微不足道的改进,一点点的提升,最终造就了这个9个月中没有一天加班,几乎没有缺陷,提前交付的项目,客户甚至愿意为他们的满意额外支付3万美金作为奖励。我把全篇总结为一句话:把项目目标放在人员能力提升,让项目成功成为能力提升的副产物。

本文转自:http://www.infoq.com/cn/articles/hk-build-full-function-team-practice

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