讨论:敏捷是否适合华为

  • 侯伯薇

2012 年 7 月 3 日

话题:敏捷DevOps语言 & 开发文化 & 方法

在近期举办的ScrumGathering 2012大会上,曾小萌在 open space 环节提出的话题是:如何转变多项目下有效资源投入的交付思维,其中对于敏捷在华为中的实施进行了讨论。会后,讨论并未结束,继续在微博上展开,话题集中在“敏捷是否适合华为”,曾小萌也在博客上总结了讨论的结果。

华为公司为了进行敏捷转型,做出了很大的努力,当初有“10 名深度合作的敏捷顾问 +10 位华为敏捷转型的重量级参与人员”,而今只剩下周耀辉一人。曾小萌作为团队的一员,早在五年前就参与到这个过程之中,经历了很多,思考之后,认为最大的问题是人的因素,即华为敏捷种子的流失性问题,而且各位敏捷顾问的心态也开始疲倦。

为了能够针对这个问题展开更多讨论,曾小萌Scrumgathering 2012的 open space 环节提出了一个话题:如何转变多项目下有效资源投入的交付思维,之后,又在微博上和大家针对“敏捷是否适合华为”的问题进行了更加深入的讨论,他提出的观点是:

巨蚌:全对,变革只能徐徐图之,可惜当时错估了狼的本质:集群作战。其实一直不明白为什么华为一直重视开疆扩土,但是守城不足呀,难道是地盘不够大?华为的待遇还行,但是对员工的个人意愿不够重视,强调集团作业,摒弃了个人主观能动性的发挥。至少我离开的原因只是不适合!和敏捷无关,只是需要内省!

华为赵磊:敏捷推行真正全面打开了一线交付团队的思维,开始认真思考什么才是正确的做事方式。或许带来了很多矛盾,但自主思维模式的开启对后续华为要做的更大转型绝对是起到正面作用的。这个成绩无可否认!说华为的交付思维始终是创业阶段的思维,颇有些贬低这种思维模式的味道,这种微观层面的交付思维,宏观上就是以客户为中心,以奋斗者为本的企业文化。正是因为这个东东的存在,才使得华为不会在上层一些错误的决策,而在华为的生命线上产生太大影响。

巨蚌:这种文化出发点是好的,但是这种趋同的价值观抹杀了一代代的华为人,差异的个体应该被重视。最好的情况是奋斗者为自己而奋斗,但是实际情况是因为制度而奋斗,为什么华为人那么辛苦但是产生的价值却那么少?反观那些创业型的公司,人少但是产品好,还有认同感!

KenFang-Park:回复@巨蚌: 敏捷仅能帮助华为的团队把事情做对, 但华为更重要的是做对的事情。特性开发与 OneTrack 就是要让华为不仅将事情做对, 更重要的是做对的事情, 避免浪费。

张克强 - 敏捷 307: CMMI3 建设时,需要各位大拿把保留在头脑中的知识、经验展现出来,而让其他人遵照执行,注重的是组织过程资产。在这过程里,有些资深人员不喜欢分享,有些资深人员不喜欢被规定,虽然似乎有点违反人性,但这个过程是可以做得人性化的,对组织是有利的,而综合上对个人也是有利的。

袁店明 Dynesy@曾小萌 HW 对这个话题非常感兴趣,个人有个建议,如果只是一对一的“10 个深度合作的敏捷顾问 +10 个华为敏捷转型的重量级参与人员”,信息可能会出现不少偏差。如果有可能,可以组织一次尽可能多的人面对面,哪怕没有 20 个人,但是效果可能会好很多,偏差会小很多。持续关注中......

豆丁丸子小丽:任何开发模式在大企业和小公司都不会相同,何况每个公司还有自己的企业文化,华为的产品和很多小公司做的产品也是不同的,只要华为不要只学习敏捷的形式导致看上去是在压迫员工每个 Sprint 出东西,员工一样的做事,为何离职呢?自组织也许还能带来更好的创意,于公司也是好事啊。回复@颜路老师: 偶就在敏捷和测试啊。 个人觉得敏捷需要上升到企业文化里,只有所有人尤其是上层有此意识的时候,实施敏捷才有意义。 这么说来其实敏捷不能作为一种模式讨论了~~

黄邦伟的微博:华为敏捷实施结果是很不错的。当然有很多改善之处。虽然有些团队做了不到位,却不表示敏捷实施是失败的。迭代开发、自动化测试、持续继承、特性开发、等在我接触的团队,都有一定的基础。更重要的是,敏捷已激发起团队的自我改进意愿。其实我们不该过于注重敏捷不敏捷这问题。应该注重开打能力、效率,效果问题在哪,然后采用正确的解决方案,把它有效的落实。敏捷带来一群"哲学家"、"思想家"。这些人啥都不干,只批评人家是否"敏捷",不知道实际操作。其实对敏捷反感,不如说对这些人反感。应该把重点放在解决实际的问题。

曾小萌 HW:回复@黄邦伟的微博: 其实主旨是赞同的,针对某个具体产品项目而言。只不过讨论的是个长期的演进和适应性问题时发现,可能不是那么乐观。

蔡德辉 _IT 质量管理前沿微博达人:如敏捷走上正轨,必以模型驱动、持续集成与测试、项目管理、持续沟通、必要的文档、代码与模型同步作为必要条件。否则债务将在交付 6 个月或 1 年后重做为基础。当员工流动性加剧时,说不定未交付先还债。

okstar791:回溯一下吧:06 年 CMMI 发展到极至,PSST 内审过于僵化引起反弹。07 年有人写论文研究敏捷,08 年 3 年上台,放了三把火,主推研发效率提升和绩效改革,敏捷被三年青睐,大规模推广,大部份项目裸奔,10 年恶果浮现,11 年偶国际惯例。这是一系列的事件造成的结果,但这又是必然的结果,从 05,06 年 PSST 过于强调过程符合度,过于强调数据度量,那时就埋下官僚管理的种子,后面三年上台,不恰当的改革更是成了摧毁流程体系和研发文化的最后一击。敏捷崇尚自由的思维,但却是用官僚的手段在推行,怎能不失败呢?只是苦了为网上问题背锅兄弟。总结华为的敏捷不能只看敏捷,必须要看到同时实施的各种变革形成的合力的影响,敏捷只是一个变革失败的替罪羊。我认可敏捷方法,但不认同推行的方式。我认为推行敏捷战略上是失败的,但战术上成功了:很多好的实践被固化,但没有改变华为文化,有可能会变得更糟。战术上推行是成功的迭代、持续集成、Story、故事墙、燃烧图、每日站会,经过推行者艰苦的努力,好不容易在 IPD 的框架上融合起来,这本身就是一个巨大的成功,但也仅此而已,再深入下去,应该就是以 PDU+OneTrack 替代 IPD,但后者无可置疑是失败的,并且短期内看不到成功的迹象。

agile123:敏捷肯定适合华为。不敏捷不变革,不持续改进适应变化,只有绝路一条,北电柯达可做参考。很多人误以为敏捷就是 Scrum-XP,就是 PO-SM-Dev、TDD、CI、PP...,这是商业洗脑的结果。所以首先要把到底什么是敏捷定义清楚。不过华为这种规模的企业敏捷化,项目、产品级容易,企业级很难。

KoncaFung:以我最近作为码农参与项目的经历来看,五个字就总结了:欲速则不达。设计阶段太短,很多东西没搞清楚,模型也不建,IT3 时还在改 data model,每轮 IT 都在为对 interface 而耗费时间,然后代码就跟着改;再加之分工不合理,一个 class 没人写几个 methods,代码重复、风格不一致,测试代码没人写……UML 和敏捷的成绩大家是"有目共睹"的。其原因,个人观点,前者是多数人不懂 OO 故无法用好类图和序列图 (我觉得),后者是"欲速则不达"和 CI 能力不足 (模块级 CI 以及自动化测试)。这都是理念层面的原因,就好比你去劝农民让孩子读书但这仁兄宁愿孩子种地马上有收益 - 我没有鄙视农民的意思,80 年代情况就这样)

okstar791@吴穹 吴博:我认为在 H 公司敏捷转型的同时,还进行着为数众多的变革,不能把这些变革都算到敏捷转型的头上,不然分析结果就是失之毫厘,谬之千里了。例如:要不要把“三年打造全国程序员都向往的研发中心”算在敏捷头上?“修改工作时间”呢?“绩效考核”呢?这些实际上对敏捷转型都有影响。

ALEXGUNDAM:敏捷的挑战不是在于十几的小公司。小公司天生敏捷。等同于我们经常听到的小公司转型容易之类的说法。 真的挑战在于那些人数众多的公司。里面牵扯的复杂的人际关系和利益。 变革也好,还是潜移默化也好,归根结底就是牺牲部分利益换取另一部分利益。

agile123:很有意思的文章!光从这个结构,看不出和敏捷有啥矛盾,是合理高效的 // 最后,看项目资源调度权。以“BG-> 产品线 -> 产品 -> 项目”等自上而下金字塔型的业务交付组织(都是 1 对 n 关系),每层都具备下层的资源调度权,同时每层都会有对应数量级真枪实弹的资源(专家)来 cover 应对该层可能出现的风险或问题。这个理解有误,敏捷的一个基本原则是减少浪费,所以不能按人分事,肯定也是精简流程、按事分人、按岗定员,敏捷实施后的效果通常是减少了不必要的岗位,避免人浮于事 // 敏捷方面就不多做说明了,组织能力成长曲线的渐进模式科学合理,诱人无比,“按人分事”符合人性下循序渐进的成长成熟规律和心理诉求。问题症结和难点在于你们如何让整个 BG 金字塔按照敏捷模式来运行,而华为的狼性文化本身就是(业务)敏捷的,取得了骄人成绩,所以你要说明 Agile 到底能给产品线带来哪些额外的好处,这需要充分论证和试验,否则就是多余。

徐毅 -Kaveri:诱因:1,集跬步以行千里;2,很好;3,诺西有过很多总结,另外华为也有自己的特点,流失问题很多地方都存在,但是由于思想的启蒙还是对敏捷的失望而流失,值得深究;4,很想知道“不愿意”背后的故事……诺西某产品线就是在项目群交付模式下转型的。末了送君一句:好雨知时节,润物细无声。

徐毅 -Kaveri:组织不也是由人组成的么,改变一个人轻松些,而改变组织也就是改变一大堆人而已。只是,做一个人的思想工作相对更容易也比较快,而要给组织内一大群人做思想工作就困难很多。最近看鹿鼎记很有感,组织内的风向转变很重要,老大下决定、滑头暗传圣意、群臣附议,辅以充足粮草于精兵良将执行,缺一不可。其实这是一个非常值得追溯的问题。如果“必须要进行敏捷转变”是一种紧迫感的话,当时有紧迫感的人有多少数量呢,是一个人、少数几个还是绝大部分甚至所有人?如果一个决定不是已有普遍共识的话,呵呵,转变的下场,想来也是可以预见的。

敏捷DevOps语言 & 开发文化 & 方法