Tag: agile

让非技术人员理解设计

作为技术人员,我们经常需要跟客户、业务分析人员等非技术人员沟通软件设计方面的问题。如何比较直观地向这些非技术人员解释设计、软件质量对项目的影响,解释糟糕设计、不干净代码给项目带来的风险,解释我们必须开始关注软家设计问题?这里有两个概念(metaphor)可以帮助我们达到这一点。

Continue reading

浮潜与水肺潜水

不同形式的分析活动贯穿于项目的整个生命周期:自上而下、自下而上以及先中间后两边。


浮潜潜水员游弋于海水表层,看鱼戏浅滩,望影掠深海。水肺潜水员可以潜过海水表层的深度;他能潜到更深的地方,在一定的区域内研究那些影子以发现鱼类、沉船残骸以及珊瑚的细节。在相同的时间内,浮潜潜水员可以游历更宽阔的水域;而水肺潜水员则在潜游深度上占据优势。成功的项目团队在项目的整个过程中会把浮潜和水肺潜水这两种方式结合起来使用,在特定的时刻明智地选择合适的方法,从而有效地利用了时间。

浮潜是一项很好的技术,项目团队可以用来弄清楚需要研究多少领域,以理解问题和达成目标。往往在项目或者子项目的起始阶段,团队通过浮潜识别出研究范围、目标、利害相干人、研究边界、已知事实以及需要进一步水肺潜水的地方。

当潜水员感觉到一些有趣的东西、陌生的事物或者更深的细节信息需要考察时,他会进行较深的水肺潜水。深度潜水的发现常常会改变浮潜阶段所设定的假设。假如我们发现了某种海产生物,而此前我们并未预料到能在这片水域找到这种生物;那么,我们就需要调查更宽更广的范围,以找出这种生物的繁衍区。

本模式的迹象之一是团队在做广度(浮潜)考察的同时,也会——而不是忽略——针对特定问题进行具体的(水肺潜水)工作。关键是团队在项目的整个过程中应用广度深度究技巧的能力。研究的广度范围识别出可能会对项目产生影响的人、组织、硬件和软件系统。在广度上知晓得越多,就能识别出高风险与高收益的领域,以及如果辅以进一步的深度研究可能大有裨益的领域。

掌握浮潜与水肺潜水技能的项目团队不会因问题域之宽而气馁。团队成员知道自己不需要对整个问题域都进行同样深度的研究。例如,如果他们决定针对问题的某一部分购买已有的解决方案,那么他们的研究只需要深入到足以验证解决方案是否适用于工作情形即可。当他们决定开发自己的解决方案,则他们需要判断这项变动要求多深的研究。他们同样知道某些更深入的研究可以推迟到以后某个更为合适的时间。面对较宽问题域的项目团队在响应变化上面更胜一筹,因为他们可以预见改动所引发的影响。他们对于哪些是自己所知道的、哪些是自己所不知道的、哪些是需要加以探索的以及哪些是可以放在一边的,都是心中有数。他们能够计划如何使用资源以获得最佳效果。

引入浮潜与水肺潜水技术的项目很可能把软件原型、模拟物与上下文建模联合在一起使用。他们也可能使用增量式的交付方法,在项目早期交付价值最高的功能。同样,他们也能够只用一页的篇幅就清晰地解释项目的范围和目标。

本模式的反例是团队要么沉迷于细节(“我们只做水肺潜水——懦弱无用的浮潜免谈”),要么惧怕细节(“我们是浮潜潜水员——换句话而言,大海深处有怪物”)。并且,当人们谈论“更高层次”和“细节”就好像它们互不相关、了无牵连的时候,也属于本模式的反例。

优秀的开发人员不会画地为牢:他们既可以浮潜,也能水肺潜水。他们依据自己需要考察的对象来选择技术。侦察的时候,浅层潜水就已足够;但如果审察,就需要更深的潜水了。

有时,仅仅用脚趾探探水就足以知道不能跳下水。

浓浓的特性汤

    “体面汤、浓又黄,

盛在锅里不会凉!

说什么山珍海味,哪儿有这样儿香?

半夜起来喝面汤,体面汤!

——刘易斯·卡罗尔(Lewis
Carroll
),《爱丽丝漫游仙境

产品夸耀自己繁多的零碎特性,其中很多对于解决客户真正的业务需求几乎毫无帮助。

在一开始的时候,一切都显得那么美好。市场部有一个来自于客户的请求——添加额外的下拉菜单。然后,在产品中添加一个输出接口的需求来了,产品经理想要加上一份新的分析报表,DBA要求在数据库里增加一个新字段以改变背景的颜色。所有这些需求以及其他更多的需求,都交由开发人员负责加进到产品里面。随着需求的不断添加,产品的特性集不断增长,但过了一段时间之后,每个人——市场部、客户和开发团队——对如何将所有这些碎片整合在一起、这些碎片如何帮助实现业务目标,失去了理解。曾经带着明确目标出发的项目变成了难以下咽的、由各种无关特性炖成的一锅汤。

情况变得更加汤汁淋漓,因为感兴趣的各方都从不同的角度来看待产品的需求,根本不存在共同的、连通的思路。市场部从营销的角度把需求打包成一组一组的特性集合,也不管它们在功能上是否内聚。开发人员则按照自己所使用的实现技术对需求进行归类。各个客户也只是从他个人工作的角度出发单独地对需求进行考虑。这些离散的需求所带来的影响就是各人谈论进度或者对变更做出决定的方式都不一致。按照产品版本的主题再取折衷已不可能,因为根本就不存在一致的主题;相反,产品变成了混杂着各种玄机的大杂烩。

为什么如此多的产品最后以沦为特性汤收场呢?这一切都始于需求的源头——人们。

人们很自然而然地会认为自己的需求才是最重要的。同一个组织中的不同部门,或者不同的客户,都想获得属于自己的、与众不同的特性,于是提出的需求根本不顾及产品在整体业务上的一致性也就不足为奇。而这,就是分析师的工作了。

当零散的需求来了之后,分析师需要将它们与受之影响的业务流程映射起来。这种映射提供了一种方法——向不同的人们展示建议的变更对他们的工作可能产生的影响(有时非常令人惊讶)。这种分析让分析师获得了基本的理解,从而进一步发现人们真正需要的——以及变更是否提供了真正的好处,抑或仅仅是另一个滴入汤中的特性。

特性汤的另一个来源是设计人员在面对一项新需求的时候,不去追究其与既有产品在整体上的关联,就将其加入进来。设计人员应该发问,“它是否属于已声明的范围?”“与既有产品的接口是什么?”“它是否重复或者搞乱了已经存在的东西?”

在解决这些问题上的重复失败导致产品变成了一堆离散碎片的组合。需求是基于离散的特性,从本质上这意味着项目对于“什么是属于范围内的”以及“什么是超出范围的”没有客观的定义。因此,额外的需求就很容易从不同的来源渗透进产品里面——事实也确实如此。产品变得越发分离崩析,它也就越发难以评估,做出的变更就越发难以前后一致;一路螺旋直下,回天无术。

避开特性汤的组织有着很多的共同点:

  • 尽可能不留余地、尽可能早地定义项目目标和非项目目标。

  • 声明项目范围,并以精确定义输入/输出数据的形式时刻保持更新(参阅第24项模式,“白线”)。

  • 拒绝那些对声明的目标没有积极效应、而又明显超出项目范围的需求——进一步锤炼、巩固了钢铁般的意志。

  • 新需求的添加遵照被核准的、可追溯的变更管理流程进行,同时使用项目声明的目标对它们进行评估。

避免特性汤得靠纪律。时刻牢记着是你们——整个项目团队,而不是零散特性的请求者——将会身陷浓汤:这绝对划算。

同事预审


在如今大部分的组织里面,是否给申请技术职位的人提供工作机会——这个最终决定权属于管理部门。经理们雇人,经理们裁人:一切都天经地义。然而在某些组织里面,这些技术人员能否得到工作机会却是取决于——至少部分取决于——他们将来的同事。这种同事预审的最终结果只有一种:当经理们让技术职员拥有发言权的时候,每一个人——申请人、职员和经理——都会和盘托出自己的想法。

招聘流程的前期阶段基本上没有变化:通常由第一线经理对申请人的材料进行最初的筛选。经理也许会要技术方面的高级职员先审阅简历,把所有的申请人归为“下一步”和“不,谢谢”两类。经理也许会给那些简历看上去非常华丽的申请人拨打电话聊一聊,做一个初步审查,决定邀请哪些人过来现场参加面试。获邀的申请人会被告知他将和团队在一起呆上36个小时。一旦众多的同事参与到招聘的过程中,面试的当天往往非常的漫长。

在抵达公司并与经理寒暄过后,申请人就随同各位团队成员开始一系列的面试。每轮面试的会谈时间从30分钟到90分钟长短不等。

虽然每位参加同事预审的面试官从申请人身上得到的信息相同,但每个人都会使用不同的方式调查。很显然,每个人都希望对申请人的知识、技术和能力做出评估。所以,针对招聘职位的类型不同,从团队的角度出发也许会要求申请人编写一些代码,或者创建一组测试。但是,每个面试官都会再以个人的角度去评估申请人,他会问自己:“我能和这个人一起工作吗?”“他能适合我们这个团队吗?”“他会让我们团队变得更强,还是更弱?”

此外,每个面试官将以自己在团队之中担当的角色去评价申请人。举个例子,如果申请人是一名开发人员,相较于团队里的开发人员,身为测试人员的面试官就会提出不一样的问题,以挖掘申请人的个性特征。

每个面试官也会根据自己的以往经验去评价申请人,问自己这样一些问题:“这个人展现出的技能与解决问题的方式,是我最为欣赏的吗?”“这个人在多大程度上让我回想起曾经合作愉快的同事,又在多大程度上让我回想起无法合作顺畅的同事?”“这个人是不是像他表现出来的那般优异,又抑或他是在假装如此?”面试官背景的多样性,使得团队可以从多个视角和价值取向来甄别将来的同事。

在把申请人交给下一轮的面试官之后,这一轮的面试官向经理——或者面对面地交谈、或者通过邮件,又或者拨打电话——就他对申请人的印象和意见发表个人的观点。每位职员都需要针对“假如由我来裁决是否雇用这个人”这个议题投下自己的一票。

如果面试一切进展顺利,申请人最终会回到经理这里,而此时经理也已经知晓了所有面试官对该申请人的看法。经理现在要从他自己的角度出发来面试申请人,然后告诉申请人是否得到了工作机会。即使其他的面试官都表示认可这名申请人,经理也可能会由于某些原因决定不对其提供工作机会。但是,如果团队的大部分成员都对该申请人倒竖起了大拇指,那肯定是没有理由再雇用此人了。

当团队在招聘过程中真正拥有话语权的时候,此时就出现了多赢的局面:

  • 当前的团队成员是赢,因为新员工加入团队的时候,大部分的团队成员都已经跟他见过面——实际上已经接受了他;不被职员接受的那些人是绝对不可能跨过那道门槛的。

  • 申请人也是赢,因为他处在了更有利的位置来决定是否要加入这支团队。他可以接触到未来的同事,而不仅仅是老板。他可以询问工作的真实情况,同时也可以感知公司的文化。

  • 经理是赢,因为他可以借鉴整支团队在技术方面对申请人做出的评价,而不是仅仅凭借自己的揣测。他也知道团队在一定程度上已经接受了这个“新员工”,而且团队对他个人的成功也非常重要。

  • 最终,团队作为一个整体也是赢,因为团队成员在参与同事预审的过程中,可以向其他人学习。在阅读其他人对申请人的评价时,团队成员能发现其他人使用的问题和标准,而他们可以在以后的面试中把这些派上用场。经理也能对自己团队成员的思维方式有更深的了解。

从经理的角度上讲,同事预审在雇用团队领袖的问题上面同样有效。为什么不邀请团队里的一些成员去面试未来可能成为他们老大的人呢?

不管申请人是开发人员、测试人员,抑或是经理,寻找到一位真正合适的人选从来都不简单,但往往又很重要。这是团队参与的项目。

只有完成本垒打或者击球成功,管理才值得嘉许。”

——卡西·史丹格(Casey
Stengel

一叶知秋

(一)
与客户吃饭。客户抱怨,“我司人员流失大,无法建设团队文化。”我说,“以你司推行的工具为例,其思路就是把团队定位于低级、傻瓜式的水平。那么,超出这个水平的人离去、不足这个水平的人加入,不正是延续并巩固了这种傻瓜式的团队文化么?”

(二)
工具或许无关好坏,但要警惕的是工具传递的创建者的价值观。推广工具遭遇困境,原因就在于推广者的价值观与接受者不合,双方价值观上面的认同没有到位。如果以外力强制推行,甚至上升为价值标准,孔夫子曰:始作俑者,其无后乎?

玩的就是心跳(Adrenaline Junkies)



电话响了。

我们想这周完成需求的规格说明书。你能过来,看看可以做些什么吗?”
规格说明书怎么了?”
我们很急,所以新招了许多人来撰写规格说明书。我们觉得他们完全不清楚自己在做什么。”
如果由我们来指导他们编写需求,效率不是更高么?”
但是我们这周就需要规格说明书。”
好吧,我明天过来。”

两个小时之后:

你能过来看看我们评估的工作量吗?”
规格说明书怎么办?”
我们没时间了。我们就照现有的需求规格说明书进行。老板要求今天就把评估的工作量交上去……”

你可能已经识别出这一类“玩的就是心跳(Adrenaline
junkie
)”型组织的特点了:优先级总是变化不休;所有事项都是“昨天”就要;总是没有足够的时间交付项目;紧迫的项目却源源不断。每个人都忙得焦头烂额……不可开交。

这些组织里面的人不会从战略层次上思考问题,只是按照紧迫程度来完成工作。除非“忙乱指数”非常高,否则项目通常都会被忽略——尽管它承诺将带来显著的长期优势。人们会一直对其不闻不问,直到它突然(绝对出乎意料地)变得非常紧迫。“玩的就是心跳”分子相信最好的工作方式不是谋定而后动,而是竭力追赶时间。

这种组织文化在令人绝望的紧迫性和高效的绩效之间划上了等号。如果身陷这种文化,你很难不受感染:紧迫性是被鼓励的。那些为了某个短得可笑的期限而加班到深夜的程序员被视为英雄(根本不在乎他们交付的程序质量)。每个周末,团队的所有成员都照常上班,以保持他们的工作量:这样做的团队比不这样做的团队更受人赞许。此外,如果你不是一直都过度加班,或者发疯一般忙碌,你就会被贴上“不是自己人”的标签;你不是保障组织运转流畅的大忙人之一。非英雄行为绝对不能被接受。

绝大部分的“玩的就是心跳”型组织至少存在一个瓶颈,就是那位英雄。他包揽了所有设计的决定,是全部需求的唯一来源,或者一个人决定框架的方方面面。他扮演了两个角色:一是让自己表现得比极少数人所希望的还要忙;二是引发了决策阻塞的局面,这种局面一旦形成,就会导致组织的其他部分更加忙乱。

大部分的“玩的就是心跳”型组织满腔热情地拥护客户服务的理念:他们把值得赞赏的响应和对紧迫事件的响应弄混淆了。当客户提出了一个请求,不管是否存在
潜在的利润(甚至有效性),该项请求都会立即被转化成一个项目,而且通常会设定一个很短的截止日期。(更多讨论,请参阅第
38项模式“Project
Sluts”
。)这个新项目自然会加重本已超出负荷的英雄们的工作,新的繁忙出现了——所有的这一切无休止地引发了让组织变得非常、非常忙碌的需求。很多这一类的组织都(错误地)认为这就是敏捷的全部。

玩的就是心跳”型组织倾向于断然行动,而不是三思而后行。这样导致的结果就是大部分工作都处在不断变化、无法固定的状态,没有什么可以固定下来,或者保持较长的时间。这种不固定的状态一直延续:需求规范不固定——没人真正清楚要构建什么;设计和计划也不固定——它们很可能明天就会改变。紧迫性是唯一的标准,没有人尝试按照重要性或者工作价值来对工作排定优先级。

对于“玩的就是心跳”型组织,回春妙手是不存在的。除了戒除再玩心跳,而且解雇经理,雇用那些明白“组织只有不再忙于处理突发事件才最有效率”的人,也别无良策。这样的人事变动或许根本不可能被采纳,毕竟高层领导,通常是CEO希望看到组织长久地保持匆忙的状态,因为工作匆忙让人生出一种生产率健康的幻觉。而且,如果公司的经理们是“玩的就是心跳”分子,项目团队也不会相去太远。

玩的就是心跳”型组织并不是总会遇上失败,其中有一部分在很多年的时间里面一直保持着匆忙的节奏。但是,它们都不可能构建重大的东西——那需要稳定性和计划。亢奋型行为不可能扩展——由一些相关的人在没有方向,也没有战略指导的前提下,光凭借非常、非常忙碌地工作所能达到的效果太有限。

实事求是地讲,任何组织内都会遇上紧迫的事情,也会有一些角色需要去关心紧迫的任务。但是,不是所有的事情都是紧迫的,也不是所有的角色都要关心紧迫的任务。除非化紧迫性为优先级和约束,否则,这种“玩的就是心跳”的治愈希望是微乎其微了。

保姆型项目经理

一个优秀的项目经理要对手下员工的能力了如指掌。他分派任务、制定计划,在可用的技能和任务本身的要求之间寻求最佳的契合。这是显而易见的。还有一些项目经理们更进一步:他们提供一个工作环境——不仅是技术性的,而且是社会性的——让人们可以最大限度地使用自己的技能,并且提高自己的技能。这些项目经理确保自己的员工拥有完成任务所必需的工具。这些项目经理鼓励提问,并且乐意、与员工辩论;他们给每位团队成员设定最合适的挑战;他们在需要的时候提出批评;他们建设一个人人乐于工作的场所;而且他们采取必要的调整以保障各项事宜运作良好。简单地说,好的经理们培养他们的员工,就像保姆培养她们照看的孩子一样。

一个保姆,在传统的英式文化中,受雇于某个家庭照看对方的孩子。保姆——通常被训练成教师、护士和厨师——对孩子的体格、心灵、社交、创造性和智力发展都要负责。在每天的日常活动中,保姆要确保孩子远离伤害,保证孩子们得到了足够的新鲜空气与锻炼、食用有营养的食物,并且增进对世界的理解,学会更多在世界上生存的技巧。除了照看孩子,保姆还需要与孩子的父母就他们在孩子成长方面的顾虑进行沟通,鼓励孩子的特殊天赋。保姆创建出一个可以承担风险和学习的安全环境。

当经理们拥有这些与保姆类似的才能,他们就能通过鼓励和培养员工的天赋,从员工那里获得更多、更好的工作结果。

迄今为止,我所共事过的最好的经理是Peter
Ford
。这再明显不过了,比如他确保协调好我们每个人的要求,以做好个人的手头工作。举一个例子,我们有一个开放计划办公室——不是最好的思考环境——而且,他设法为团队弄到一些消音的屏幕,并预订了几间“静室”。所有的这些,以及他为我们做的其他事情,牵涉了我们所不知情的协商和政治。他鼓励我们阅读,在系统开发的时候讨论新的想法。他为我们团队购买书籍和杂志,并安排时间让我们聚在一起讨论。当我们觉得不开心或者不舒服的时候,他会注意到这一点,跟我们交谈,帮助我们。他保护我们不受组织其他人、事的干扰,但如果他对我们不满意,他会让我们知道。他的办公室门很少关闭。Peter就是我们的保姆。

——SQR

如果注意到如下一项或者多项情况,你能发现在你所在的组织已经有一些“保姆型”经理:不必预约就能见到你的头,或者不必在琐碎和生厌的管理工作上花费太多时间。周围是开放的氛围;人们畅所欲言,互相学习。这种经理认为培训或进修非常必要,而不是视为奢侈烧钱。他们还会抽出单独的时间(比如早晨咖啡闲谈或者周五下午阅读探讨),让大家在一起讨论新的想法。

在任何由人组成的团体里面,总会有流言蜚语、小道八卦,和一些磨洋工的情况。然而,在被经理细心呵护的办公室里面,这类浪费时间的事情会被最小化,因为经理确保团队成员对于实际进行中的事情都非常清楚。人们不需要去靠打探小道消息以得知组织内发生的事情。与之相反,他们觉得自己充分知情和受到信任,把精力都放在自己的本职工作上面。

一个类似于保姆的经理会把他自己看成是工作的催化剂。传统保姆的工作满意度来自于看到孩子能力的发展,“保姆”型经理的工作满意度则来自于看到每个团队成员在个人角色方面得到发展、生产率得得提高,并对自己工作更加满意。

这个模式的反模式有:经理把工作重心放在政治上面、放在流程上面,抑或放在逢迎更上层领导上面;绘制、调整PERT图和甘特图比与团队成员交谈更重要;还有一些经理承担了太多的实际开发工作,而不是去解决好团队的需求。

你们组织如何看待这样的经理角色?他们会因为“催化”了工作受到赞扬么?你们是雇佣“保姆”,还是“管理者”?

欢乐的鼓掌会议



高涨的士气永远象征着组织的健康。与之类似,低弱的士气则说明肯定有什么地方做错了。有一种管理理念就是奉这种关系如圭臬,试图从相反的方向来利用这种关系。逻辑是这样的:把士气鼓舞起来,其他美好的东西也就跟随而至。

啊哈,那如何鼓舞士气?尤其是如何在不增加时间、精力和花销——虽然它们是改善事物的必要投入——的情况下鼓舞士气?这是个难题,但别以为人们就不会去尝试。于是,才有了这样的谚语:“打气,打到士气提升为止。”

鼓舞士气的常见举措是仪式性的会议。会上老板笑容可掬,站在集合在一起的团队前面,
大开言路:“让我听听你们的心底话,”他大度地告诉大家。“任何事情都行,即使坏的消息和尖锐的问题。”注意这里的腔调和背后传达的信息:没有什么好隐瞒的,我们是一个欢乐的大家庭。(欢乐,该死的,欢乐。注意了。)

我知道有一家公司,这样欢乐的鼓掌仪式被称作全体会议。之所以称为全体会议,是因为所有人都获邀参加。但是一旦哪位勇敢的人果真举起手,向CEO提出尖锐的问题,最后的结果却根本不是他所预想的。CEO咕哝了几句,就迅速找了个台阶下。在当天的晚些时候,这个冒失的提问者就被他的直接上司叫去训了一顿,打消其尖锐问题受到欢迎的幻想。从此以后,在私底下大家都把这种会议都称为一言堂,因为没人会再次举手发言了。

——TDM

一旦你理解到老板并不是在征求你们的发言,而只是你们的同意的时候,你就能清楚地知道什么在上演:欢迎参加欢乐的鼓掌会议。

浅谈软件开发的权利和权力

在日常生活中,有各种各样的法律规则和道德准则来约束、指导行为。比如在初次的商业合作中,双方都会选择制定一份详尽的合约来规约双方,包括双方拥有的具体权利、以及单方出错时对方享有的权利等。软件开发,在商业上面也必然会有详尽的合约,处理的是两个组织之间的利害关系。但是,软件开发同时作为紧密involve商业客户与开发团队的活动,正如Alistair Cockburn把它比喻称为game——由客户、管理层和开发人员共同play的game,其中也需要由参与play game的各方利害人来共同制定规则,让大家都能玩得开心、尽兴,甚至长久。这样,围绕着多赢长赢的出发点来play game,就同样需要这样一份“权利法案”,对开发过程中的三方利益利害人的权利做出基本的原则上的规定。在敏捷软件开发方法中,特别是极限编程中,就存在这样一份“权利法案”。

其实,我一直不知道原来极限编程里面还存在这样一个“权利法案”,问一些朋友,也有不清楚的。正巧,在翻译《ThoughtWorks Anthology》中的“What is an Iteration Manager Anyway?”一章时,原文写到:

the IM(注:Iteration Manager) must facilitate, enforce, and defend the team member’s rights. For many agile teams, these rights come from the developers’ Bill of Rights.

多亏一位资深同事透明指出,其中的Bill of Rights就是前面所讲极限编程中的“权利法案”,并给出了出处Extreme Programming ‘Bill of Rights’。该文由Steve Hayes发表,对play game的客户、开发人员和管理层都规定了各自的基本原则,试图对各方都定义一份清楚的职责和权利范围,减少各方因为认知不同造成的混乱。

Customer rights

  • The customer has the right to plan on a large scale with costs and options.
  • The customer has the right to set development priorities weekly.
  • The customer has the right to see progress in the form of a working system at the end of the first week, and to see a little more functionality every week thereafter.
  • The customer has the right to updates of the schedule, good or bad, as soon as the information is available.
  • The customer has the right to change his/her mind without paying exorbitant costs.

Programmer rights

  • The programmer has the right to estimate work and have those estimates respected by the rest of the team.
  • The programmer has the right to honestly report progress.
  • The programmer has the right to produce high-quality work at all times.
  • The programmer has the right to know what is most important to work on next.
  • The programmer has the right to ask business-oriented questions whenever they arise.

Manager rights

  • The manager has the right to an overall estimate of costs and results, recognizing that reality will be different.
  • The manager has the right to move people between projects without paying exorbitant costs.
  • The manager has the right to monthly updates of progress, and to help the customer set overall priorities.
  • The manager has the right to cancel the project and be left with a working system reflecting the investment to date.

从内容来看,这份法案给客户、开发人员(这里的开发人员包括项目团队中主要工作是与软件开发相关的各种角色,比如BA/DEV/QA)和管理层提出了很高的要求,但也在一定程度上让各方认清自己享有的权利。各方都有自己的权利,也就是在play game时可以行使的权力,让game的规则尽可能摆出在桌面上面,减少对规则的误解。但是,在具体的game中,各方毕竟不是完全对等的,如何避免对权力的误用,使各方保持一个清晰的远景?

这些天读Scott Berkun的《The Art of Project Management》,其中提到权力的来源和挣得颇有意思。拨去笼罩在“权力”一词上面的褒贬,Random House College Dictionary里对“权力”的解释是:

权力(power,名词):做事或行动的能力,进行或完成事情的能力。

Scott指出权力通常分为授予型和挣得型,授予型来自于阶级体制或者职衔,而挣得型则必须由效能和行动耕耘而得:“权力在团队中不断流动、改变方向,在不同时刻对不同人会有辅助或阻碍。因为权力在使用前纵使晦暗难明,谁有什么权力,很容易搞混”。Scott把权力误用定义为“只要无法为项目及参与项目的人提供利益,任何行动都是权力误用”,并指出“因为权力来源是自然的,而使用权力以影响和推动决策则是团队工作的副产品,这些事情本身并不邪恶”。如何防止权力误用?Scott也指出“最佳方式就是大量依赖项目远景所定义的目标,借此推动权力的应用。”

 

AgileChina 2009: Pragmatic Agile [转]

AgileChina 2009大会官方网站

由在敏捷领域最具有影响力的技术社区InfoQ中文站、敏捷方法论的领导厂商
ThoughtWorks共同主办的敏捷中国技术大会(Agile China
2009),将于9月11日~12日(周五、周六)在北京举行。届时将有超过500人来自电信、金融、互联网、教育等行业在内的高级软件开发人员、项目管
理人员等参加。本次大会将特别邀请敏捷宣言缔造者、敏捷编程(XP)方法学创始人Kent
Beck,敏捷开发权威人士、敏捷宣言的创始人之一,Dave Thomas,敏捷宣言签署人之一Steve
Freeman等国际敏捷领域专家,以及在团队中成功应用敏捷的阿尔卡特、赛门铁克、诺基亚-西门子、华为、腾讯等公司的项目负责人参与此次大会并分享他
们的心得。

敏捷中国技术大会(Agile China
2009)是国内敏捷技术领域最高水平的大会,本次大会将由InfoQ中文站负责大会策划、营销和项目实施。InfoQ中文站在今年4月已成功举办了
QCon全球企业开发大会,邀请了国内外30多名讲师,超过550位架构师、技术总监、项目经理和高级工程师参加了本次大会,大会及其运营团队获得了空前
的好评,并誉为国内“技术含量最高”的大会。而今年的敏捷中国技术大会,也将一改往年的风格,参会者以高端开发者和技术管理者为主,融合管理和工程实践,
推广全面敏捷之路。

会务咨询: 010 – 89880682 agilechina@cn.infoq.com

赞助咨询: 010 – 89880682 sponsor@cn.infoq.com

郑重声明:本文转自熊节的“透明空间”,原文地址:http://gigix.thoughtworkers.org/2009/7/5/agilechina-2009-pragmatic-agile,一切权利归原作者所有