不要只在字面上理解敏捷开发

小谈敏捷
服务器君一共花费了260.742 ms进行了5次数据库查询,努力地为您提供了这个页面。
试试阅读模式?希望听取您的建议

敏捷是一种高效的开发模式,但并非任何项目都适合,而且并非一定要推翻现在的瀑布模式完全采用敏捷。敏捷的本质是什么?敏捷的核心原则是什么?瀑布模式能否将敏捷的思想用过了从而优化现在的模式呢? 

没有任何一种模式说是适合于任何公司,任何项目,还是要从公司特性,项目特性来看。下面就结合敏捷思想一一解读,看那些适合优化瀑布模式。

敏捷宣言: 

  1. 个体和交互 胜过 过程和工具 
  2. 可以工作的软件 胜过 面面俱到的文档 
  3. 客户合作 胜过 合同谈判 
  4. 响应变化 胜过 遵循计划 

敏捷12原则 

1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。 

这点指导我们要尽可能最早将客户需求明确、细化,当然很难一次性将客户的需求完全挖掘出来,但是我们起码可以试着提高我们的需求挖掘,细化能力,每一次和客户(市场人员)交流能够尽可能多地明确需求,减少需求迭代的次数。

2.即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。 

敏捷提出的背景就是应对客户不断改变的需求,除了上述提到的第一点来减少迭代次数外,也要保证迭代影响面尽可能小。这就要求我们设计的代码耦合性尽可能低。

3.经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。 

交付间隔越短,就会越多越明确地了解客户的需求。在瀑布模式中其实也可以指导我们多和需求引入人、合入人交流。

4.在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。 

  • 保证项目的稳定,只有一个稳定的团队才能带来项目的持续进展。
  • 也可进行结对测试,既减少沟通量,可通过模块责任人制保证质量。 

5.围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。 

团队的成功,离不开项目人员和项目负责人的相互支撑。提供任何需要的环境和其他支撑工作,可通过环境固化提高环境复用率。敏捷是以人为本的模式,离不开团队各成员的互相信任和支持,但这并不代表100%的自由,我们还是需要一定的抽查机制来检验相应的工作成果的 

6.在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈。 

要减少无效沟通,提高沟通质量,确保沟通的高效性。但是并非就不要文档了,有时候项目的过程还是需要一定的显性文档的,如bug管理平台,svn配置管理等来对工作进行归档,检视,做好PDCA。 

7.工作的软件是首要的进度度量标准。 

软件进度的度量标准有多种,但是不要忘了最重要的一点,我们最终是要开发出高质量的 满足客户需求的软件。可以把需求细化成一个个story,设计并测试完即可认为完成一个功能的build。另外进度的敏捷也可以考虑如下方法或理念:敏捷就将任何可提前做的事,前移,可以采用看板管理进度。doing,done,to do等了解短阶段应该要完成的任务,其实项目中经常会发生这样的现象,前面轻松后面紧张很大一部分原因是,做完前面的事后不知道后面要做什么事,只能再等负责人的安排。 

8.敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。 

这个需要保证项目成员的稳定,不能出现这样的现象,这个人员过几天被抽调了,那个成员过几天又被抽调了。而且需要保证一定的老员工和新员工比例,既保证人员可持续发展,也要保证项目可持续发展。 

9.不断地关注优秀的技能和好的设计会增强敏捷能力。 

变化是IT最大的杀伤工具,也是IT最大的魅力。要时常拥抱变化,新功能用什么技术可以更高效地开发维护等。

10.简单——使未完成的工作最大化的艺术——是根本的。 

复杂的事情做简单是一门艺术,很多时候一个js页面,一个cgi都被开发人员设计的相当复杂,如果能够从小事开始做起,简单将不再遥远。不过这个也许需要一定的培训和分享制度。

11.最好的构架、需求和设计出自于自组织的团队。 

当前代码的高耦合性是因为最开始软件的架构出现问题,如果一个公司有架构师一样的人(当然能力必须达标),有了一个好的架构,模块的低耦合性也许会不再是空话。

12.每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。 

一日三省,经常要对自己的工作进行总结反省,进行一定的沉淀,才能在新的起点上更好的前进。不要等项目结束了才开始总结,要经常总结,我为什么没有发现那样的bug,为什么测试效率这么低,只有反省总结了才会有进步。 

其实瀑布模式没有什么错,如果保证第一次就把正确的事情做正确,再结合敏捷的一些思想优化当前的工作,我相信会比单单地用敏捷的“拿来主义”强的多,最重要是理解敏捷的思想。另外完全的敏捷需要公司各平台(自动化,公共技术平台)的强力支撑,如果不能完全敏捷,那就从半敏捷做起,考虑目前哪些事情可敏捷,可优化,先从局部敏捷做起吧。 

本文地址:http://www.nowamagic.net/librarys/veda/detail/2040,欢迎访问原出处。

不打个分吗?

转载随意,但请带上本文地址:

http://www.nowamagic.net/librarys/veda/detail/2040

如果你认为这篇文章值得更多人阅读,欢迎使用下面的分享功能。
小提示:您可以按快捷键 Ctrl + D,或点此 加入收藏

大家都在看

阅读一百本计算机著作吧,少年

很多人觉得自己技术进步很慢,学习效率低,我觉得一个重要原因是看的书少了。多少是多呢?起码得看3、4、5、6米吧。给个具体的数量,那就100本书吧。很多人知识结构不好而且不系统,因为在特定领域有一个足够量的知识量+足够良好的知识结构,系统化以后就足以应对大量未曾遇到过的问题。

奉劝自学者:构建特定领域的知识结构体系的路径中再也没有比学习该专业的专业课程更好的了。如果我的知识结构体系足以囊括面试官的大部分甚至吞并他的知识结构体系的话,读到他言语中的一个词我们就已经知道他要表达什么,我们可以让他坐“上位”毕竟他是面试官,但是在知识结构体系以及心理上我们就居高临下。

所以,阅读一百本计算机著作吧,少年!

《JavaScript高级程序设计(第2版)》 尼古拉斯·泽卡斯(Nicholas C.Zakas) (作者), 李松峰 (译者), 曹力 (译者)

《JavaScript高级程序设计(第2版)》在上一版基础上进行了大幅度更新和修订,融入了近几年来JavaScript应用发展的最新成果,几乎涵盖了所有需要理解的重要概念和最新的JavaScript应用成果。从颇具深度的JavaScript语言基础到作用域(链),从引用类型到面向对象编程,从极其灵活的匿名函数到闭包的内部机制,从浏览器对象模型(BOM)、文档对象模型(DOM)到基于事件的Web脚本设计,从XML(E4X)到Ajax及JSON,从高级前端开发技术到前沿的客户端存储,从最佳编程实践到即将成为现实的API,直至JavaScript未来的发展,全景式地展示了JavaScript高级程序设计的方方面面。

更多计算机宝库...