Agile Software Development ——敏捷开发

 

敏捷?

       过去几年中,软件行业中出现了一个新词汇——agile;与此同时,一个关于新的软件开发方式的变革正悄然兴起。

       在老师的引导下,我阅读了Agile Guide网站上的几篇文章,并查阅了相关资料。不得不说,这一系列全新的软件工程方法确实给了我在团队作业方面的诸多启发。

       个人理解,敏捷开发并不是一种确定的开发方式,而更像是一种软件开发过程中的思路指导。有一些概念,与敏捷开发是分不开的,如:极限编程,持续集成,结对编程,TDD等等。这些概念并不完全隶属于敏捷开发,但又与其有着千丝万缕的联系。因此,我更倾向于将敏捷开发当作一种开发的思路,它有着一些原则,从而衍生出一系列的开发方法。

       无论如何,敏捷开发有着两条基本原则:

  1. Agile methods are adaptive rather than predictive.

敏捷开发具有适应性,而非预见性。

  1. Agile methods are people-oriented rather than process-oriented. 

敏捷开发是面向人的,或者说,以人为核心的。

       这是两条很关键的原则,与此相应的是传统开发过程中的两大弊病。首先,传统开发过程中,往往制定了详细同时繁杂的计划。而这些计划很难被遵守,因为需求时常是变动的;毕竟工程的开发并非一朝一夕,不变则跟不上潮流,做出的产品就会过时。于是,在修改功能的同时,又要去更新长篇大论的文档。这种拉锯的过程不能说没有意义,但也颇为——原始。既然需求无法更改,我们就应该更改我们的思路:需求经常变动?那好,我们就不去做详尽的计划,而是灵活变动,小文档,小版本,简洁明了,经常发布,做好改动的准备。有预见性的开发,将更灵活,更直接。

       其次,传统工程开发将人作为部件,好像程序中的块:每个人有自己的位置,有自己的功能,其他不需劳神。表面上看,这样的方式清晰明了,只需要像零件一样运作起来就可以了。但实际上,有一个致命的缺陷:人并不是零件。这样的氛围下,人失去了主动性,失去了工作的动力,忽视了思想碰撞火花能够得到的优势。在曾经的工作中,我也碰到过类似的情况:在一次活动的准备中,部里分工不同的小组只是机械地执行了互相间的联系,而没有对一些漏洞提出质疑。虽然,活动依然完成了,但是浪费了很多资源——我们本可以做的更快,更好。这就是当人成为机器的时候产生的可怕后果。我们应该改变传统思路,以人为核心,发挥每个人的主动性,让思想碰撞,让思维交流。这也是敏捷开发中五大价值观力图强调的:沟通,简单,反馈,勇气,谦逊。生物学中存在集智的概念:低智商的蚂蚁聚集在一起竟产生分工这样的社会行为;对人类更要将此发挥至极致。

       在这两条原则的指导下,许多开发方法应运而生。这些方法与我们距离并不遥远,事实上在团队协作中触手可及,许多都给予了我启发。在团队作业中,希望能够在我的团队中推进实践。

启发

极限编程(XP)

       极限编程严格意义上并不是敏捷开发的一部分,而应该是与敏捷开发平起平坐的一种方法。顾名思义,其宗旨可以总结为:将需求做到极致。例如,我们需要了解客户需求,那就极限为之,与客户形影不离,使其成为团队的一部分,那么对需求的理解与更新势必登峰造极。诸如此类。

       对于团队作业,我们可以效仿这种极限的做法:

       我们的工作环境要好,极限之:我们选定一个教室或其他场地,布置白板,工作图,桌椅,电源等,工作时间就都处在一起,甚至围坐一张圆桌,随时交流意见;即使吃饭游戏也一同活动,成为标准的死党和忠诚的队友。

       我们的编程非常关键,极限之:分为多组,采用结对编程,时刻将精力集中于编程。

       我们的协调非常重要:每日进行例会,交流对项目的理解和学习工作进度。

       等等……

       既然要做,就做到极致吧!

站立会议

       这是一种很有趣的会议方式。所有与会者围站成一圈进行会议。这样的会议可以改进坐式会议的许多冗余之处。站立会议更健康,更直观,更活跃,而且更有效率,不会成为“座谈会”。这可以成为我们团队会议的新方式。

持续集成(CI)

       团队合作的项目往往是大家闷头做很长时间,最终一集成就跪了。解决这种问题的方式除了写文档,还有一种更直接的方式——从一开始就进行集成,并持续下去——这也是极限编程思想的一种体现。CI减少了风险,减少了重复过程,对于团队效率有着很大提升。

测试驱动开发(TDD)

       极限编程又一实践:软件测试过程漫长且错误率高怎么办?将测试用例写在前面!在工程的开始就写好测试用例,在用例驱动下进行编程,这样就万无一失了!

结对编程(PD)

       在开发层次,结对编程能提供更好的设计质量和代码质量,两人合作能有更强的解决问题的能力;对开发人员自身来说,结对工作能带来更多的信心,高质量的产出能带来更高的满足感。在心理上,当有另一个人在你身边和你紧密配合, 做同样一件事情的时候,你不好意思开小差, 也不好意思糊弄。在团队管理层次上,结对能更有效地交流,相互学习和传递经验,能更好地处理人员流动。因为一个人的知识已经被其他人共享。

结语

       以上就是我对于敏捷开发及其相关概念学习之后一些总结和感悟。事实证明,我们是人:无论完成什么类型的工作,我们都需要以人为本,将人性的因素考虑进来——毕竟我们的根本属性。

       最后复习一下敏捷开发宣言:

Manifesto for Agile Software Development

We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work we have come to value:

 

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

 

That is, while there is value in the items on the right,

 we value the items on the left more.

原文地址:https://www.cnblogs.com/libcan/p/3371351.html