Feeling after reading the blog of Agile development
在阅读老师所推荐的文章之前,我先百度了一下有关敏捷开发的基本资料,对敏捷开发有了一个宏观的粗浅的认知。“简单的说,敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。”
从百科的这段文字描述中我们可以发现,敏捷开发从根本上讲是一种软件开发方法,而且这种软件开发方法具有其他方法无法比拟的优势。有了宏观概念后,便开始着手阅读那篇又长又看不大懂的博客了,下面做一些笔记,用我的方式记录些学到的东西,也算做是一种feeling吧。
1.兴起由来:
起初,软件开发过程是一种很混乱的活动,即典型的“code and fix”,即边写边改。都是即兴的决定,没有完整规划。这就会有严重的隐患,当工程越来越大越来越复杂的时候,难以添加新的功能,bugs越来越多且难以排除。这就需要软件开发团队以漫长的时间为代价来换取软件的可靠性,而且还不一定利于维护。
这时,工程方法进入人们视线。工程方法要求十分严格,就好像把写软件模式化流程化了一样,对它进行细致的规定。这样虽然对软件有了预见性,一定程度上提高了效率,但是过程繁琐,coder们生性渴望自由,这种束缚难以让工程方法取得大的成功。
严格的环境下必定会产生叛逆。这时我们的主角便登场了——敏捷开发。它们在无过程和过于繁琐的过程中达到了一种平衡,既纠正了以往的官僚繁琐过程,又不是“无政府无组织”的放任创作,使得能以不多的步骤过程获取较满意的结果。敏捷开发,以其适应性性质和以人优先的理念迅速引起行业极大兴趣。
2.优势特点:
2.1适应性
说到适应性就不得不把它和预见性相比,这里又要提到工程方法。我们说的工程一般可以指土木工程、电气工程等等。这些工程都有一个共同的特点,就是可预见性。比如说我们要建造一座大厦,工程师们会做出一些设计,然后绘制各种图纸交给建造团队,然后高楼便在一切计划好的流程中建起。这建高楼的工程就是可预见的,事先做好规划然后严格执行就可以了。然而软件工程却不是这个样子的,因为“创作”不等于“制作”,“设计”不同于“建造”。软件是“软”的,需求是可变的不仅可预见的,这就需要我们的设计方法能够灵活多变,具有适应性,接受变化。而敏捷开发便具有这样的性质。
2.2把人放到第一位
刚读到这里时,我对此感到十分诧异,不明觉厉。也许没有走出过校门,没有参加过公司的软件开发,原来在曾经的的开发过程中,开发人员竟是相当于可替换的部件这样一个存在。完全把人当成机器,而非有血有肉有思想的一员。也许大家都是这样认为的,不过具体操作中还却不是这样做的。敏捷型开发则非常强调以人为本。并非管理人员决定开发过程,而是由实际开发的人员共同拟定的,是让大家接受一个过程,而不是强加一个过程。
3.个人的一些想法
粗略读了一些文章后我个人感觉,敏捷开发之所以敏捷,原因就是统一优秀的团队。团队中包括各种开发中的角色,大家在一起面对面的交流,误解能在第一时间得到更正,团队成员间多交流(并不限于工作上),多组织些活动,让团队成员间关系更和谐温馨,增加默契。
在保证了人员关系的基础上我们再来谈技术性的问题我觉得才是ok的。文章中多次提到迭代化开发,我觉得是一个很不错的方法。将开发时间分成一个一个固定时间长度的小阶段,每个迭代完成相应的用户故事,新的需求与改动按照优先级情况排在下一个迭代以后。每个迭代之初,进行迭代计划,按照需求的优先级,由小组成员自己领取适合自己规模的工作。然后,进行用户需求划分搞清任务。每个迭代完成的时候,会有一个迭代回顾会议,总结完成的故事点数,演示这个迭代的成果,听取组内成员的意见,以持续改进,增进默契。这样可以让可执行的部分软件第一时间问世,“可以工作的软件胜过面面俱到的文档”,我们可以一层一层排除问题,然后进入下一阶段,这样提高了不少效率。
最后,我想说的就是我们team会在接下来的team project中按照敏捷开发的要点进行实践来实际体会敏捷开发的优势!
posted on 2013-10-16 00:10 hmy-runner 阅读(188) 评论(0) 编辑 收藏 举报