18

忘记敏捷

作者:baiyuzhong 分类:选题策划, 高端视点 4 Comments »

文/熊子川

瓦沙奇山下那段著名的敏捷宣言,至今已近十年。似乎在不经意之间,敏捷已经被视为CMM之后又一次软件开发领域的浪潮,不论业界报道或者坊间传闻,都不约而同地将敏捷视为一个时代的开始,与之同存的是那些未尝或浅尝敏捷者的各种质疑和争论。

当敏捷在介于自发与非自发中间演变成为一种近乎“革命”的运动,围绕在它身边的躁动就不曾停歇,对于细节的争执,对于方法的固执,让我们更多地为敏捷的未来忧心忡忡。我们担心的是,如果敏捷只被认为是实践和方法集合,那么必然有一天在它某次失效或者迫于压力无法延续的情况下,便会被开发团队自然而然地抛弃,他们要做的也只是耐心等待下一次所谓的“革命”。

这时往往被忽略的是第一个要问的问题——为何敏捷。作为从汽车产业精益制造理念衍生出来的敏捷,到底为何产生?敏捷的萌芽和发展与精益理念的传播过程有何共同之处?敏捷将如何发展?当敏捷风潮过后留下什么?只有当这些问题一一被深刻解答和理解,才能让敏捷实践忘记敏捷,真正的敏捷基因才会被持久留存。 阅读全文 »

标签:
阅读:10,639 次
15

Scrum的故事

作者:baiyuzhong 分类:IT名人堂, 坊间人语 6 Comments »

2001年2月,17位敏捷先驱齐聚犹他雪鸟度假村,起草《敏捷宣言》的时候,Scrum只是众多方法中不太起眼的一个。十年之后,Scrum却成为最流行的敏捷方法,几乎成为敏捷的代名词。

本文来介绍下Scrum的两位创始人——Jeff Sutherland与Ken Schwaber。

大家可能不会想到,Jeff Sutherland的第一份工作居然是美国空军战斗机飞行员,还曾于1967年获得了“壮志凌云”称号,完成过100次飞越北部越南的作战任务。服役后期,他到斯坦福大学拿下统计学硕士学位,并在美国空军学院教授数学统计学和概率学。11年军旅生涯结束后,他成为了科罗拉多医学院的教师并获得了博士学位。在诺贝尔化学奖得主莱纳斯·鲍林的赞助下,他以放射学、生物学及预防医学助理教授的身份参与了维生素与癌症研究中心的创立,担任八年国家癌症中心的主要研究员,负责科罗拉多地区所有癌症患者的数据统计和IT方案与研究,整合了国家注册、临床试验、流行病学研究和癌变的超级计算机数学模型。1983年,他进入了一家遍及北美、经营着150家银行的公司,职务为先进系统副总裁及ATM业务部总经理。此后,Sutherland先后担任了11家软件公司的CEO、CTO或者工程副总裁,积累了丰富的软件开发经验。 阅读全文 »

标签:
阅读:37,158 次
14

文/方坤

作者结合切身经历,展示了他之前所在团队软件项目延期的种种原因,而其中印象最深刻的是各种人事纷扰乃至于勾心斗角。

六年前,毕业未久的我在一家外企工作,我所在团队开发的软件项目在交付到集成测试组时因种种原因延期一周。这本身根本不是什么大事情,但其间各种人事纷扰乃至于勾心斗角却着实令我印象深刻。

公司

我的老东家是一家大型跨国电信设备开发商,曾具有辉煌的历史。我还记得在公司110周岁的生日庆典上,一位高管致辞说:“110年,这不是奇迹,是成绩”,令人不胜欷歔。遗憾的是,公司在.com泡沫中遭遇重创,一蹶不振。时任CEO为求摆脱困境,打起了人力成本的主意。当时,公司在美国雇用一名工程师的综合人力成本接近中国的2.5倍【注:工资只是其中一小部分】。至于法国,成本比美国还要略高一些,而且不要忘了,人家可是35小时工作周。大家都是聪明人,很快就看到端详:公司正在法国裁员,将项目转移到中国。

depres5_副本

令人尴尬的是,我所在的中国团队恰好就在与法国团队合作。这一项目最早完全在法国,此后几年时间,中国团队大规模扩张人手(我就是这样进来的),将项目模块逐一从法国团队手中接过来。刚开始,法国工程师将原先的模块移交中国之后,便转而从事其他项目或职位,谈不上什么个人损失,双方共事可谓融洽。后来可就不是这么回事了。有一次,两位中国工程师去巴黎接手一个项目,一位法国工程师负责培训,为时2~3个月。在这位法国老师兢兢业业的帮助下,两位中国工程师成功掌握整个模块,按期于圣诞节前夕归国。告别巴黎时,没有一个法国同事去跟他们寒暄话别—那位法国老师被裁掉了,他的最后一个工作日恰好就在两位中国工程师离开的同一天,法国同事都去送他了。 阅读全文 »

标签:
阅读:23,421 次
14

文/路宁

敏捷已经做得很好了,还需要研究精益吗?

精益对敏捷软件开发起着补充作用:

(1)精益理论体系完备、不落俗套、而且并不复杂,它从另一个独特的视角解释了敏捷实践和原则,让人耳目一新,也适合指导各项工作。

(2)丰田生产方式和精益中的很多工具和概念可以很好地应用到软件开发领域,补充敏捷的工具集。比如看板,其“控制在制品数量”和“拉动”的特性就非常值得敏捷的“故事墙”借鉴,可以有效地加强故事墙暴露问题的能力。价值流分析方法对于发现软件开发过程中的浪费和改进点很有帮助。PDCA(Plan-Do-Check-Act)改进循环和A3报告对于开展一个个的改进活动是个不错的指导思路。“内建质量”、“停止生产线”的做法和敏捷的测试驱动和持续集成不谋而合。“现场管理”和“自组织多功能团队”也正是敏捷推荐的做法。如此种种,举不胜举。

(3)精益被应用的范围要广的多,尤其是其在部门、组织及产业链上推广的思路有助于敏捷向部门、组织及合作伙伴间推广时借鉴。

采用精益是因为Scrum等方法已经被说得过多,作为一种新的管理风尚而吸引眼球? 阅读全文 »

标签:
阅读:9,776 次
13

敬业,功夫在诗外

文/万兴软件副总裁 刘伟

敬业有两层含义。一是个人层面,头悬梁、锥刺股,王国维读书三境界之“为伊消得人憔悴”,都是个人层面的敬业。二是组织层面,即营造一种敬业的组织氛围。一个人原来并不“好好学习”,到了你这里,很自然地就“天天向上”了,这就是组织层面的敬业,“随风潜入夜,润物细无声”。

公司不同的发展阶段,对敬业的要求不同。初创阶段,员工比较少,创始人冲在一线,公司出不起太多钱请精英,选人原则是“敬业第一,能力第二”,待遇甚至达不到行业平均水平,但大家愿意干,在方向正确的前提下,一般就能壮大。发展阶段,队伍扩大了,创始人在后面激励大家干,公司有实力请得起高手,选人原则演变为“能力第一,敬业第二”,但前提是敬业能够上升到组织层面,形成勤奋、努力的组织氛围和土壤,于是即使吸引大批人才加盟也不会冲淡原来的创业文化,继续保持激情和活力。

我们团队一直保持着旺盛的战斗力,勤奋努力的敬业精神常为投资者称道。能做到这些,仅靠高层的榜样作用是不够的,公司层面的敬业问题,还是要从公司层面解决。 阅读全文 »

标签:
阅读:15,603 次
09

1975年,美国罗彻斯特大学纽约分校,一组研究员正在做一个名为RIG(Rochester”s Intelligent Gateway)的项目,它由Jerry Feldman主持设计。RIG的目标是给所有本地以及远端的计算设备(比如磁盘、列印机、磁带、绘图机等)提供一组统一的访问方式,其作业系统称为Aleph。为了实现所需要的功能,Aleph的内核主要构建了一个进程交互(Interprocess Communication,IPC)的机制。RIG的各进程,只要设置了目标端口,就可以彼此间发送信息。RIG项目没过几年就被判了死刑,主要是缺少很多有用的功能,比如端口没有保护机制,一次最多只能发送2KB大小的信息(受硬件限制),也没有很好的网络支持等。不过在20世纪70年代,这个系统依然代表着当时作业系统设计的先进水平,比如除了进程交互外,每个进程还有内存保护的功能,这足以让20世纪90年代末都没有做出内存保护技术的Apple公司汗颜。

ref_05tevanian

该项目后来失败了,随后在1979年,RIG的Richard Rashid博士毕业到卡内基-梅隆大学当教授,开始做Accent项目。它是一个网络作业系统,于1981年4月开始活跃开发。受RIG的影响,Accent系统的亮点也在于可以使用IPC,而且解决了很多RIG的不足。比如每个进程有4GB的虚拟内存空间,而且甚至连内核自已都可以被存入缓存页面,内存有先进的更新前拷贝(Copy-on-Write)功能,可以实现进程间大信息的传送等。读者可以把Accent理解为支持虚拟内存技术,并且具有网络透明IPC功能的RIG内核。 阅读全文 »

标签:
阅读:54,955 次
08

自从接触敏捷以来,已经在公司里帮助建立了不少的团队去实施敏捷,也参与了不少社区的交流活动,在这些实践和交流的过程中,感觉对于敏捷,还是有很多不同的理解,其中也包含了不少对于敏捷的误解,在这里和大家一起讨论一下比较常见的几条。

敏捷就是追求速度

一次在和几个朋友聊天的时候,有朋友说最近装了有线数字电视,他觉得开发数字电视频道服务的团队应该是采用了敏捷的团队,因为每隔一段时间,就会有新的功能发布,只是系统不稳定,不得不经常的重新启动机顶盒。

这无疑是个非常有趣的关于敏捷的理解,似乎敏捷就是关注软件功能的投放市场速度,而往往忽略质量。我想这是很多有关敏捷的理解中,比较典型的一种误识。如果我们重读一下敏捷的四句宣言以及12条敏捷原则,应该不难看出,敏捷实际是关注实现客户的价值,而这一价值体现在“可工作的软件”之中,这其实是对质量的要求,它意味着交付的软件是客户需要的并且质量稳定的,是同时对需求质量和开发质量提出要求。另外,因为市场的变化会促使客户重新调整需求,以获取最大的价值,因此敏捷强调“响应变化”,迅速调整策略,以帮助客户迅速对市场变化做出响应。所以,个人的理解,敏捷真正的含义应该是 阅读全文 »

标签:
阅读:8,057 次
07

记者/常政

“浪潮之巅”最初是2007年时在Google黑板报博客连载的一系列文章,因对世界IT产业高屋建瓴的视角、深入浅出的剖析,而获得盛誉。近期在读者们的千呼万唤下,《浪潮之巅》由出版公司Just-Pub正式出版,再次在IT圈内引起了广泛的关注。

浪潮之巅_副本_副本

这是一本什么样的书?下面这段话可概括它的主旨。

“近一百多年来,总有一些公司很幸运地、有意识或者无意识地站在技术革命的浪尖之上。一旦处在了那个位置,即使不做任何事,也可以随着波浪顺顺当当地向前漂个十年甚至更长的时间。在这十几年间,它们代表着科技的浪潮,直到下一波浪潮的来临。”

不难看出,这是一部分析科技产业、商业机遇内在规律的IT历史书,难以想象的是它出自一位科学家之手——前Google资深研究员、现任腾讯副总裁的吴军老师。他是如何考量这部作品,并将其中的法则来解读我们身处的IT大时代的?最近,本刊记者有幸对吴军做了专访。 阅读全文 »

标签:
阅读:31,183 次
07

三个主要误区

第一个是重视流程忽视人。敏捷宣言开明宗义指出“人和沟通胜过过程与工具”。但是仍然有很多企业试图通过创造一个完美的流程来实施敏捷。不可否认,合理的流程对于提高团队效率有一定的作用,但是企业真正要从敏捷改进中获益必须落实到人的改变上来。

第二个是重视管理轻视工程。很多团队将敏捷等同于开开站会、做做迭代、搞搞回顾。到头来,一切流于形式。敏捷说到底是对于软件工艺性的认识回归,那么持续集成、自动化测试、设计、重构这些手艺是绕不开的。不从这些根本的手艺上解决问题,各种眼花缭乱的沟通手段实际上徒然增加了团队的成本。
第三个是重视指标轻视过程。很多团队特别是从CMM型组织转向敏捷的团队,热衷于设计所谓的敏捷度量体系。度量应该是帮助团队增强信心和持续改进,指标不应成为目的。我们要关心的不只是站在哪里,更应关心我们将走向哪里。 阅读全文 »

标签:
阅读:6,706 次
06

记者 / 董世晓

作为从英特尔中国研究院走出的第一位首席工程师,吴甘沙的故事或许能给我们一些启迪。他相信无论做任何事情,只要你认真对待,即使走的是弯路,同样也能获得另外一种成功。

首席工程师的责、权、利

《程序员》:首先恭喜您成为英特尔的首席工程师,请介绍一下首席工程师的工作职责。

吴甘沙:只要你是认真地对待,一切弯路都是直路

吴甘沙:根据我的理解,首席工程师不是一个具体的工作岗位,更多的是一种荣誉,或者是一个职称。英特尔共有8万员工,其中近5万人从事技术工作,因此就需要有一个系统,能够让每一个人都能在其中找到自己的定位以及努力的方向。所以我们创造了一个系统的职业阶梯,使新加入的人可以从基层开始,慢慢往上攀登,最终走到首席工程师、资深首席工程师、院士、资深院士等位置。 阅读全文 »

标签:
阅读:19,018 次
preload preload preload
京ICP备06065162