Re: 倡议把中国改革开放的成功经验借鉴到敏捷软件开发方法的推广工作中来

阅读更多

[quote="taowen"] 许多同志都抱怨自己位子低，权利小，对于工作中遇到的问题有想法，明知道推广敏捷能够极大地改善这些问题，但是却无能为力。究其原因，不外乎敏捷的推广涉及到开发流程的方方面面，对内关系对外关系。要全面推开，不光需要有力的权利支持，开明的客户，还要有一支优秀的团队。面对这样的状态，我们能做什么呢？难道我们就不作为，混日子么？我觉得，一个可以借鉴的成功经验就躺在眼下的中国大地上。中国改革开放的成功经验中有许多创新，比如说有计划的商品经济。我觉得不能把这些称法简单认为是文字游戏，我觉得它是中国中庸精神的体现。正是通过小步放开，让中国的经济总量做上去。才能够有力量去做更深一步的改革，有经济实力，也有人才储备，更有民意基础。 在这个思路下，可以有很多工作可以做。比如说，如何让高层支持你？不光是靠几个演讲，做几次报告就能解决的。作为领导，恐怕最关心的还是不出岔子。你要是太急，推动得太过了，缺乏实际成功的经验，恐怕很难有领导会支持你。假如先引入持续集成（或者别的最佳实践），让团队看到益处，让市场看到好处，要走下一步应该就会容易一些。这里就牵涉到最佳实践是不是能够部分采用，先采用哪些后采用哪些的问题了。对于这个问题我们先来看看改革开放的经验。最开始引入的商品经济，运行的是双轨制。虽然中间造成了很大的公权利寻租问题，但是不得否认商品经济对于解决当年主要矛盾“人民日益增长的物质文化需求与落后的生产力之间的矛盾”的巨大贡献。国企改革，中国股市，股权分置。这么多年来，虽然是走两步退一步。但是至少还是部分说明了这市场经济也是可以分步实现的。反观休克疗法下的那些国家，至少还是能部分说明我们是成功的。就敏捷软件开发的实际生存状况来说，其实也并不是每个项目都应用所有的最佳实践，团队成员个个是牛人的。以我在悉尼三个月工作的经验来看。至少对于TDD和结对编程，我们公司都是很灵活的。而且也没有明显的证据表明这样实践下来的敏捷项目变了味。 除了对内的逐步改革，对外关系更是软件项目成功的重中之重。其实，敏捷软件开发的先进性就是体现在对于客户商业价值的重视的基础上的。但是，重视客户是靠喊口号就能实现的么？短期内，在国内，还很难有客户认识到敏捷软件开发流程的价值，销售很难谈下来按时间收费的项目。难道我们只能“等靠要”么？关于固定时间固定费用的项目，我们作为基层开发人员能够做出什么贡献来确保敏捷在此类项目中的良性实施？这都是很大的研究课题。更是实验课题。需要在日常实践中，慢慢来摸索。 中国有中国特色。不妨套用那句老话，开创有中国特色的敏捷软件开发方法学。这个命题，也是我在ThoughtWorks China今年所要思考和实验的核心命题。[/quote]

OK，如果真的打算引入敏捷，如何选择最恰当的切入点？ 我想这个点应该符合这样几个条件：第一：简单、易行；第二：效果明显；第三：至少在领导看起来，对现有的开发模式影响不大。 持续继承恐怕很难，因为领导最关心的其实是整个团队、整个项目（产品）。如果持续集成没有其他开发者的接纳，没有领导的认可，根本不可能推行。影响面比较大。 依我看，最好的切入点是TDD。 由每个人写单元测试代码，而TDD本身就很难为不了解它的人所接受。退一步讲，即使所有人都接受了（情愿抑或不情愿），都开始写测试代码。那么由谁来保证他写的测试代码的质量？我们可以说采用配对编程、代码共享、持续集成来保证。呵呵，不过那这就不是lz所谓“逐步改革”了。 或许最好的方式是先找几个积极分子在小项目上实验，采用比较完整的敏捷方式。在领导和开发者看到明显效果的情况下再向整个开发部分推广。因为小项目的风险系数比较低，可以在封闭状况下的自由实践。这好比先建立几个特区，取得经验之后再向全国推广。 其实当初Kent把c3 team改造成敏捷不也是“休克疗法”吗？ 未必不行。 写完了发现其实我也主张渐进式，只不过主张的改革切面不同罢了。