2013-04-25 11:53:28 lalala003 阅读数 695
  • 产品研发敏捷统一过程2.0

    产品研发敏捷统一过程2.0视频教程,该课程介绍一种极轻量级又能涵盖整个产品研发生命周期的敏捷开发框架,包含了产品创新、敏捷需求建模与分析(QUML)、精益创业、Scrum等体系,全程无缝连接。 讲师介绍:陈勇,IIOM(无锡英特奥盟科技有限公司)CTO/CIO/技术副总裁/总工程师。

    7021 人正在学习 去看看 CSDN讲师

专访陈勇: 敏捷开发现状及发展之路


2014-03-04 16:31:56 cheny_com 阅读数 10131
  • 产品研发敏捷统一过程2.0

    产品研发敏捷统一过程2.0视频教程,该课程介绍一种极轻量级又能涵盖整个产品研发生命周期的敏捷开发框架,包含了产品创新、敏捷需求建模与分析(QUML)、精益创业、Scrum等体系,全程无缝连接。 讲师介绍:陈勇,IIOM(无锡英特奥盟科技有限公司)CTO/CIO/技术副总裁/总工程师。

    7021 人正在学习 去看看 CSDN讲师

感谢大家多年来对《火星人敏捷开发手册》系列博客和手册本身的关注。

本周四晚上在QQ群234570791的群视频中将进行此手册的免费培训第一期,详情如下:

时间:2014-03-06 周四晚上8点~9点

话题:Scrum概览。

时长:60分钟左右

授课:火星人陈勇

用途:用于本人公开课和内训的课前预习材料,也可以作为自发学习和推广敏捷开发的课程材料。

培训视频:培训已经结束,视频请见:http://yun.baidu.com/s/1i3r7jqH?fid=793514989638781

日后本群每周四晚上8点都可能推出类似的培训,日程表会提前发布在群内的日历上,如果感兴趣请关注。


2014-11-27 12:31:08 cheny_com 阅读数 274
  • 产品研发敏捷统一过程2.0

    产品研发敏捷统一过程2.0视频教程,该课程介绍一种极轻量级又能涵盖整个产品研发生命周期的敏捷开发框架,包含了产品创新、敏捷需求建模与分析(QUML)、精益创业、Scrum等体系,全程无缝连接。 讲师介绍:陈勇,IIOM(无锡英特奥盟科技有限公司)CTO/CIO/技术副总裁/总工程师。

    7021 人正在学习 去看看 CSDN讲师
火星人敏捷开发手册—27895人已学习
课程介绍    
201411270716166935.jpg
    本课程讲师是CSDN下载总量超过一万人次的《火星人敏捷开发手册》的作者,课程中将以PPT+视频方式讲解《手册》,适合个人学习、敏捷开发现场培训预习、企业推广敏捷开发等场景。除了《手册》中的原有内容外,还将包括讲师正式培训中相应的一些内容,以便深度了解Scrum敏捷开发的全过程。
课程收益
    
讲师介绍
    陈勇更多讲师课程
    具有丰富的工程技术与项目管理实践经验,从其程序员、项目经理、CMMI/FPA功能点估算/敏捷咨询师、事业部总监、副总经理等各种技术与管理岗位获得的一手经验,令其可以站在企业管理者的高度,以更广的视角来理解敏捷开发,并能配合和推动非研发部门协作推广敏捷。
课程大纲
    1.15分钟Scrum扫盲  15:10
    2.Scrum中的工作产品  15:11
    3.Scrum中的角色  15:08
    4.Scrum 计划会之讲解故事  15:09
    5.Scrum 计划会之扑克牌估算  15:13
    6.每日立会  15:09
    7.看板与燃尽图  15:11
    8.Scrum 评审会与反思会  15:09
大家可以点击【查看详情】查看我的课程
2012-05-08 10:55:00 valzepingtang 阅读数 6045
  • 产品研发敏捷统一过程2.0

    产品研发敏捷统一过程2.0视频教程,该课程介绍一种极轻量级又能涵盖整个产品研发生命周期的敏捷开发框架,包含了产品创新、敏捷需求建模与分析(QUML)、精益创业、Scrum等体系,全程无缝连接。 讲师介绍:陈勇,IIOM(无锡英特奥盟科技有限公司)CTO/CIO/技术副总裁/总工程师。

    7021 人正在学习 去看看 CSDN讲师

陈勇老师作为国内外包与敏捷开发专家,具有丰富的工程技术与项目管理实践经验,擅长在各种实际场景中灵活运用各种实践,并可提供敏捷开发、早期软件成本估算等公开课、扩展咨询和实践指导活动;曾参与多种模型的实践/咨询和培训工作,如CMM/CMMI、敏捷(Scrum)、功能点FPA、早期软件成本估算等,并能将多种模型融会贯通。

日前IIOM独家专访国内外包与敏捷开发专家陈勇老师,以下为采访内容:(问:IIOM记者  答:陈勇老师)

问:最近越来越多的海外发包商在在招标时要求供应商具备敏捷开发的能力,您怎样理解这一趋势?

答:这一趋势,首先表明海外发包商在寻找新的供应商的时候更加谨慎,希望利用敏捷开发的短期迭代来及早判断供应商的能力;其次表明他们对于利用敏捷开发中的尽早交付来保证项目不会中途被取消;最后还应该归于越来越多的外包应用发生在互联网、移动应用领域,其固有的特性要求快速交付产品。

问:为什么之前的发包商更看重CMMI,而最近则很倾向于敏捷开发?

答:在大约10年前的外包中,主要的发包商是类似美国国防部之类的大型政府企业、制造业,而开发的软件也比较大,因此出现了一批与之对应的大型外包企业如印度的InfoSys等,而这些企业凭借CMMI来证明自己的实力,也就不足为奇,因为CMMI本质上说是美国国防部对供应商的招标的资质标准。

而最近的业界趋势,则是移动互联网、SNS等应用,这些应用的价值观不是“有序地开发”,而是“迅速、创新地开发”,业务上的差异造成了更加追求短周期、持续交付这些敏捷开发的价值观。

问:上面说的都是甲方的需求,作为乙方,尤其是中国的乙方,能从敏捷开发中获得什么呢?

答:首先是机遇。以往有印度、菲律宾这些外包大国围绕,中国的外包很难开头,因为很多发包商都觉得中国是个“陌生的市场”,与其承担巨大的风险,不如继续与传统外包国家打交道,尽管其成本在不断上升。敏捷开发的快速短期迭代,使得发包商的“试水”工作变得不再那么可怕,这是我们打开外包渠道的一次机遇。

其次是更丰厚而合理的利润。在以往,由于中国本国的发包方多数比较强势,中间追加需求而不增加金额的情况非常普遍,而国外的发包商相对通融。比如我就去过有一家欧美外包企业,他们曾经因为甲方变更负责人而发生了很多的需求变化,但最后双方核实后,追加了相应的金额。

问:追加价格的时候,如何核实数额呢?

答:这个就要谈到报价模式。

在国外用功能点报价已经逐渐是一个常态了,澳大利亚、芬兰、荷兰、意大利、日本、韩国等国的政府招标,很多都是采用功能点报价。尽管在中国鲜为人知,但在全球有多达6000人的CFPS(认证的功能点专家),在从事各种报价和度量活动。

功能点方法迄今为止已经形成了5个ISO国际标准,其核心思路是:利用一个公认的方法来衡量软件的规模,然后再乘以单价,来测算项目的报价。这个可能不符合国内外包中甲方先有预算后招标的习惯,但是却很符合海外发包商的相对单纯的“商品交易”的心理。

比如就曾经有海外发包商要求接包方报价,并必须说明报价的依据,结果国内无一企业能做到。失利的原因是多方面的,其中一个方面是当时没有可行的方法能在项目早期快速从有限的客户文档中判断项目的规模。

针对这类问题,后来我主笔编写了造价估算的行业协会标准,引入了NESMA(荷兰的功能点组织,同时也是世界第二大功能点组织)的快速功能点估算方法,在国内发包的项目中做的测算是每一人年左右的工作量仅需一张A4纸即可描述清楚,培训后每人天可完成4000~6000功能点需求的估算(大约合20~30人年的开发量),20多个历史项目的回归数据表明其精度在15~20%左右(大于和小于此数据的项目数各占一半)。

问:敏捷开发与这种造价管理有何关系呢?

答:尽管在项目初期只凭借几十页纸能完成20~30人年开发量的估算已属难得,但15~20%的误差对于固定单价合同还是有点粗糙。最佳方法,是与客户签署固定单价的合同,然后在几个短周期迭代后,定期实际计数一下功能点的数量,与用户结帐,这样非常适合长期项目的阶段性结帐。

    尽管听起用 单价×实际功能点数 = 总价 结帐很不可思议,但实际上澳大利亚政府就是用这种方法,只是他们并不要求迭代交付;芬兰政府的一些项目也采用类似的方法结帐。北欧最近一直在推行Northen Scope方法和工具,目的就是为了推进按规模估价、结算的方法。

     如果配合敏捷开发方法,在一个或多个短周期迭代后,按交付的功能数量进行结算,则无论对甲方乙方都是有利的。对甲方而言,可以按照乙方实际完成的功能结算,因而无需事先定义完整的需求(在移动互联网行业几乎是不可能的),而可以中途提出新需求;对乙方而言,新需求也是付费的,“拥抱变化”成为一件有利可图而非避之不及的事情。
     在这种新语境下,合作从僵硬地“履行合同”变成双方一起思考:哪些需求是值得开发的?有什么新需求胜过之前的计划因而能提升市场竞争力?这些正是甲方的利益所在,而乙方通过对甲方这种利益的满足,自己也能赢得客户。

本文来源于IIOM中国(官网:http://www.int-iom.cn),转载请注明文章来源,违者将被追究法律责任。
编辑:IIOM中国 

2013-03-12 14:19:55 cheny_com 阅读数 5341
  • 产品研发敏捷统一过程2.0

    产品研发敏捷统一过程2.0视频教程,该课程介绍一种极轻量级又能涵盖整个产品研发生命周期的敏捷开发框架,包含了产品创新、敏捷需求建模与分析(QUML)、精益创业、Scrum等体系,全程无缝连接。 讲师介绍:陈勇,IIOM(无锡英特奥盟科技有限公司)CTO/CIO/技术副总裁/总工程师。

    7021 人正在学习 去看看 CSDN讲师

原文出处:http://www.csdn.net/article/2013-03-05/2814348

以下是文字拷贝,与原文相同,留作备份。

摘要:敏捷这个含着金钥匙诞生的“霹雳娇娃”是软件开发行业的救星,从头到脚、从里到外无不闪着金光,透着与众不同。但国内少有团队能真正理解其精髓和奥秘。为此,社区之星第15期采访了敏捷开发老兵陈勇。他站在企业管理者的角度来讲解敏捷开发并分析的字字珠玑。

陈勇,16年软件研发、管理及咨询经验,擅长在实际环境中应用敏捷开发实践。具有丰富的工程技术与项目管理实践经验,从程序员、项目经理、CMMI/敏捷咨询师、事业部总监、副总经理等各种技术与管理岗位获得的一手经验,令其可以站在企业管理者的角度,以更广的视角来理解敏捷开发,并能配合和推动非研发部门协作推广敏捷。

个人工作经历:

  • 1995年毕业于南京航空航天大学自动控制系,后获得清华电子与通信工程的工程硕士学位。
  • 1995-2001年,曾在某研究所、清华同方等企业从事编程和项目管理工作,参与过国庆阅兵直升飞机指挥系统、CCTV数字电视条件接收系统等项目的研发工作。
  • 2002-2006年,主要从事CMMI的过程改进工作,供职单位包括普天、亚信等软件研发企业,以及英普信、斯福泰克和DNV等咨询公司。
  • 2008年,在泰克赛尔任中国区的咨询总监、事业部总监、副总经理等职。
  • 目前就职于IIOM国际外包管理协会,担任咨询总监,并领导团队开发“火星人”敏捷开发管理工具。

国内缺乏敏捷思维

CSDN:请问你是如何接触到敏捷开发的?又是什么吸引你如此专注于敏捷开发的?

陈勇:2000年,我接触到最早期的XP(极限编程),在一些团队中进行多次尝试后,总结出许多敏捷实践的方法,比如代码审查、松结对编程等。

在几年后的CMMI咨询工作中,感觉国内的研发现状普遍不适合直接使用CMMI的标准,反而更适合使用敏捷或偏向敏捷开发的方法。CMMI是美国国防部对其供应商的选择评判标准,带有大量的军工、大型制造业的影子;而国内软件更多的是MIS、OA、金融、电信这些更加平常的软件,还有许多需要灵活变化的网站和网络应用,与CMMI的很多假设前提都有很大的距离。

在最初的时候也是希望兼顾各种方法,曾经同时开设多达13种培训课程,但后来放弃了。原因之一就是,尽管管理一个软件企业的知识体系有很多,但应该有一个较为一致的思路贯穿其中,才更加利于企业及其团队的理解和应用。

不过,尽管方向和课程收缩为只有一个敏捷开发,但所包含的内容却扩大到包含整个企业及团队管理所需的所有内容。比如下面还会细谈的FPA(功能点分析),实际上完全不是传统敏捷开发关心的内容。

CSDN:在你为不同公司和团队提供敏捷咨询的过程中,你认为最困难的地方在哪里?

陈勇:最大的困难应该是中国企业在研发管理方面普遍“胆子很小”,缺少探索精神,期待现成的答案。

敏捷开发出现并传入中国已经有10年历史了,两个被问烂了的问题还是没有答案:“什么是敏捷开发?”“我们适合什么敏捷开发?”在这种情况下,企业应该清醒地认识到国外没有答案,权威人士也没有答案,培训师和咨询师也没有答案,答案一定是自己找出来、实验出来的。

基于这一点,我会尝试在课堂上尽量少讲概念,而是多讲自己的实践及其启发,希望企业接受“敏捷无有定法”以及“最佳方法需要自己找”的概念,有多少个企业就有多少种敏捷开发。企业应接受的是敏捷开发的思维方式和可选的实践方式。

CSDN:你觉得什么样的产品或应用,比较适合敏捷开发?

陈勇:互联网及相关的产品或应用比较适合。敏捷开发的出现与互联网应用的兴起是同一时间,这不是巧合。无论敏捷开发最早出现在哪里(实际上来自于日本制造业),但最终发扬光大的原因是与互联网应用对“拥抱变化”“快速迭代”的相同价值观的追求。

敏捷强调快速灵活反应

CSDN:自从敏捷概念从国外引进国内后,敏捷开发和敏捷测试就很火,但有人认为敏捷测试就是一个大忽悠,你是怎么看待这个问题的?

陈勇:可能是因为敏捷测试被炒得太火,有喧宾夺主之嫌,所以才有此说吧。我个人认为,敏捷开发(“开发人员”的开发)和敏捷测试都不是敏捷的主角。相反,“敏捷需求”才是敏捷开发的主角。毕竟敏捷开发的最终目的是交付客户价值,而开发与测试都只是手段而已。

在开始转向敏捷开发的时候,很多企业都会选择看板(用于增强团队管理的透明度,偏向“开发”)或持续集成(用于快速验证产品,偏向“测试”)作为最早采纳的实践。但长期而言,应该认识到这些工作不过是过程而已,目的仍然是交付价值,也就是完成正确的需求。

CSDN:敏捷方法在中国实施起来相对有些困难,由于它导致项目管理原有模式的改变,以致公司往往不愿意引进这样的开发模式。您怎么看待这个问题呢?

陈勇:这个问题有两面性。一方面,多数企业对变革结果的不可见性都心存警惕。其实从做CMMI的年代这个现象就存在已久了,比较好理解。

另一方面,敏捷开发过于“强势”,对于团队模型、角色、开发方法、测试方法乃至术语都与以往方法大相径庭,令企业和团队感觉如果转向敏捷,革命在所难免。其实不然。以Scrum Master这个角色为例,实际上原来的Project Manager就处于非常接近Scrum Master的位置,两者的主要区别是某些工作方式的差异。因此可以令Project Manager吸收对方工作方式中“领导而非管理”“协调而非跟踪”等概念,形成“PM2.0”即可。

CSDN:还有一些团队已经在实践敏捷开发,但团队中往往无法很好的理解敏捷的本质,导致技术上标榜敏捷,团队在开发上还沿用老的开发方式。对此种现象,你有什么的经验可谈?

陈勇:造成这种情况的主要源头往往不是企业或领导,而是开发人员自己。很多开发人员之所以力挺敏捷开发,是因为敏捷开发带来的负担小,不像其他方法需要写大量文档,遵循大量的过程。听起来似乎这个想法会促进敏捷开发的推广,但其实不然。如果“负担小”是终极动力,那么敏捷开发中一些必要但相对困难的改善也会因此而被当作负担扔掉。

敏捷开发的发展之路

CSDN:你认为国内的敏捷开发何时能成为主流?敏捷开发的未来走向是什么?

陈勇:个人感觉或许这个时间点始终都不会到来,包括现在如日中天的Scrum也不会成为主流。由于企业的领域、价值观、现状的本质差异,导致不会有一个像Scrum这样被“精确定义”的方法能普遍适用。CMMI的推广过程其实已经见证了这一点,尽管它比Scrum复杂很多。

相反地,极有可能出现类似过去XP的情况:Scrum及其他方法中的各种实践会被打散,不是重新编排,而是被企业零散地选择性采纳,最终形成“四不像”研发过程。在这个过程中,对企业现状熟悉、方法论深入理解、灵活应用的高级管理人才将起到决定性作用。

目前,Scrum、XP、CM、FDD、ASD、DSDM等哪类敏捷开发方法使用最多?

陈勇:参考VersionOne的报告,可看出Scrum的应用占比最多。不过,“只应用Scrum”和“完全应用Scrum”的企业都不多,反而是“应用Scrum,但是……(又称ScrumBut)”的企业居多。以前这被认为想尝试Scrum但又裹足不前的状态,但未来正如前一个问题所说,极有可能成为广泛接受的情况。唯一的区别是,“裹足不前”会被“灵活应用”所取代。

松结对编程极益于技术复用

CSDN:你博客中更新的“松结对编程:L型代码结构”的系列文章。请问你最初写作想法是什么?该系列文章又能为读者带来什么?你近期计划写哪些方面?

陈勇:最初写这篇文章是因为前段时间在做代码和功能点统计时发现,我们的编码效率居然是国外业界先进水平的3-4倍,也就是只需要1/4-1/3的代码就能实现相同数量的功能。(注:文中所指的“功能点”是国际标准功能点Function Point,具备相对一致的定义和可横向比较的规模。文中“国外业界先进水平”是ISBSG的注释,他们指出凡是能做代码和功能点比较的公司都非等闲之辈,其数据代表了业界20%左右最优秀公司的水平)

独自编程可能会提高编码效率(主要技术是复用),但在团队中,由于沟通问题造成复用率下降,编码效率往往不高。回想起来,复用技术由来已久,可以说C++取代C的主要目的就是为了提高封装和复用。但即使是在存在已久的公司和团队中,极少有团队拥有自己的可复用库。所以,造成复用率低的主要问题不在技术,而在其他因素。

我们从这个线索可以分析出,现在的团队极有可能受益于“松结对编程”,也就是由师傅(高手,复用库的主要编写者)带徒弟(新手),由于松结对编程中师傅要指导徒弟的设计(前关键点)和代码审查(后关键点),尽管共同编码的时间很短,但却足以避免徒弟困惑于“有没有轮子?”“轮子在那里?”,更不会“重复发明轮子”。而师傅同时负责底层库和上层应用的编码,又会保证“没有多余的轮子”。

技术、团队、过程三者同时存在才能催生极高的复用率。反观业界复用率低的现状,缺少的显然不是技术,而是类似“松结对编程”这样的利于形成和推广复用库的团队及过程模型。

CSDN:从博客上,你曾经多次提到参与和管理CCTV数字电视条件接收系统,这个项目给你带来了什么不一样的体验?

陈勇:这个项目我参与时间最长也是感受最深的项目,其质量水平、技术架构、团队模式都有可圈可点之处。

首先是质量水平。团队鼎盛时期曾达到35人,平时大约有25人左右,但测试人员一直只有2个。考虑到这个产品对质量的要求,以及参与研发人员的实际工作年限平均只有2年左右,就可以发现这不是一般的团队能做到的。全员的质量意识和质量文化可以说起了关键作用。开发人员都以编写高质量代码为己任,而不是把缺陷留给测试人员解决。

其次是技术架构。由于团队的人数开始较少,编码数量不会很多,所以整个产品对复用的要求很高,充分利用了面向对象等技术。我本人的主要编程技能多数是在这个阶段学到的。

最后但也是最重要的是团队模式。一两个高手编写高质量的代码或先进的技术架构不足为奇,但一个年轻的、在一年内从5个人成长到25个人的团队要做到这些就有些困难。当时起到决定性作用的是部门经理的关宏超。作为团队中的顶尖技术高手,他主动手把手地教大家编程技术,建立质量意识,又在后期完善了师徒制度也就是1-3-9团队的雏形。后来直接受到他指导的四、五个人成为了25人团队里的骨干,而我们学到的不只是他的技术,还有他管理微观团队的方法。

在后来的很多团队中,我都实践和完善过这些质量、架构、团队管理方法。但在这个团队中的收获是系列博客中提到的“松结对编程”的最早起源。

AUP(统一敏捷过程)的重要性和实施性

CSDN:请介绍下你正在策划的AUP是什么,进展如何?是否已经找到与敏捷的互补方法?

陈勇:AUP是敏捷统一过程的起源。与CMMI相比,敏捷开发覆盖的范围相对较窄,很多内容都处于“不涉及”“不关心”的状态。但这些内容中有一些不但是软件企业不得不做的事情,而且如果处理不当,极有可能伤及敏捷开发“涉及和关心”的内容。

例如,早期计划,老板拿出三张字迹模糊的A4纸问:“这些需求要多久能开发完?”这个在敏捷开发里边的确“不涉及”。但如果大家没有答案,而老板被迫接受了客户提出的“3个月必须完成”的期限,但假设实际需要6个月才能完成,敏捷开发期间会发生什么?我们是否还可以让“开发人员自己估算任务?”是否还有心情“自动化测试并持续集成”?估计很多敏捷开发实践都在压力下烟消云散了。

这些都促使我们思考:在敏捷开发的范围之外,应该有哪些过程与之配套?

AUP的定义

AUP(Agile Unified Process)也就是敏捷统一过程尝试解决这个问题。当然,解决方法不是形成一个更大的精确定义的过程,而是从Unified这几个角度来形成“兼容性”标准。

所谓Unified有两方面,一是拥有具体可操作的方法直接与敏捷互补,另一个是至少兼容;各个过程之间数据应该衔接复用,不能各用一套说法。

例如,网上经常有人提到UML中的Use Case和敏捷开发中的用户故事,并争论谁好谁坏。那么,两者有没有可能融合?毕竟敏捷开发很少提到复杂需求的组织结构,也缺少关于“敏捷设计”的方法,而UC正好做这两个工作。这些工作不是可有可无的,在一些领域如银行、电信等需要对业务进行深度分析的行业,这些工作不可或缺。既然如此,是否其中一方略作变化,就可能让两者兼容?

又如敏捷开发中有一个由来已久但难以推行的“故事点”的概念。尽管故事点是用来做估算和生产率度量的,但却不能做跨项目的横向比较,也从未见过基于故事点的企业级生产率报告。

那么何不参考功能点分析中对Function Point的定义?毕竟围绕FP现在已经出现了5个国际标准,全球有多达6000认证的功能点计数专家(中国只有两位),度量结果可以跨项目、跨企业乃至跨行业比较,度量数据数以万计,很多国家的政府软件开发项目报价都采用功能点,这与故事点的尴尬境界截然相反。AUP实际上是开放的Agile,欢迎一切能与Agile进行Unify的Process,而不是封闭、总是想与其他方法一争高下的Agile。能争的就争,争不过的又说不涉及,这不是开放的敏捷心态。

AUP的建立过程及当前的进展

在选择所有可以兼容的Process的过程中,要坚持Agile的原则。这并不代表Agile的原则是普遍适用,而是AUP只是一个基于Agile的价值观的过程的集合,比如轻量级、短周期迭代、重视客户价值、拥抱变化等。如果要做与此价值观不符的项目,比如大飞机软件的研制,那么请选择其他过程。

现在能比较容易引入AUP的非“传统意义”上的敏捷方法包括:功能点用于早期估算和生产力度量,故事树作为宏观需求模型,139团队作为宏观团队模型,松结对编程作为微观团队模型,L型代码结构作为团队和代码的交互模型,UML作为设计模型。

当然这不只是说所有方法都向敏捷兼容,相反地,在很多方面敏捷也要做一些修正。比如用户故事的定义和组织方式必须修订,否则就很难与功能点和UML兼容。

CSDN:你是怎么分配一天的时间的?闲暇时,喜欢做些什么来放松自己?

陈勇:每月除了外出培训时间外,每天都会投入大量时间编程开发“火星人”敏捷开发平台。

另外一个常规投入则是写博客。不过我写博客不是任务,而是有感而发,因此多数博客内容都与近期我们自己的开发活动有关。这一点从最近的L型代码结构系列就能看到。

闲暇时主要是陪家人,看美剧学习外语,偶尔外出看看电影。

希望CSDN能成为中国原创研发思想的阵地

CSDN:你在学习或工作中,是怎么接触到CSDN?CSDN对于你的工作或学习有什么影响,起到过什么帮助?有没有故事可以分享?

陈勇:2001年左右就接触了CSDN,那时候经常在BBS回答C++问题,也顺便看自己不懂的问题。我还记得当时有一个很好的帖子提到程序员的四个境界,分别是“编写可用代码、编写高质量代码、编写精美代码、编写思想深邃代码”四个级别,这个帖子对我们当时的团队影响很大。后来我们对质量、技术架构的高要求,可以说是对这篇帖子的响应。

中间曾有一段时间不再编写程序就比较少上。后来再次回到CSDN的时候,已经是从事敏捷开发的咨询工作了。也就是最近看到比较经常写敏捷开发系列文章的阶段。

CSDN:你对CSDN有什么建议,以及你对CSDN的未来有什么期待?

陈勇:非常希望CSDN能成为中国原创研发思想的阵地。

这里说的原创研发思想,还不等同于原创文章。限于中国的研发水平,尤其是开发语言和技术都源自国外的现状,包括原创文章在内的文字和学术,基本都是学习、翻译、阐述国外的思想。而我们国内则是一向缺少原创思想。

但实际上至少有两个方面,国内不并不比国外落后。或者说,大家算是平行发展,没有直接的继承关系。

一个方面是广义的“产品管理方法”,比如银行、电信、互联网。中国的银行、电信业的规模远远大于多数西方国家,因此对于酝酿全新的架构、研发方法都有足够的土壤。互联网行业更是如此,百度、QQ、淘宝、Weibo这些产品都是世界级的,网络游戏市场也空前繁荣(欧美日本更倾向于开发单机或基于硬件的游戏),这些都对于我们研究和创立自己的产品管理方法奠定了基础。

另一个方面是广义的“团队管理领域”,涵盖团队模型、计划与监控方法等诸多内容。敏捷开发也属于这个方面。东西方文化的差异令很多国外的管理模型来到中国后就水土不服,但却很少见到中国人自己拓展或发明自己的研发管理方法论,甚至是个别变通实践都鲜有耳闻。曾经有一个敏捷开发人士说过:“我们都尝试敏捷开发10年了,每次引经据典都还是10年前某某老外说的那几句话,不能不说是一种悲哀。”

这在很大程度上说明我们在软件研发领域的不自信。凡是国外流传进来的思想都认为是经典,凡是自己思考出来的方法都担心是山寨。其实不然。任何一次成功,无论产品领域多么特殊,人员水平多么高或低,在偶然之中必有必然之处,如果深入思考挖掘,都有值得分享之处。

在我自己写的博客中,松结对编程,139团队,功能点与用户故事的结合,L型代码结构这些内容都是提炼于自己参与的项目,在独立思考并在与其他个人、团队和企业交流后逐步形成的结果。与其对多年尝试仍然水土不服的方法念念不忘,不如观察思考身边的成功案例,思考其背后隐藏的潜在规律。

未来非常希望CSDN及其他社区关注国内原创研发思想的产生与发展。这不是鼓励封闭思考或不鼓励借鉴,而是说与我们实际的人口基数、产品与项目数量相比,能沉淀的东西实在太少了。如果能吸引读者充分参与讨论、创新、思考、沉淀,CSDN一定会越发展越好。

陈勇 CSDN ID:cheny_com  博客地址:http://blog.csdn.net/cheny_com 


我的友情链接

阅读数 1

没有更多推荐了,返回首页