敏捷理解12

  • Post author:
  • Post category:其他


当下,相比于以CMMI(软件能力成熟度模型)为代表的传统软件过程,敏捷软件开发过程成为企业和互联网应用开发过程不争的首选,在此类应用开发过程中,瀑布模型被迭代模型取代,大前置设计被及时涌现设计所取代,阶段式物交付被可使用的功能交付取代,后测试被测试先行取代等等,这一切无不践行着敏捷“个人和互动高于流程和工具,工作软件高于理解文档,客户协作高于合同协商,变化响应高于计划遵循”的价值观。



敏捷宣言中将“个人和互动高于流程和工具”作为第一条应坚持的价值观,这反应了敏捷对于以人为中心的核心价值观,人对于软件开发的成功可谓至关重要。从工程学的观点来看,软件开发属于工程的设计阶段活动,而非工程的制造阶段活动(对比桥梁制造和汽车制造而言,软件开发与桥梁设计和汽车研发,而非桥梁搭建和汽车流水线制造,软件开发对应传统工程的制造过程已经由计算机负责,包括编译和执行),因此,软件开发对于智力的需求多于体力的需求,而对于智力工作者来说,舒适的环境、轻松的氛围,自由的空气更利于激发工作热情,提高产出,相反对于体力劳动者而言,规则、工作步骤、流程等科学生产是提高效率的关键,有时皮鞭或许更能简单而有效。规则、要求等程序性的东西对于智力工作为主的软件开发效率的提升来说,带来的坏处多过好处,敏捷宣言中“为积极员工提供他们需要的环境和支持,并相信他们可以完成工作”或许是对于这一结论的最好体现。要提高产出,先提高人的技能,而不是用流程和工具来要求人、限制人,犹如治水,堵不如疏 疏不如引。



按照敏捷的观点来看,软件开发的产物是可以工作的软件而非面面俱到的文档,在敏捷的眼睛丽,软件或则说代码是一切开发活动的中心,设计的产物事代码、实现的产物是代码、测试的设计是代码、测试的实现是代码,项目进度的度量对象也是代码(不过不是代码行,而是可以工作的代码),成员的交流也依附于代码(可以说代码是唯一的干货),而文档不过是辅助成员通过代码交流而已(因此javadoc的重要性抵不过具有自释性的类和方法命名),让我们再次体会“工作软件高于理解文档”的敏捷价值观外延,把工作的中心真正转移到代码本身而不是其他。



版权声明:本文为itd018原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。