Scrum_tp

什么是工程师文化?

四年前,我在QCon上演讲了一个《建一支强大的小团队》提到了工程师文化,今天,我想在这里再写一篇关于工程师文化的文章,一方面是因为我又有了一些想法和体会,另一方面,因为我也正走在创业的道路,毫无疑问,要建一个有浓重的工程师文化的团队或公司,所以有必要把自己的相关想法形有成白底黑字的“字据”,以供打自己的脸——“要是未来没有做到,这篇文章就打我未来的脸” || “这篇文章太幼稚了,未来的我会打我现在的脸”,当然,如果要打脸,我希望是前者。
Read more

关注工时还是关注目标

工时管理有错吗?工时管理是很多公司还在实施的一种人力资源管理方法,主要目的就是记录员工所有的工作时间都花在哪里,笔者认为这没有错,有错的是工时记录方式以及对工时数据的运用。
先来看看正确的运用:
工时管理为改进服务,不建议用于考核。 Read more

成功的SM和敏捷教练应具备的品质

Attitude & Affirmations态度&自我肯定
端正你的态度,你就能100%成功。
自我肯定是与自我的交谈——你对自己的对话会体现在你的行为中。
善待自己,美好的事情就会发生。
Balance & Benchmark平衡&基准
使身心达到一种平衡。比如,在Naya – No Sayers的反对声中坚定立场。
为你当天的工作创建一个基准。通过持续的反馈机制来跟踪你的团队的进程。
Courage & Collaboration勇气&协作
只有勇气才能创建高协作的团队。
Determination & Desire决心&渴望
强大的决心能令人成功。
渴望成功。积极的看待他人,你就会在每个人身上发现美好的事物。

Energetic & Enthusiastic充满活力&热情
你身边的人会留意到你的能量和热情,尽情展示它们。
Focus & Faith关注&信念
保持持续的关注。试着在你的sprint中玩短期冲刺游戏和马拉松游戏,给团队注入强烈的信念,使他们能赢得竞争。
Give & Give Some More给予&给予更多
做一个给予者。无条件的竭尽所能地提供所有帮助和支持。记住:你给予他人的终有一天会回报到你自己身上。
Happy & Honest快乐&诚实
保持快乐的心态。如果你快乐,你在全世界都会找到快乐的人。快乐会传播。
诚实,无论你说什么或做什么。
Income & Investment收益&投资
把收益和投资作为每个用户故事商业价值的准则。询问PO,“从这个功能里我们能得到什么收益?”这很难实施,但却会得到不错的效果。
Joyful & James欢乐
散发愉悦的情绪,无论他或她。每一个人其自身就拥有所有美好品质。如果从没有人告诉你该在什么年纪做什么事,你不会相信自己能变成任何样子。鼓励他人。传播你的欢乐。
Kind & Knowledgeable友善&博学
通过友善,你能懂得人类在大脑里通过听觉和视觉图像所产生的的动觉。友善的对待他人能帮助你了解团队成员以及他们的困难。它还能帮你和团队建立一个深层的联系。
知识是一股真正的力量。如果你有过实战经验,为TDD写过FIT scipt,,CI写过Hudson,Unit Test写过Junit,或GUI test写过Silenium,对你的团队来说你就会是非常好的技术资产。
Love & Learn爱&学习
无条件的爱所有人。爱己者人必爱之。你所表达的会反射向你。
学习。做一个永远的学生。保持开放的心态。俗语有云,人类的心灵就像一个降落伞:只有打开状态它才能很好的工作。
Miracle & Mind奇迹&思想
我们周身所见的所有事物都是人类思想的奇迹。如果给予所有的资源,帮助和信任,人类能创造奇迹。

Neuro-lingustic Programming & Noble deeds神经语言程序学&行为高尚
神经语言程序学能帮助你了解团队成员的思想,帮助他们解决困惑。
至于高尚的行为:肉体易腐而行为永恒。
Objective & Observation客观&观察
永远对你真正想要和明确想要的东西有一个非常清楚的客观的认知。
通过他人的言语,手势和身体语言来观察其反应。只有7%的沟通是通过文字完成的;而65%的是通过的身体语言。
Passion & People激情&人
怀抱激情地做任何事,则一切皆有可能。
人是你生活中最有价值的事物;无条件的尊重他们的思想——他们的想法是他们的世界观的体现。他们的行为方式是他们成长和教养方式的产物。
Questioning & Quality询问&质量
用开放性的问题做引子来开始和PO的讨论,用控制问题来搜集事实。
敏捷里的质量开始于第一天——和TDD一同开始。不要接受一个用户故事,除非它已经明确定义了商业价值和验收标准。
Realistic & Respectful实事求是&尊重
始终实事求是。有90%的功能从未使用或被客户需求过。
在各个方面尊重每一个人。
Satisfy & Serve满足&服务
满足客户真正的需求,而不是想象出来的。采取仆人领导模式–其已被圣雄甘地,曼德拉,特蕾莎修女,或其他你对其有坚强信念的公仆型领袖所验证。这个领导模型已经存在了好几十年了;把它拿过来充分利用吧。
Time Boxing & Trading时间盒&交易
时间盒是最强大的基础概念之一,敏捷项目管理实践(Scrum)就是建立在这个概念之上。利用它来制造合适的压力。
只在商业价值上花费时间。采用丰田成的14项原则来消除浪费。

Unique & Unify唯一&统一
通过协作交流和使用简单的语言来统一团队(业务和技术)的所有人。主要使用视觉化的交流,白板,可视会议,网络摄像头,实时会议,实现了SAS的 ALM工具,wiki照片等。
Vision & Value想象&价值
对每个产品都有一个明确的愿景,并让团队里的每个开发人员也能明了。它是一个我们从哪儿来到哪儿去的路线图。把敏捷的价值观和原则映射到组织机构的价值观中。而价值观和原则是成功的主要成分。
Work & Worship 工作&崇拜
工作就是崇拜。工作创造了意义。
Xanadu & Xavier世外桃源&泽维尔
世外桃源:美丽或奇妙的地方。营造一个工作环境,使之成为最为美丽的地方之一。
泽维尔:一位著名的数学家和喜剧演员的中间名。你必须运用数学技能和幽默感才能产生渴望的结果。
Yoga & Youthful瑜伽&年轻
瑜伽是对你的思想,身体,以及灵魂的结合。瑜伽与任何文化或宗教无关。做力量瑜伽来冷静你的想法,并平衡自己来保持永远年轻。青春是团队们喜欢的一个魅力。
Zion & Zeal纳西&热忱
纳西指一个幻想出来的完美的地方或主意。记住这世上没有完美;总会有不断的改进。
热忱是积极的关心。在你的工作中,团队里和生活中使用它。

原文地址:http://www.scrumalliance.org/community/articles/2010/april/agile-coaching-qualities-from-a-to-z

成功组建规范敏捷交付团队的 5 大技巧

简介

敏捷宣言(Agile Manifesto)自 2001 年发布以来就定义了敏捷方法的核心精髓。最近,IBM 以 “规范敏捷交付” 之名提出了一组最佳实践,帮助较大型软件开发团队取得与较小型团队在过去 10 年使用敏捷技术所取得的相同成就。这不是说现有的常用敏捷方法是杂乱无章的;事实上,大部分敏捷方法都需要比传统或临时的方法更加规范和严格。但是,并不总是有处理复杂企业环境中的大型敏捷项目的指南。

DAD(规范敏捷交付- Disciplined Agile Delivery,是 IBM 提出的一组实践,旨在帮助较大型软件开发团队像较小型团队一样成功实现敏捷开发) 提供了一个混合框架,将来自各种现有的成熟敏捷方法(比如 Scrum、XP、Crystal、FDD 和 DSDM)的最佳指南结合在一起。尽管这些方法中的每一种都有价值,但每种方法在各个方面都是不完整的,因为从业者通常会将来自不同方法的技术堆叠起来,获得某种相对集中的产物。来自 IBM 的敏捷/精益 IT 首席方法学者 Scott Ambler 收集了来自多种方法的最佳指南,并得到了 DAD 框架。我非常幸运能够与 Scott 合作,并能够在我自己的项目中使用这些实践。

DAD 还为常见的敏捷方法补充了企业指南。例如,DAD 会向团队展示如何将 “积压” 等主流概念带到下一个层次,让它们更适合更大规模的企业环境。它可帮助您与直接开发团队以外的企业权威合作,比如企业架构师或数据库管理员。一些开发人员错误地认为,采用敏捷方法后,您就不再需要处理这些个性特征和准则。事实不是这样的。大部分敏捷团队都必须放眼于团队外部,尤其是在参与其他项目和与组织中的其他权威人员合作时。

基于我个人作为大量敏捷项目的开发人员和团队领导的经验,我提出了以下建议,帮助您思考与敏捷开发原则指导下的项目相关的大型团队管理问题。这些只是在组建拥有 20 或更多位开发人员的敏捷项目团队时要考虑的部分因素,但它们可帮助您朝正确的方向发展。

技巧 1:欢迎通才专家

传统方法倾向于假设一个拥有非常专业人员的团队会为客户带来更出色的产品。事实上,我们发现事实正好相反。在许多情况下,参与项目的人员越专业,他们会越想尝试生成完美的文档、完美的代码和完美的模型。此外,如果团队依靠只拥有自己专长技能的专家,则效率就会降低。例如,如果团队中只有一个人理解数据库,那么不仅该团队的工作会延误,而且将有效的解决方案交到利益相关者手上的整个过程也会延长。

DAD 促进了拥有 “通才专家” 的团队的形成,通才专家也就是具有一项专长,但还对软件开发生命周期中的多个领域拥有基本知识的人。例如,一位分析师可能是需求方面的专家,但还对测试具有基本知识,如果团队测试进度落后了,该分析师可以提供帮助。

在我现在参与的项目中,开发人员除了传统的编码专长外,还花了大量时间来帮助编写部署和持续集成脚本。结果,他们都获得了有关基础架构和配置管理的基本知识。另一个示例:测试人员在传统上主要负责从黑盒角度测试用户界面和软件工作原理。但敏捷领域中的测试人员日渐需要变得更加技术性,考虑开发人员所做的工作。如果他们能够将测试编写为代码,而不仅是从用户界面测试功能,他们会对团队更有用。

技巧 2:更多地专注于协作技能,而不是智囊团

聪明的人组建的团队常常无法得到预期的结果。一组聪明的人不一定就会组建成一个优秀的团队。只有在这些人朝一个共同目标协同工作时,才有可能成功。我看到过不想协同工作的非常聪明的人,他们更喜欢独立工作。您的组织中可能有适合这样一个人的职位,但在敏捷开发和交付团队中可能没有。

此外,还有一个事实是,我们无法在每个项目团队中都配备超级明星。我们需要学习如何在具有普通、可预测能力的人中变得富有成效,而不只是明星编程人员。所以,我在组建团队时寻找的是既能良好协作,又展现出竞争力和自信的人。他们谦恭有礼,因为他们认识到事实上他们无法知晓全部内容,他们需要彼此学习一些东西。

技巧 3:为手头的项目组建规模适中的团队

DAD 描述了 3 种不同的团队级别:经典的小型团队、中型团队和大型团队。当然,DAD 主要针对大中型团队而创建。对于可能有多个子项目同时处理共享组件的较大型团队,一定要考虑各队人马与其各自团队领导如何协同工作。一个问题是,经典敏捷理论建议组建小型、自给自足的团队,假设他们应该能够自行实现完整的解决方案。但在我们的队伍不断壮大时,我们需要从团队外引入其他具有专业技能的人。

例如,在我当前的项目中,我们将十几项技术集中起来实现一个非常大的系统。我们明确地应用了 “通才专家” 的原则,但事实上不是团队中的每个人都能够了解所有这 12 种不同的技术的每个细节。所以我们为团队补充了一些基础架构人员,比如 Linux 专家、两个数据库权威人员以及安全性和防火墙专家。

在像这样较大型项目中,当您过渡到生产环境时,您将必须与(举例而言)您的 DevOps 团队或企业现代化团队合作。换句话说,您的系统不会孤立地存在。我当前参与的项目将与一个现有的系统相集成。要移到生产环境的所有要素都会受到严格的变更控制流程的紧密控制,所以我们会定期与团队外部的这些人互动,以让这些要素正常工作。

DAD 还包含在启动项目时执行某种初始规划的指南,这可能对于让不同团队协同工作很有用。对于较重的项目,您需要在要解决的商业问题和要得到的解决方案方面获得初步愿景。这个愿景可能包含业务案例的总体概述、提议的技术架构、风险摘要以及其他的摘要信息,让利益相关者相信该项目真正有用。

技巧 4:理解敏捷领导原则和团队组织,灵活处理手头的项目

小型团队的敏捷方法(比如 Scrum)解决了这样一种事实,在软件开发中,领导阶层的指挥控制方式(经理创建详细的工作细分结构、向团队分配任务,并告诉他们每项任务要花多长时间完成的方式)存在问题。敏捷方法从业者认识到,实际执行工作的人才是制定这些决策的最佳人选。开发人员确定他们的任务,他们执行自己的评估,他们自愿挑选任务,他们自行分担工作量。在本质上,他们就像一个高效运转、自行组建的团队,没有明确定义项目经理职位。相反,该团队指派某个人作为团队领导,帮助推进整个流程。
DAD 使用了产品所有者 的概念,这个概念直接来自于 Scrum;DAD 事实上完全没有更改这个角色。产品所有者负责确定工作范围、优先级并阐明他们需要完成的工作的需求。作为产品所有者,他们拥有解决方案的产品愿景。但是,参与 DAD 实践的人认识到,对于较大型、更复杂的项目,可能必须向团队增加领域专家来协助产品所有者。

DAD 还有另一个类似于产品所有者的角色,称为架构所有者。团队拥有天才开发人员固然很好,但同样重要的是,让某个人 “拥有” 交付解决方案的架构愿景和负责关键技术决策。架构所有者也可以与团队外部的重要权威人员协作,比如企业 DBA 或企业架构师,以确保开发团队所做的决策不会与企业整体的标准和指导原则相冲突。他或她是项目的技术专家,定期与这些利益相关者合作。

作为自己团队的领导,我大量依赖于架构所有者。我目前的情况是,在一个房间里拥有 25 个工作人员。这是一个比经典敏捷项目人数更多的团队,但这是将一个项目升级为 DAD 项目的不错示例。紧挨着我左侧的是架构所有者,所以我总是可以向他咨询问题,比如:
我们是否有合适的人在参与合适的任务?

我们是否减轻了技术风险?
哪些团队成员需要帮助?我们是否为他们安排一个搭档,以便他们在执行任务时可获得帮助?
企业中是否有现有的技术资产或模式可供我们使用?

作为团队领导,尤其是在像这样的大型团队中,我很难详细地了解每个开发人员是如何工作的。所以我选择架构所有者作为我的搭档,帮助提高团队效率。
从另一方面讲,架构所有者也很重要。架构是项目风险的一个巨大的潜在来源,因为存在超越项目边界的依赖关系,比如生产环境、业务需求、遗留数据、旧有系统等。架构所有者确定要在早期迭代中实现哪些工作项,以尽可能早地减轻这些风险。这种 DAD 实践称为 “风险价值生命周期”,它不同于其他仅依靠商业价值来确定工作优先级的敏捷方法。架构所有者帮助团队理解关键技术风险,以及必须捕获和满足哪些需求才能减轻这些风险,在项目后期,修复这些风险可能非常困难且成本极高。

技巧 5:提防自行组建的团队,尤其是如果团队缺乏经验

自行组建的团队是一个非常美妙的敏捷概念。团队成员最了解如何自定义他们的流程,以保持最高效率。他们可以协作,是因为已学会了如何协同工作。例如,Hal 知道他是否可向 Julie 发送电子邮件,或者他是否需要面对面地讨论以提高效率。在理想情况下,团队拥有他们履行构建所需软件任务所必备的技能。在实践中,自行组建的团队非常适合技术牢固、透彻理解软件开发最佳实践且对敏捷方法有一定了解的人。

对于较新的或更年轻的团队,可能不具备这些条件。他们可能不理解如何针对架构或需求建模解决方案。或者更基本来讲,他们可能不熟悉敏捷方法,不理解不同的实践。

因此,在自行组建团队时,您需要考虑技能和经验成分。技能和经验的缺乏可能导致混乱且散漫的团队环境。还有一种个性特征成分。一些团队成员不习惯于决定他们应该执行哪些任务或按何种顺序执行。一些人可能实际上更喜欢采用更加传统的方式。如果您是团队领导,您必须对这些态度和习惯产生警觉,理解某个人何时需要诱导或引导他们的日常活动。

此处传达的基本信息是,自行组建的团队可以运转,但团队领导让团队自行管理的程度取决于团队的成熟度和能力。优秀的团队领导不会简单地相信团队,全权委托权威专家来完成他们想要的任何事情。相反,优秀的团队领导应该了解团队的进展,密切关注以确保他们朝正确的方向发展。

最后的思考

主流的敏捷理论在向客户交付具有较高商业价值软件方面奠定了牢固的基础,但它可能有点理想化。它并不总是代表 Scott Ambler 和我每天在较大型项目中的经历。我们的目标不是推翻前人的成果,重新发明敏捷方法,因为如果正确实现敏捷方法,那么这些成果是很有用的。我们只是尝试填补所存在的一些空白。

毋庸置疑,对于 DAD,我们没有打算规范化。例如,尽管我们更喜欢在工作项列表中通过用户案例来表示需求,但如果您希望应用用例场景,完全没问题。DAD 是一个框架。您应该选择其中最适合您的敏捷项目需求的技术。

结束语

DAD 可帮助大型软件开发团队成功实现敏捷开发项目。DAD 将来自各种现有的成熟敏捷方法结合到一个框架中,为常见的敏捷方法补充了企业指南。因此,它可帮助具有超过 20 人团队的组织充分利用敏捷开发方法。当组建 DAD 团队时,请记住以下这些技巧:欢迎通才专家,专注于协作技能,为您的项目组建规模适中的团队,理解敏捷团队原则和团队组织,但保持灵活并提防自行组建的团队。

原文来自:http://www.ibm.com/developerworks/cn/rational/agile/forming-dad-teams/

使用特性团队(Feature Team)

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

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

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

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

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

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

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

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

有时候界限是模糊的

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

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

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

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

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

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

向特性团队倾斜

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

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

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

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

打造学习型团队

学习型组织,是指通过营造整个组织的学习气氛,充分发挥员工的创造性思维能力,而建立起来的一种有机的、扁平的、符合人性的、能持续发展的组织。学习型组织取得成效的主要原因在于:它为从高层管理者到一般员工的组织内所有成员提供了自我提升的机会,并具备将有价值的资源进行整合和合理运用的机制。

如果你的团队已经拥抱了团队承诺的理念,减少了对专家的依赖,能够保持一小块一小块的做事情,那么你的团队已经在团队协作上有了很大的进步。这时多数团队会有一种满足感。请不要这样,仍然还有改善的机会。要成为一个真正的高效团队,并领会Scrum带来的所有好处,那么,你的团队一定要主动寻求学习和分享知识的新方法。

有些学习很自然地就发生了——例如用户告诉产品负责人她期望某个功能应该是怎样的,或者程序员发现使用某种具体技术不能满足扩展性需求等。有些学习则需要主动的进行。这是我们现在感兴趣的学习。最高效的团队和他们的领导者在改善学习效率和意义上起着非常积极的作用,而不是被动的等待学习。

把积极的追求团队学习作为项目的目标,要使团队学习能够发生,以下五个条件是必不可少的:

1.设计学习型团队: 在组织团队结构是可考虑到这点。
2.个人有分享知识的方法: 可通过Scrum的5个仪式或社区活动沟通来增强只是分享的方式
3.领导者要强调学习的重要性: 可展示重视学习的事项,领导也要和团队加多接触
4.授予团队激励性的挑战: 要注意激励的方式方法,不要让团队产生出负面情绪,一级级的态度
5.让团队去接受挑战有互相帮助的学习环境: 近朱者赤近墨者黑,接触的环境可以影响一个人的行为和想法,好的学习环境,可以帮助团队更好的学习新知识

注意消除知识浪费:

在一些情况下团队会失去学习的机会,通常为:分散、交接和一厢情愿。导致团队布局分散的原因是沟通障碍和一些不合适的规则制度。团队责任制可以减少不必要的交接浪费。一厢情愿是指在信息量缺失的状况下做出决定,往往带来错误的影响,比如项目的延期和抛弃至少。

小议团队自组织

“自组织”是敏捷中难以把握的一个词,英文是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

在混合型的开发和受限于服务品质协议的bug修正团队中使用敏捷

如今在大多数的软件开发组织中,没有专门的维护工程(SE)团队来关注已发布产品的维护和支持。工程(研发)团队除了完成产品的功能开发外,要花费同样的时间来完成维护任务。然而,支持服务品质协议(SLAs)的维护支付的客户通常都很严格,所以比起研发,维护工程经常有更高的优先权。然后遵循scrum的工程团队由于维护工程问题的大量涌入以及对于迅速解决问题的需求,他们无法成功地递交承诺的功能。在功能开发和修改bug中挣扎反作用于团队士气和工作积极度。
以下基于scrum的选择是由小组成员提出建议来克服在这些情况下发生的问题的。 Read more

自我评估团队

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

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

交流,而不是监督

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