RELATEED CONSULTING
相关咨询
选择相应客服马上在线沟通
服务时间:8:30-18:00
关闭右侧工具栏
现代软件开发方法
  • 作者:大左软件
  • 发表时间:2015-07-21

    IT业界正在经历着重大的改变,从惯例性的开发方法(prescriptive development techniques)转化为敏捷方法。经常出现令人困惑的现象,开发者不愿意遵循过程,也弄不明白希望遵循的几千页文档倒底哪里有问题。随后出现了备受开发者欢迎的敏捷方法,例如极限编程(xp),特征驱动的方法FDD,以及敏捷建模,不幸的是,很多管理人员对敏捷方法持保留态度,不愿意采用他们,这就产生了一种矛盾,开发者愿意遵循这些经过验证的软件过程,但是他们却不能这样做。
下面是4种重要的开发方法:


  • 敏捷软件开发

  • 统一建模语言UML

  • 统一过程

  • 模型驱动架构


传统惯例性软件开发方法的问题:

  • 惯例性过程在业界失败率相当高

  • 大多数开发人员不愿意采用惯例性过程,不管有没有意识倒,他们会找到各种理由破坏这种尝试

  • “大设计先行big design up front”的方法,对于软件开发来说是相当危险的,因为他们无法支持变化和反馈

  • 大多数惯例性对于实际的软件开发人员来说,起到推动作用是很小的

  如果要在软件开发中取得成功,需要关注以人为中心的问题,并遵循那些易于支持变化的开发技术,他们编写了敏捷宣言,定义了4项价值以鼓励更好地开发软件:

 

1.  个体和交互胜过过程和工具
强调人是软件项目获得成功最重要的因素,但是光有优秀的程序员还是不够的,需要构建团队,构建团队需要团队成员能够很好的合作,沟通。
合适的工具是非常必要的,但是没有必要使用过于庞大笨重的工具。除非项目特别的需要,否则使用最简单够用的工具。

 

 2.  可以工作的软件胜过面面俱到的文档
首先作者指出了,没有文档的软件是一种灾难,代码不是传达系统原理和结构的理想介质。然后又指出如果文档太多,将会比没有文档更具有灾难性。这是因为:维护文档需要很大的工作量,如果文档和代码不可以保持一致,文档就会成为一种谎言。作者强调了文档的重要性,同时又说没有必要维护太多的文档,直到迫切感到需要文档的时候才使用文档。

 

3.  客户合作胜过合同谈判

    客户可能没有一次确定问题本质的能力,有时他们会改变主意,与客户一起工作是艰苦的,但是这是工作的现实情况。软件开发人员需要不断的得到客户的反馈,而合同往往会随着时间的变化和需求的变更变得没有意义。

 

4.  响应变化胜于遵循计划

    业务环境在变化,技术也在变化,响应变化的能力常常决定着一个软件项目成败,当我们制定计划时,应该确保计划是灵活的,并且易于适应商务上和技术上面的变化。

 

 

关于怎样制定计划,作者给出了这样的建议:
1)  计划不能考虑的太远,这是因为i商务环境可能变化,II一旦客户看到运行的软件,客户可能会提出改变的建议(这一点很常见哟)III即便我们确信客户的需求是不会变更的,正确的估计项目时间也并非易事。
Q:上级交给了我一个任务,我们怎样才能正确地估计时间?

2)  作者给出了一个他认为合理的制定计划的策略,为下两周作一个详细的计划,为下三个月做出一个粗略的计划,在以后就做极为粗糙的计划了。我们应该清楚地知道下两周要完成的任务,粗略的了解一下以后三个月要实现的需求,系统一年后要做什么,有一个粗糙的想法就行了。


 

由敏捷宣言的四句话引出了敏捷的12个原则:这12个原则是敏捷方法区别于重型过程的特征所在。

1. 我们最优先要做的是通过尽早的,持续的交付有价值的软件使客户满意
敏捷之所以这么做是因为,尽可能早的交付可以更好的得到客户对需求理解的反馈,从而可以让客户更具已有的系统引导团队开发出满足他们需求的软件。
敏捷为什么这样做呢?作者给出了这样一个论文结论来做这一条原则的论证:“初期交付的系统中包含的功能越少,最终交付的系统质量越高。”,“系统交付的越频繁,最终产品的质量就越高。”
2. 即使到了开发的后期,和欢迎改变需求,敏捷过程通过变化来为客户创造竞争优势。
这是一个关于态度的声明。
作者指出了敏捷使用者不惧怕需求的改变,是因为他们会尽力的保证软件的灵活性;通过什么来保证灵活性呢?是通过面向对象设计和模式。这一点说明敏捷是离不开OO的。不过这一点并不是什么区别于重型过程的特征所在。重型的方法也会努力的保持软件的灵活性的。
3. 经常性的交付可工作的软件。交付的间隔时间越短越好,间隔的时间可以从几个月到几周。
经常性的交付确实可以更好的把握用户的需求。从而提高系统的质量。
4. 在整个项目的开发期间,业务人员必须和开发人员天天在一起工作。
为了沟通更好的了解需求。

5. 启用有积极性的开发者,给他们提供所需要的环境和支持,并且信任他们能够完成工作。
敏捷把人作为项目成功的最主要的因素,过程环境和管理都被认为是次要的,如果他们对人有负面影响,就要对他们进行改变。

6. 最好的交流方式是面对面的交流。
强调了最好的交流方式是面对面的交谈,而并非文档。

7. 可以工作的软件是首要的进度度量指标。

8. 敏捷过程提倡可持续的开发。责任者,开发者,用户要保持一个长期的恒定的开发速度。

9. 不断的关注优秀的技能和好的设计可以提高敏捷能力。

10. 简单是至关重要的,简单拒绝过渡设计。

11. 最好的架构,需求和设计出自于自组织的团队。
这一点和传统的分析人员,设计人员,开发人员… 分的很细有很大的区别,在敏捷团队中任何人都可以参与分析,设计,开发。

12. 每个一定的时间团队都会对如何才能更有效的工作方面做出总结,反省。然后相应的对团队的行为进行调整。

 

以人为本的敏捷开发
“既然无法阻止变化发生,我们就要找出适应变化的方法。”Fowler并非空手而来,随他登场的还有敏捷开发。

什么是敏捷开发?一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。简言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

敏捷开发是全新理论吗?答案莫衷一是。细心的人们可以发现,敏捷开发其实借鉴了大量软件工程中的方法。迭代与增量开发,这两种在任何一本软件工程教材中都会被提到的方法,在敏捷开发模式中扮演了很重要的角色。再向前追溯,我们还也可见到瀑布式与快速原型法的影子,也许还有更多。

改善,而非创新。敏捷开发可理解为在原有软件开发方法基础上的整合——取其精华,去其糟粕。因此敏捷开发继承了不少原有方法的优势。“在敏捷软件开发的过程中,我们每两周都会得到一个可以工作的软件,”Fowler介绍,“这种非常短的循环,使终端客户可以及时、快速地看到他们花钱构建的软件是一个什么样的结果。”