对敏捷的一点看法

  10月14日敏捷中国2010大会又在北京召开了。 根据公开的大会日程,以及公司去参与的同学反馈,效果一般。

  个人感觉,现在的敏捷开发主要理念主要是测试驱动开发、流程简化、持续集成,外延比较局限,而且主要限于软件工程领域。这几个专题目前感觉过于概念化了,敏捷成为一些公司的赢利点。每次技术大会,有众多敏捷咨询公司 的身影,比如:ThoughtWorks等等;而且会前或会后通常安排1-2天的付费敏捷培训。

测试驱动开发  

    而在敏捷社区里,经常只看到新闻和概念性文章,很少见到案例分析和具体问题的建议做法。比如单元测试实践中的问题和解决。 测试驱动开发(TDD)或者会所单元测试实践(UnitTest),在一些公司(比如我所在的公司)都遇到一些纠结问题。比如:编写单元测试需要花费大量额外时间;测试过一段时间就无法运行;为了提高覆盖率写了测试方法,但未写测试逻辑或断言(Assert)等等,一段时间下来,大家的热情都有所减退。 这些问题,比较少在社区看到敏捷社区的一些具体解决方案。

流程简化   
    至于流程简化,敏捷过程就更加“前卫”了。 比如:减小需求粒度,减少需求分析、概要设计的环节而直接编码。 这种做法我们的一些产品实践了。程序员反馈,经常还不清楚需求,就开发编码,常常导致下次需求迭代时需要返工或重新再来。整体上看,反而项目成本更高,大家在频繁迭代中,消磨了很多精力和激情。

    我想流程简化,比较适合于业务简单的互联网站,比如:社区,视频,博客,SNS等。而对于电子商务类网站,由于业务模型,业务规则,业务流程等的复杂性和互相的关联,没有前期统一完善的产品规划、分析和设计,在开发过程中很难达到缩短研发周期,尽快交付合格产品的目标。或者说,前期明确好需求、研发阶段及里程碑, 而迭代等敏捷做法可以放到编码,测试阶段,这时的敏捷效果更好。因此,应该说“前期规划好,后期才能敏捷”,“总体设计好,局部才能敏捷”。
   
   总之,流程简化应该根据具体的产品类型,技术特点来选用。实践检验和锤炼出来的流程才是最适合的,而不能一刀切的谈敏捷。 我想,敏捷社区和咨询公司,可以就不同的项目类型来定制最佳敏捷流程,开发差异化的敏捷课程可能更为适用。

敏捷应是个大概念
   我想,敏捷不应该局限于软件工程和项目管理角度。 只要是能提高研发效率的手段都可以纳入敏捷的范畴,比如:辅助开发工具,流程流程平台,敏敏捷文档平台, 捷开发框架,敏捷设计模式, 敏捷沟通方式等。
   而这些环节需要管理者,项目经理,架构师,程序员,测试等从各自的角度来分析和解决问。



  

你可能感兴趣的:(设计模式,敏捷开发,单元测试,软件测试,咨询)