读完《构建之法》后所产生的问题

花了一段时间来读完了《构建之法》,觉得从中学习到了很多知识,当然对于书中的内容我也有一些不理解,存在一些疑问需要解答。

第一个问题是我看完本书第2章所产生的。按照书上对于一个软件工程师的评价标准来说我们这个团队里大部分都不是合格的软件工程师,因为我们个人技术都没有很好的储备,那么有什么比较有效的方法来提升我们的能力?

第二个问题是看完第6章产生的。对于我们这样一个4人小团队,且所要研发的软件项目不是特别复杂,能够借助使用敏捷流程吗?

第三个问题是看完第9章产生的。如果一个团队所开发的项目不索求任何利益,也不需要和别的团队合作,项目经理同时也没有开发软件的技术和能力,那么是否就不需要项目经理了?

第四个问题是看完第11章产生的。在软件开发阶段应该经常会遇到瓶颈,比如写不出代码这个问题,那么整个团队情绪会受到影响,这种情况下改怎么处理?

第五个问题是看完第16章产生的。我们现在真比较困难去想出一些创新,因为科技太发达,很多软件都已经被他人开发出,所以有什么方法能够帮助我们去创新吗?

这就是我看完这本书后想提出的五个问题。

时间: 2024-11-07 04:26:42

读完《构建之法》后所产生的问题的相关文章

学习构建之法后的疑问

通过一个学期的学中做,做中学这样的学习方法,深深的感觉到了与平时听课学习方式的不同,收获很多.我学习完构建之法这本书后仍然有几个小问题.’ 1.成功的软件总是解决了我们生活中的迫切需求,但是不同的人群有不同的需求,我们如何去权衡各种需求,从中取出最核心的需求,我们该如何完成一个好的需求分析? 2.在实际制作软件时,外观.需求.性能.效率,我们该如何取舍?我们需要注意些什么才能更好的完成开发设计? 3.优秀的产品总是需要优秀的团队,但是在有限的资源下,怎样才能磨合出优秀的团队,探索出合适的团队模式

对读构建之法后提出的五个问题

读构建之法有以下几点疑惑: 1.如何使自己的开发思维更加敏捷? 2.如何分配好团队里面成员的任务,来达到最好的工作效率? 3.当面临用户的需求和优化后的软件起冲突时,用户的需求一定是最重要的吗?那么用户根本不了解优化的软件的好处,一定强制要求修改怎么办? 4.如何使自己的产品在市场上占有绝对的优势? 5.什么样的软件开发团队要开发什么样的软件才适合敏捷流程?

读构建之法后的五个问题

1.如何使自己的开发思维更加敏捷? 2.如何分配好团队里面成员的任务,来达到最好的工作效率? 3.当面临用户的需求和优化后的软件起冲突时,用户的需求一定是最重要的吗?那么用户根本不了解优化的软件的好处,一定强制要求修改怎么办? 4.如何使自己的产品在市场上占有绝对的优势? 5.什么样的软件开发团队要开发什么样的软件才适合敏捷流程?

读构建之法后的问题

1.个人技术与个人能力的关系,个人技术越高能力越强吗? 2.怎样在团队中与伙伴合作?就像我们现在的小组只有5个人,但是一盘散沙,总是说不出什么原因 3.如果客户需求不合理,作为PM应如何处理? 4.如果在开发过程中需要其他新知识(特别复杂.繁琐)应如何? 5.团队领导者对整个团队影响大吗?团队的凝聚力取决于领导者还是个人的想法? 6.感觉书中成为软件工程师的要求离现今的我有些遥远,怎么破?

构建之法后三章读后感

开始读这本书,最大的感受的感受就是软件工程原来是可以这么学的,以前学习软件工程的课程的时候,总是感觉这门课程及其枯燥无味,总是在说太多的理论,很少 会涉及到实践,甚至根本就是没有实践这个环节,所以学习很无聊,但是读到这本书,真的是全新的感受,首先,不仅仅只是在说理论了,加入了很多实 践的东西,而且还可以在网上可以与其他人进行交流学习心得. 整本书从实际软件开发的各个阶段出发,详细地分析了软件工程的各个环节,如:需求分析.设计实现.用户体验.软件测试已经最后的发布等等. 首 先,说说代码风格,一个

构建之法的读后感

七月份读完了构建之法这本书,粗读,基本了解了软件工程这个专业的工作,就业,和前景.目前有如下体会(构建之法这本书正如前言所介绍,适合软件工程的任何阶段去读,我现在只阅读了一遍,还会继续地读下去): 一,      原来,软件工程并不是像我再选专业之前认为的那样,只是一群人在一起敲代码.软件工程的定义是把系统的,有序的,可量化的方法应用到软件的开发,运营和维护上的过程.(构建之法P8),而软件工程这个专业里细分了,软件需求分析,软件设计,软件构建,软件测试,软件维护.以前只是简单的构想,软件只是一

读《构建之法》1,2,3章后感

读完构建之法1,2,3章后,我对软件工程有了初步的了解,所谓的软件工程就是一整套的开发,运营,维修等流程,软件工程把这流程规范化了.我明白了软件开发过程中遇到Bug是很正常的事,这需要我们开发者去通过多次的JUnit去排除,修复Bug,以达到软件的正常运行.而完成做好这些工作需要一个好的软件工程师,需要一个好的软件开发团队,一个好的软件工程师要有一个好的开发习惯,更需要熟悉掌握一定的软件开发知识技巧,而掌握这些东西需要程序员不断去学习知识,总结经验,使自己 达到一定的等级.看完书后,我深知自己还

软件 = 程序 + 软件工程(构建之法读书笔记一)

在我正式开始阅读这本书之前,我对于软件工程这个词汇的概念还是模糊的,认为它只是停留在是一门学科,一个专业,或者是一大堆硬生生的理论知识,然而当我读完构建之法这本书的推荐序和第一,第二版前言开始,我就深刻意识到我之前对于软件工程的肤浅认识是多么错误. 我看书一般喜欢从从书的封面开始看起,或许这也是大多数人看书的习惯,·在本书的封面素描着一副鲁班锁,刚开始让人感觉有点奇怪,明明是一本讲软件工程的书,为什么要用鲁班锁做为封面图案呢?原来玄机深藏于鲁班锁的内部,这鲁班锁从外部看,是严丝合缝的十字立方体,

软件工程-构建之法 阅读笔记

在我正式开始阅读这本书之前,我对于软件工程这个词汇的概念还是模糊的,认为它只是停留在是一门学科,一个专业,或者是一大堆硬生生的理论知识,然而当我读完构建之法这本书的推荐序和第一,第二版前言开始,我就深刻意识到我之前对于软件工程的肤浅认识是多么错误. 我看书一般喜欢从从书的封面开始看起,或许这也是大多数人看书的习惯,·在本书的封面素描着一副鲁班锁,刚开始让人感觉有点奇怪,明明是一本讲软件工程的书,为什么要用鲁班锁做为封面图案呢?原来玄机深藏于鲁班锁的内部,这鲁班锁从外部看,是严丝合缝的十字立方体,

观《构建之法》有感

大学这三年,说实话很少去真正看一遍书,最近老师要求老师要求写个构建之法的读后感,本想是应付下任务.不过,在我阅读了十几页之后,渐渐对这本书产生了兴趣,特别是里面的讲解例子让我更加枯燥的软件书籍第一次有了改观.虽然本人学的是软件工程专业,但是说来惭愧,对于学习了三年的软件工程,软件工程这四个字的含义,我自己却也没能其真正理解.别人问我什么是软件工程专业,我只会通俗的解释就是设计软件的,敲代码,做程序的.阅读了构建之法后,我对软件工程及软件有更专业的认识,软件工程+程序=软件.而软件工程是把系统的,