构建之法 第四次心得

第六章

学习了之前的内容之后,我了解到了团队合作的流程以及在编码时候一些格式的注意,在学习第六章后,对敏捷流程有了大致的了解。敏捷流程是一种很好的软件开发的流程,我认为在软件开发时,敏捷开发可以使得软件可以在满足客户的满足时不断地快速更新。

敏捷开发需要不断关注技术和设计,这种开发模式需要以有进取心的人为项目核心,并且充分支持信任他们。软件开发是一个很漫长的过程,也不是一个人的事情,一个人的效率高是不好完成这个开发的,所以必须要一直总结怎么提高团队效率,并且不断地提高团队内每个人写代码的能力。在敏捷开发中,会有很多的问题和解法,需要考虑到各个需求和任务之间是有种种复杂的依赖关系的,除了优先级之外,我们还要考虑相互的依赖关系。

有时候做软件开发的时候并不是从一开始定好的,中途可能会因为一些突然加进来的内容,有时候这个功能可能需要修改很多内容,所以很多时候都要结合多项因素综合考虑是否需要停下来先修改再完成,还是应该继续做下去,最后再做改动增删。在软件开发中,写完该写的代码之后,并不会变得轻松,因为还有最后的综合,验证各个功能单元的正确性等等,这部分非常重要,而且需要很多时间去完成。但是我觉得并不是所有软件开发都适合用敏捷开发,我认为并不可能每个人都很厉害,都能在短时间内尽快的完成项目,所以要视情况而定,并不是所有人都适合这种方式。软件开发一定要精益求精。

第七章

学习了第七章之后,我觉得MSF是建立在敏捷开发的基础上的,这种团队模型有9条基本原则:推动信息共享与沟通,为共同的远景而工作,充分授权和信任,各司其职并且对项目共同负责,交付增量的价值,保持敏捷、预期和适应变化、投资质量,学习所有的经验,与顾客合作。对于一个公司的项目,最重要的就是保护技术机密,保证不会泄露出去,提高安全性,采取必要的保护措施。正如之前阅读第五篇的时候说的,团队合作,重要的是团队的合作,所以大家必须要很明确目标是什么,并且一起完成,虽然成员间实力可能有所偏差,但是每个人都应该要努力。

无论是在什么开发模式中,充分授权和信任都是必要的,不然是做不好好的软件的。如果成员之间就不信任,那么势必不能合作,不能共同进步。MSF过程模型是从传统的软件开发瀑布模型和螺旋模型发展而来的,结合了两个的优点。MSF团队模型还可以推广到包括操作、业务和用户等外部因素,要在对立中寻求共同利益,在冲突中达到平衡。

第八章

每个软件开发最重要的就是需求分析,没有需求分析,就不能进行下一个步骤。在软件开发中,需要对产品的各方面需求进行分析,比如对产品功能性的需求,开发过程的需求,非功能性需求,综合需求。软件开发最主要的就是针对用户的需求的,所以这部分很重要。

在现实生活中,无论是什么方面,需求都是销售商品的首要条件,我认为需求也应该分一下主次,主要的需求着重分析。在做软件开发的时候就需要考虑到用户的最重要的需求。在用户需求这方面,可以采取用户调查问卷的形式,向用户提供实现设计好的问题,让用户回答,这种方式可以更加容易了解用户的需求,更容易做出满足用户需求的软件。

竞争性需求分析,就是需要找一些别人还没想到的东西和人家进行竞争,并且对自己和竞争对手进行分析,了解到自己的优劣势,以及对手的优劣势。NABCD是一种很好的,很有效的方法,N是需求,A是做法,B是好处,C是竞争,D是推广。

进行需求分析之后,就是要考虑如何实现这些需求,还要将这些功能结合起来,呈现给用户。在实现这些需求的时候,我们应该要想清楚为什么要先做这个功能,谁做哪部分。功能性分析可以分成杀手功能,外围功能,必要需求,辅助需求,可以让团队看到自己感兴趣的功能,然后决定谁来做。

做项目重要的是有计划,有目标,有决心,所以无论谁做项目,都要进行需求分析,估量好做项目的时间,需求等,并且努力实现。

时间: 2024-11-10 06:31:49

构建之法 第四次心得的相关文章

构建之法第四章学习心得

今天我学习了构建之法第四章,主要讲述了两人合作的理论和知识点.合作,无论在任何领域,都是不可缺失的,往往能产生不可替代的效果.同样在软件设计中也是如此,经过我的学习,我了解到软件设计中两人合作主要包括包括代码规范.极限编程.结对编两人合作的不同阶段以及影响他人的技巧. 其中最让我印象深刻的是代码规范.包括:代码风格规范和代码设计规范,代码风格规范主要是文字上的规定,看似表面文章,实际上非常重要:代码设计规范牵涉到程序设计.模块之间的关系.设计模式.等方方面面的通行原则: 同时,我了解了代码风格规

构建之法 第三次心得

构建之法 第四.五章心得 学习了第四第五章之后,我了解到了两人合作的注意要点,还有团队和开发流程.软件都是在相互合作中完成的,合作的最小单位是两个人.每个人的标准都不一样,对于什么是好的代码规范未必认同,所以我们需要给出一个基准线,即什么是好的代码规范和设计规范. 代码规范可以分成两个部分,一是代表风格规范,主要是文字上的规定,看似是表面文章,实际上非常重要.二是代码设计规范,牵涉到程序设计.模块之间的关系.设计模式等方方面面的通用原则.代码风格的原则是:简明.易读.无二义性.这里可以从几个方面

构建之法小结四

本周阅读了构建之法的第四章,本章讲了两人合作的前提是代码要规范 (包括代码风格规范及代码设计规范)及代码复审,然后才能结对开发. 以前,写代码时,很多时候是上手就写,一个大括号包含所有内容,虽 然大一时学过函数.类等知识,但写代码时并不使用这些知识. 很显然这样,不利于别人及自己后续阅读代码,因为代码最终是要给人看 的,要想一个团队合作开发,必须有一些大家一致遵守的规则,这样团队 才能良好的进行工作. 在以后的编程实践中,我会注意按照本章的代码规范来编写程序,多加练 习.

《构建之法》读后心得,问题

我觉得构建之法这本很不错,书的内容给我一种欢快的阅读体会,能让人更加的快速去接受里面的内容,并吸收为自己所用:并且里面的内容都举例生活中的例子,并且在一些容易有疑惑的地方,以问答形式解答,而且语言通熟易懂,使人看上去更加的了解其实软件工程就在我们的身边. 之前上过软件工程这门课程,那本软件工程的书本不像<构建之法>,都是一些很枯燥乏味的内容,并没有像<构建之法>让人舒适,让人以一种欢快的阅读体会.其实软件工程就是包括了“开发.运营.维护软件的过程中的很多技术.做法.习惯和思想.软件

构建之法 第六次心得

构建之法12.13章小结 第12章 这一章讲的是用户体验,对于软件的使用,用户的体验是非常重要的方面,如果一个软件给用户的体验不好,那么这个软件无疑是不会受到欢迎的.但是用户体验和用户界面的领域不是那么容易的,这两个需要丰富内容的学术领域.就像一个游戏,如果这个游戏界面单调,但是操作又非常复杂,那么用户可能很快就失去了兴趣. 在设计软件界面时,我们也要考虑到使用这个软件的人群的特征,使用习惯等等,可以根据这些来设计界面,还要让用户在每次使用的时候减少对自己没有价值的部分的访问,尽量使得用户不浪费

0405构建之法第四章--读后感

<构建之法>这本书的第4章讲的是关于两人合作的内容,对于书里所说的两人的关系就和驾驶员.领航员类似,通过结对合作,令我意识到了编写程序不仅仅要自己能明白,也要便与他人查看和理解自己的程序. 代码规范性,我们编写代码时要注重代码风格规范和代码设计规范,无论是类名,对象名,缩进还是行宽什么的,在结对子编程时都要有所规定,不然到后面出现的类或是对象多了,就很容易混乱,分不清楚谁是谁.要学会封装,编写函数,将功能模块具体化,减少主方法里面的代码,避免大规模的出错. 代码的复审,在平时编程程序时,我也会

构建之法 第五次心得

构建之法9.10.11章 第九章 学习了第九章之后,了解到了在一个项目中项目经理的重要性.生活中,无论什么团队工作,都需要一个领队,来掌控团队项目的发展,以及各个成员工作的分配.PM指Product Manager.Project Manager.Program Manager.这个章节主要讲了Project Manager即项目经理,PM要凭自己的能力,把用户的需求展现成其他成员能够理解和执行的语言.项目经理需要正确地协调团队内部外部,调配各部门资源和时间,有效进行风险管理,保证一个项目顺利按

《构建之法—现在软件工程》心得体会

作为软件工程专业的一员,我觉得自己并没有学习到太多跟专业有关的知识,甚至不是很清楚的了解“软件工程”这一词的意思,每逢家中的长辈问学的什么专业,我都需要用很白化的词语解释,就是开发游戏的软件,纯属敷衍了事.因为本人自己也不太清楚. 本学期有一门课程叫——软件测试,可此课程居然有两本教材,后经老师介绍后,才知道<构建之法——现在软件工程>这本书由我们自己去阅读.起初由于无聊,我把<构建之法——现在软件工程>这本书拿出来看,没想到根本停不下来,它把软件开发方法讲得清晰有趣,书中还遇用许

构建之法 第七次心得

构建之法14.15章总结 第14章 这一章讲的是质量保障.在我们做软件的时候,最重要的是质量,如果做成功的软件质量不过关,那无疑是白费心血,浪费时间.程序的质量体现在软件外在功能的质量,用户体验的质量,国际化的质量,安全性的质量等等. 软件开发过程中有三个主要的特性:好.快.便宜,即软件需要在成本.功能.时间三方面满足利益相关者的需求.一个团队可以靠很多方法来提高程序的质量,比如交付前不断测试,修改,也可以在软件发布之后再一直进行修复问题,但是软件工程的质量需要长期的过程来提高. 软件工程的质量