为什么你的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

DevOps中文名: 开发自运维

谜面

在实践和推广 DevOps 的过程中, 当对着客户吐出 DevOps 这个词之后, 收获的往往不是大腿一拍热泪盈眶, 而是一脸困惑欲言又止想问又没问的场景. 在一番解释后, 到团队中落地的时候, 往往又单独拉几个人出来, 划了个圈说这是一个 DevOps Team. 这类做法背离 DevOps 的初衷. 背后的原因很多, 但一个浅显却影响深远的原因往往被忽略, 就是 DevOps 这个名字本身.

DevOps 目前并没有中文翻译, 对于中国人来讲, 即使直觉的望文生义也无法产生. 当几番了解知道是” Development” 和” Operations” 的拼接之后, 对应的中文是”开发运维”, 依然一头雾水不明所以. 而由于” 开发”和”运维”目前是常见的两种角色, 两个团队, 而 DevOps 需要新的技能和工具, 因此把 DevOps 作为一种新的角色, 成立一个新的团队, 就自然而然了.

开发自运维

语言的边界就是思想的边界. 一个精确表达概念的词汇将阻止误解的产生. TDD 也好, Pair Programming也好, 虽然实践本身争议不断, 但其含义却少有误解. DevOps 对于英语母语的人来说或许精确表达了它的意思, 但对于中国的开发团队来说, 带来的只有困惑.

开发自运维” 是我推荐的 DevOps 中文翻译. 它依然没有反映全部的含义, 甚至暗示着不再需要运维团队, 但它至少从字面上就阻止一件事: 成立专门的 DevOps 团队. 想想吧, 把几个人弄出来, 说你们是”开发自运维”团队, 这从语义上就说不通啊. “开发自运维”从字面上就意味着运维是开发团队内置的责任, 这也符合 DevOps 运动的初衷.

历史即未来

在高度不确定性的产品创新中, 对市场的响应速度越来越快, 开发自运维是一个趋势, 可以缩短交付时间和对反馈的修复时间. 这种趋势的前一波浪潮, 则是”开发自测试”/“开发自设计“, 而下一波运动则极有可能是”设计自开发”.

”开发自测试”已经接近成功而即将成为过去式, 可最初也曾经面对”开发”和”测试”天然是两个团队这种概念而阻力重重. 并没有一个像 DevTest 这样的运动来指导开发和测试的融合, 而是敏捷推行的”全功能团队”帮了忙. 而最终的结果是并不会取消测试这种活动, 甚至依然有专职的测试人员, 但相当一部分测试活动被”开发人员自测”涵盖了. 对照历史, 我们有理由相信, “开发自运维”并不会取消运维这种活动, 甚至依然会有专门的运维人员, 但相当一部分运维工作, 将被”开发自运维”涵盖.

“开发自设计”几乎从未引起过困惑和质疑. 事实上无论是 PC 时代还是 Mobile 时代, 大量软件都是个人能力的结晶. 这里面的制约因素是开发能力而非设计能力. 即使对企业应用开发, 架构师, 交互设计师等也都算作开发团队成员.

而”设计自开发”则已初露端倪. “心声”是一款帮助听障患者与他人沟通的 iOS App, 由 ThoughtWorks 设计师朱晨独自设计并开发. 随着对市场响应速度的追求, 对不确定性快速验证的追求, 设计师们发起了”Lean UX” 等工作方式, 而对开发工具的掌握, 将极大提高其产品设计和验证效率. 开发工具及平台朝着简单易用的方向发展, 也会助设计师们一臂之力.

Share