文章

使用特性团队(Feature Team)

敏捷团队更有利于关注价值交付,对这一主题产生了相反的矢量。实际上对于敏捷团队的组织,几乎普遍接受的方式是围绕特性的。如下图所示。
scrumcn1352366254

特性团队方式的优点也非常明显:团队可以形成对实际领域和系统使用方式的专业知识,而且通常可以加速任何特性的价值交付。这种方式的开销更少,因为在对特性的实现中,多支团队不必来回传递待办事项条目。而且在团队之间的相互依赖少很多,计划工作与执行也更简练。

与核心技能对应于技术栈中某一层形成对比的是,特性团队的核心能力对应于某个特性(或特性集)。团队的待办事项被简化了,在任何时间只有一到两个特性,这样必然可以促进高增值特性的快速交付!

也有一些其他作者支持以特性为焦点的方式。例如Highsmith写道:

基于特性的交付意味着工程团队将构建最终产品的特性。

当然,这并不是说团队本身必然是“按特性组织”的,因为所有工程团队到了最后都是为最终产品构建特性,虽然他所说的可能含有某种合理推断。其他人—包括Larman和Vodde,更直接(而且坚决)地提倡特性团队作为组织敏捷团队的最佳方式,他们指出:

特性团队是一种长期、跨职能的团队,能够一个接一个地完成一些端到端的顾客特性。其优点包括提高价值产量、方便知识学习、简化计划、降低浪费….

Larman和Vodde还认为应该“避免构件团队”。不管怎样,他们也指出了采取特性团队方式的若干难题,包括需要更宽泛的技能和产品知识、对代码的同时访问、共享设计职责、以及在实现复用和基础设施工作中的困难,而且还有围绕边界的组织对齐造成某些团队成员错位的可能性。

有时候界限是模糊的

即便有着这样的建议,我们也必须承认特性和构件都是抽象概念,它们的界限并不明确,一个人设计的特性可能是另一人的构件。而且有时候,单一特性最好被实现为独立的、面向服务的构件。

举例来说,TradeStation Securities构建一个在线交易系统,其中“记录”是一个关键的交易者功能,由少量集中的敏捷团队一起在“记录”功能上工作。表面上看起来这是特性团队的一个良好示例,因为记录是该系统的主要特性。

在开发新的在线交易功能时,如“外币兑换交易”(Forex),必须添加新的记录功能。然而驱动这一新记录功能的是一些主要构件,如流化数据、账户管理、与外汇交易市场的交换接口。是应该把新特性的价值流描述为“通过专门的记录功能完成与外汇交易市场的所有交易”吗?如果是,很明显应该产生垂直特性流,而且可能要重新组织团队,从各构件团队吸纳某些成员并针对外汇交易市场的交易创建新的垂直特性团队。或者是否把新特性描述为“Forex交易”加“Forex绘图”?这种情况下的绘图团队是否已经有了适当的组织?这种记录功能是特性集还是构件呢?或者是二者?对这种状况起个什么名字真的重要吗?

即使认为其称谓是可以明确的,特性团队总是最佳选择吗?Keith Black(TradeStation Technologies的副总裁)写道:

在线交易要求在许多不同层次上有着相当深度的专业技能和行业知识,我们没有办法对来自所有构件领域的成员合理地形成特性团队。

因此,在我们向敏捷转型中,我们首先是围绕构件团队进行组织,在成熟之后,我们现在针对特殊情况组建特性团队。虽然特性团队在推动一个计划直到完成中是出色的,但是某些情况下它们就不合理。例如,有二十支特性团队而且他们都依赖某个公共构件,比如一个时间关键型的联机事务处理引擎,让20支不同的团队都参与到这一关键构件是不明智的。相反,可以选择使其中的变更由单一团队控制,由该团队代理20支团队的需要,并通过对具体特性作出修改确保其他团队不危及他们不了解的区域。

向特性团队倾斜

鉴于每种方式的优点与缺点,答案并非一直都那么明显。但是考虑到敏捷对直接价值交付的焦点,可以向特性团队适当倾斜。正如Mike Cottmeyer指出的:

我倾向于从特性团队开始,只在必须的情况下才转向构件…但这种决定是基于特定状况的。

为了做出这种决定,将必须分析你们的技术多样性…你们系统设计的如何…使用什么工具来管理代码基…你们团队的规模与技能…团队是如何定位以及分布在哪里…还包括你们的基础设施自动化的品质。

必须认真研究要把特性团队分解到什么程度…到了某种规模特性团队会瓦解。伸缩到这样的程度是我们必须现在处理的吗,还是可以等待?

小议团队自组织

“自组织”是敏捷中难以把握的一个词,英文是self-organizing,也有地方是self-organization,还有self-organized,以上三个词的中文都译为“自组织”,从英文来看,显然三者是有区别的。

在敏捷软件开发宣言中没有提自组织,在敏捷原则中相关原则的英文原文是:

The bestarchitectures, requirements, and designs emerge from self-organizingteams.
中译文是:最好的架构、需求和设计出自自组织团队。Scrum中用的词也是self-organizing。

从字面意思上理解,敏捷原则指出了自组织为方向,推荐自组织(self-organizing)团队,但并没有强制要求必须自组织。这与现代管理学对待知识工作者的方向是完全一致的。已经有研究结果表明,基于X理论并且很好的适用在体力工作者上的管理方式是不适用在知识工作者的。

通过英文单词self-organizing和self-organized可以看出,自组织可以分为两种状态,1种是正在自组织中,第2种是已经自组织了。self-organizing更像是一种趋势,当团队展现出向self-organized的趋势时,这个团队就可以算是自组织中的团队,简称自组织团队。

scrumcn1347346641

图 团队类型的三角关系
在讲到自组织时,常常拿自然界的蚂蚁群和蜜蜂群作为自组织的典范,但是同样在自然界的狮群、狼群和猴群等也是符合自组织的特征:“没有外部指令,系统按照相互默契的某种规则,各尽其责而又协调地自动地形成有序结构”。所以没有团队内部领导者并不是自组织的本质特征,自组织团队内部不一定没有领导者。

在Scrum的团队方案中,取消了项目经理角色,给ScrumMaster加了不少限制,团队内部没有指定的领导者,不允许给他人分配任务,如果团队能够有效运转的话,自组织程度必然很高,可以说超越了self-organizing,达到了self-organized。这样对Scrum团队就意味着必须强制采用自组织方式。对比XP的理念,好的东西就发挥到极致,Scrum有点这样的味道:自组织团队是好的,就要把自组织发挥到极致。一盘散沙、群龙无首的团队是个极端,自上而下命令与控制的团队也是个极端,完全已自组织(self-organized)团队也是个极端,存在一个如上图所示的团队类型三角型。

现在已经有多个例子表明,没有团队领导者的Scrum团队是可以获得很高的团队绩效的,照样可以形成原来在个别杰出项目经理身上的团队领导力。当然也有例子说,标准Scrum团队搞不下去。

如果团队成员只会做相应报酬的工作量,还可能基本还达不到其相应的报酬,大多数人都在混日子啊;如果给他们自由,他们会只会做他们感兴趣的事,要么聊QQ,要么打游戏,看闲书,反正不干正事,那么这个团队离图二所示的完全已自组织顶点还很远,要有效发挥团队能力的话,一个富有领导力的领导者是最可行、最现实的解决方案。

另据报道,当前这个世界上已经存在一家名为Semco的公司,这家公司的团队没有内部领导者,团队成员的薪酬已经内部公开,并且各团队成员能够心平气和的协商确定各自的薪酬,团队绩效非常好。这样的团队真可以算是自组织的巅峰了,让人不由的联想到传说中的共产主义社会。

笔者认为适合的才是最好的,应在三个极端构成的三角型中寻找合适的位置,把握三者之间的平衡,以团队贡献目标为导向,不必追求形式上的极端。所以笔者并不赞成仅仅是为了搞Scrum而取消团队内部领导者。

从传统软件工程看,团队内部领导者的设立似乎是理所当然的。中国政府信产部推出了名为“信息系统集成项目经理”的资格证书。

从CMMI来看,在CMMIfor Dev 1.2中,明确给出了项目经理的名词解释:负责计划、指导、控制、构建、激励项目的人,项目经理对满足客户负责。显然的,这个解释就是传统软件工程中理所当然的解释。而在2010年10月发布的CMMIfor Dev 1.3中,项目经理的名词解释没有了,在正文中,说明了项目管理相关目标和实践,没有提项目经理。这个改变显然是敏捷所带来的。因此最新的CMMI for Dev看,只要满足项目管理相关目标,没有团队内部领导者的团队能够符合要求,当然传统的项目经理也能符合要求。

Scrum关于自组织的高要求在前文已经说明,而从XP及其它敏捷方法流派来看,“自组织中”的团队是得到推荐的,而且自组织程度需要比较高,但缺省的仍然保留了项目经理或领导者的角色。在敏捷的另一个流派-精益(Lean)当中,就强调经理发挥好教练的作用,并且将此作为精益的基础。水晶方法集中存在项目协调者或项目经理的角色。

 

本文来自于张克强博客,原文地址为:http://hi.baidu.com/hespr/item/0add99de8e90b91ed78ed0a6

自我评估团队

虽然你对于现在的团队成员评估的流程是彻底全面,一丝不苟的,但很有可能对于结果你是不满意的。业绩评估的首要目标是从个人到组织层上业绩得到改善。但是个人如果没有在评估中顺利通过的人会感到失落,这样就失去了联系的目的。

深入了解下目前常用评估系统的挑战,有以下几点突出点: Read more

交流,而不是监督

我从不是一位事必躬亲的管理者,要不是因为使用敏捷和Scrum。若不是我总是太忙了,以至于无法花费我的时间在监督别人,在我的职业生涯的早期,我就可以转型成一位事必躬亲的管理者。但是,在我避免监督团队或人们的同时,我从来没有不情愿与他们沟通。最近通过阅读一篇关于从小处着眼的重要性来提醒自己记住这个。 Read more

我所知道的关于Scrum团队的一切都来自MASH

我热衷于参加团队组。我喜欢进行讨论,也乐意见到参与讨论的朋友。有很多问题重复出现,但是经常都能引起不同的讨论,而我个人认为这是好事。因为这些话题每次出现的时候总是能够让我学到新的东西。

一个经常出现的问题就是:“应该让谁来当Scrum Master?”有时候问题简单得就像“我们要开始实施Scrum了,所以我们要一个Scrum Master。但是应该让谁当呢?”有时候问题又稍微深入一点。很多这样的对话都集中在团队在向Scrum转型的过程中,如何将项目经理转变成Scrum Master,而这个问题是转型过程中一个自然的步骤。虽然,我觉得这是自然过渡的一环,但是我不大确信它像想象中那么有用。在我们无休止地追寻自我的过程中,我将会用70和80年代一部非常有名的节目——MASH来解释。 Read more

巧妙使用“故事点”进行敏捷估算

克强在“敏捷中国”讨论组中引发对敏捷的估算的讨论(“Scrum sprint plan中规模估算的做法调查”,“关于story point的单位”)。我想分享一下我自己对敏捷估算方法的理解以及对于“故事点”的认识。

在敏捷开发中,团队通过两种方法对迭代做计划。
  • 基于承诺”Commitment”。做法很简单:
    • Product Owner从Product Backlog中取下一个用户故事(按照优先级),对这个用户故事进行解释,
    • 团队对用户故事进行讨论,明确需要解决的问题,
    • 整个团队确定是否能够在下一个迭代周期中完成这个故事,
      • 如果团队没有信心完成该故事,计划会议结束,或者把这个用户故事进一步划分成更小的用户故事重复第一步。
      • 如果团队有信心完成该任务,重复第一步。
  • 基于速率”Velocity”
    • 确定Product Backlog中用户故事的规模(用“故事点”)
    • 确定团队迭代的开发速度(“昨天的天气”)
    • 从Product Backlog中取出相应量的用户故事。
基于速率的估算中,需要确定一个“故事点”,也就是确定一个速度的单位。而在敏捷计划与估算计中,这个“故事点”是没有单位的。为什么?首先来看一下传统的规模估算的方法(标准日、代码行数)的问题。
  • 绝对估算 vs. 相对估算
    传统的方式是通过计算出一个绝对值(有单位,比如多少人天,多少代码行)。然后,做出计划。很大的问题是,人天生不擅长做绝对估算,人们更擅长做相对估算,更容易在相对估算值上达成共识。举一个简单例子,估算从上海市人民广场到徐家汇的距离,如果使用公里或者米等绝对单位,多个估算者很难达成共识,往往陷入没有必要的讨论和争吵。而如果用相对距离,比如从人民广场到徐家汇的距离相当于两倍的从人民广场到火车站的距离,人们就很容易、很快达成共识。因此对一个需求点来说,关注于相对大小也更容易使整个团队在估算值上达成共识。
  • 关注规模(而不是将不同维度的概念混淆)
    比较合理的估算方法是,首先估算整个规模,然后有一定的历史数据,知道速度,从而可以做出计划,推算出时间。比如我们看书,一共三百页,一天看十页,很容易就算出是三十天。如果使用理想日(时间维度),其实就是把这个过程搞反了,从时间维度反过来推算规模。同时使用“故事点”可以综合考虑一些其他因素包括复杂度、不确定性等,基于故事点的规模估算是在综合考虑各种因素之后的综合估算。而用代码行数很难对复杂度、不确定性等作出估算
  • 忽略个人能力的不同
    不同人的理想日和代码行数估算是不同的,是根据每个人的能力和认识的不同而不同的。但是使用关注“相对大小”的“故事点”就可以解决这个问题。同样举距离的例子,每个人的能力是不同的(有人步行、有人跑步、有人公车、有人地铁、有人开法拉利),但是所有人得出的相对规模值还是一样的。因此使用相对规模估算就可以不需要考虑这种个人能力因素。
  • 不可相加
    传统估算方式的一个很大的问题是,估算不能相加。每个人的理想日是不一样的,这样成员甲的估算(理想日)就不能和成员乙的估算(理想日)相加。基于这种相加结果的计划肯定是不准确的。在敏捷开发中,需要整个团队一起对任务进行估算,因此需要一个能够达成团队共识的标准 – 也就是“故事点”。
因此,为什么“故事点”没有单位?
  • 首先,故事点是一个相对量,相对值是没有单位的;小学乘法:被乘数 × 倍数 = 积。故事点估算值就是这个倍数。
  • 其次每个团队的单位“故事点”是不同的,很难也不需要统一。
最后,其实敏捷的计划估算与传统的计划估算很大的不同是对计划的态度。在敏捷开发中,计划估算只是一个对未来的预测,因为是一个预测,所以总是有不确定性。敏捷开发计划承认这种不确定性,因此对计划估算的态度应该是不断根据新的发现,对计划进行不断的调整,但是不需要过于关注预测的准确性(我们的工作是为客户开发有用的软件,而不是提供可靠的计划。如果公司以预测的准确性来衡量员工的绩效,那其实大家也该考虑换一个地方了,这又是一种局部优化)。

关于作者:

爱迪德高级软件经理,InfoQ中文站特约编辑。他是亚洲第一位也是目前唯一一位认证Scrum教练(Certified Scrum Coach)Daniel具有多年的敏捷项目(Scrum & XP)实践经验以及丰富的带队经验。

Daniel20061月创建了Irdeto上海研发团队,并将ScrumXP成功引入了团队。目前该团队主要负责数百万美金级别的大型付费媒体计费及客户关系管理系统的开发及维护,四年中成功发布产品的两个新版本。系统现在在美洲、欧洲以及亚洲的许多国家运行。

Daniel一直致力于将海外的敏捷思想、理论及方法以及实践介绍到国内,帮助国内的软件团队高效并有趣地工作,真正为客户创造价值。作为敏捷社区的活跃分子,Daniel通过博客、InfoQ以及讨论组等宣传敏捷。Daniel经常受邀到各个会议中针对敏捷话题进行演讲,他是敏捷中国2009的讲师,并受邀QCon北京2010以及在CSDN举办的软件开发2.0大会2009等中作关于敏捷的演讲。

Dianelblog: http://www.cnblogs.com/tengzy/

他山之石,不可攻玉

在一次行业聚会上,又一次遇到了李剑,和他开玩笑:
……
我:你翻译的这本书(《硝烟弥漫中的Scrum和XP 》)害了好多人。
李剑:呵呵, 我知道,我道歉。@# ¥ # ¥ %… ,很多人把这个当成了敏捷…
我:哈哈… ,关键它太流行了。你现在成敏捷的罪人了,你竟然一下子送给了我们公司   5本。
李剑: @#¥ # ¥ % …… Read more

基于 Jenkins 快速搭建持续集成环境

持续集成是一种软件开发实践,对于提高软件开发效率并保障软件开发质量提供了理论基础。Jenkins 是一个开源软件项目,旨在提供一个开放易用的软件平台,使持续集成变成可能。本文正是从持续集成的基本概念入手,通过具体实例,介绍了如何基于 Jenkins 快速搭建持续集成环境。 Read more

11 个高效的同行代码评审最佳实践

简介:这 11 项针对轻量级高效同行代码评审最佳实践被证明是有效的,它们建立在一个通过结合使用 IBM® Rational Team Concert™ 与 SmartBear CodeCollaborator 对 Cisco 系统的开发进行案例研究的基础之上。它们可以帮助您确保评审既能够改进您的代码,又能利用好开发人员的时间。 Read more

Scrum解析:当西方遇上东方

敏捷的基本观点是以变化的观点看待世界(体现在敏捷宣言中的响应变化)和以人为中心(体现在敏捷宣言中的个体与互动和与客户合作)。Scrum是一个管理框架,流和可能性的艺术。它是东西方思想碰撞与结合的产物。它的三个哲学基础是:
来自中国的王阳明的知行合一学说。
来自日本的野中郁次郎的场理论。
来自美国的Jim Coplien等的模式(源于道德经)。 Read more