对敏捷的一点看法

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

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

测试驱动开发  

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

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

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

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



  

评论

1 楼 Willam2004 2010-12-18  

引用

编写单元测试需要花费大量额外时间；测试过一段时间就无法运行；为了提高覆盖率写了测试方法，但未写测试逻辑或断言（Assert）等等

编写单元测试需要花费大量的额外时间，所以在开发时间评估时将单元测试的时间也加进去了；测试一段时间无法运行可以通过Hudson持续集成方式或者Mock的方式；单纯为了覆盖率而写的测试方法，有sonar进行覆盖率查看。