码迷,mamicode.com
首页 > 其他好文 > 详细

第三次读后感

时间:2018-03-22 00:28:49      阅读:169      评论:0      收藏:0      [点我收藏+]

标签:用户   工具   通过   开发   遇到   pos   高效   建议   原则   

《移山之道——VSTS软件开发指南》有感

?         两周时间把这本书看完了,因为我并没有下载微软的这个软件,所以对里面的具体操作还不不太熟悉,但是已经大概了解整个开发的流程。本书一大亮点就是能创造一个生动的故事线,通过一个从什么都不是的软件开发团队,用它们成长的历程,一步一步引导读者如何从一个开发小白,逐渐熟悉开发过程的。书中的专业术语很多,基本上每一个英文缩写都代表了一种在软件工程中非常好的方法或者一种让人耳目一新的工具。而在书中令我最印象深刻的还是MSF中的敏捷开发模式。

?        我最初接触这个名词以为是怎么样在最短的时间内做出一件软件产品,这应该就是敏捷一词的基本含义。其实只要深刻一思考,做产品光有速度是没有任何作用的,若是产品质量跟不上,那么所做的一切全部都是无用功,所以我们所要追求的应该是一种新型高效的开发方法。敏捷开发这一词的解释是以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。书中所说,在敏捷开发中,会把一件比较大的项目分成许许多多的小项目,每一个项目都可以处在相互关联,或者相互独立情况下,在此过程中软件一直处于可使用状态。

?        继续以我们上学期的电设实验为例,我们前期的确做好了技术调研,从各个时期也都分配的好好的,可事实上一开始我们就遇到了很大的困难,以至于我们的进度越来越慢,我们的项目最终也不是十分的成功。首先我们要反思在人员分配上出的问题,我们并没有了解谁特别擅长哪个领域,或者是在开发过程中哪一部比较难(实际上是我们以为比较难的部分实际上很简单,而我们以为很简单的部分却很难),如果当时知道敏捷开发,我们就一定会遵从递增的原则,我们其实不必在一开始对所有的项目细节有所精确地了解,因为就算这么想也不太可能实现,而且正是为了了解我们以为最难部分PID算法那部分的细节,导致我们忽略了硬件搭建时可能出现的问题,所以才出师不利。我们当时应该先定一个大概的框架,在对当前需要面临的问题了解其全部的细节,以后只需在原来的框架上逐渐增加细节就好。而且我们也没有做到投资的最大化,因为对工程评估不足,我们在人员的分工上有了很大的问题,在硬件上我们投入了3个人,而在对项目很重要的角度的获取上,我们仅仅投入了一个人,所以在后期角度模块频频出问题,导致了项目的不顺利。

?        以上和上一篇读后感只是反思,只是当时做的只是一个小项目,我们也没想那么多,以为糊里糊涂就能过去,所以这种不科学的开发之道才导致了最终的失败。在这学期项目开始以后,我会按照书中的建议,以正确的方法进行软件的开发。

第三次读后感

标签:用户   工具   通过   开发   遇到   pos   高效   建议   原则   

原文地址:https://www.cnblogs.com/jahnson/p/8620705.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!