《构建之法》8,9,10章读后感和总结

第八章:需求分析

需求分析,我觉得需求分析挺重要的,一个需求分析是指对要解决的问题进行详细的分析,弄清楚问题的要求,包括需要输入什么数据,要得到什么结果,最后应输出什么。可以说,在软件工程当中的"需求分析"就是确定要计算机"做什么",要达到什么样的效果。可以说需求分析是做系统之前必做的。需求分析确定了整个团队的方向,那么怎么做好需求分析呢?有以下几个步骤:1、获取和引导需求;2、分析和定义需求;3、验证需求;4、在软件产品的生命周期中管理需求。

第九章:项目经理0

项目经理,项目经理名字好像好高大上,之前觉得项目经理没有什么用,现在觉得项目经理有着敏锐问题的能力,察觉未声明的假设以及解决人与人之间的冲突,同时还需要更多的系统化的管理技能。项目经理的能力很重要,有能力并且得到大家认可支持的项目经理才是一个优秀的项目经理。自省能力中的“拍屁股”走人是我最讨厌的事情,但是可能谁都有这么一种冲动。——“啊呀,我真做不出来,不做了。你们自己玩吧。”这种心态可能会有一时,但当你勇敢面对这些困难,并认真学习如何打败它时,你是个优秀的人。当你打败困难之后,你会有满满的自豪感。这种感觉比你放弃“拍拍屁股走人”的感觉好多了。再者,得到大家支持也很重要。一个无法得到团队成员支持的项目经理,大概也无法得到领导的支持。

第十章:典型用户和场景

光看用户的表面语言和行动远远不够,所以我们要找到用户背后的动机。不然实现的功能总是无法取得用户的满意。以致于产品可能要多次“返工”。“返工”不仅仅考验软件开发团队,也考验用户的耐性。也许用户觉得这次在你的公司购买的软件这么麻烦,下次他会考虑换一家公司进行购买。我们的软件不是给所有人用的。每个人都想自己做的软件多一些使用者,但是在做软件的时候,我们不能考虑太多类人。需要考虑的是主要使用我们软件的典型用户,一些跟我们软件实际上并无交集的人并不能算为典型用户。

2、Sprint总结

     在此次Sprint中因为各种原因我们的进度比较慢,后来经过调整我们的速度快了一些,慢慢跟上了进度。在合作的时候虽然成员们在能力上参差不齐,但好在可以形成互补,所以合作进行的还算顺利。我们在分配任务上还不够合理,这方面要继续加强。

时间: 2024-12-28 12:11:23

《构建之法》8,9,10章读后感和总结的相关文章

《构建之法》第四章读后感--软件工程

<构建之法>第四章读后感--两人合作 1.代码风格很重要,因为良好的代码风格,有益于两人的合作甚至多人的合作. 个人认为 : 良好的代码风格的培养就是 多去阅读别人的优秀代码 ,用于提高并且培养自己的代码风格. 2.关于结对编程的重要性 2.1 结对编程能提高设计质量与代码质量 2.2 结对有益于学习交流 3.如何结对编程 3.1 主动参与讨论,提出设计方案或者问题的解决方案 4.代码的复审 复审可以提高代码质量,优化项目性能.

构建之法五、六章读后感

在本周我主要学习了构建之法的第五章和第六章,第五章主要讲述团队和流程,第六章主要讲述敏捷流程: 软件团队的模式有:主治医师模式.明星模式.社区模式.业余剧团模式.秘密团队.特工团队.交响乐团模式.爵士乐模式.功能团队模式.官僚模式: 开发流程包括:写了再改模式.瀑布模型.瀑布模型的变形(生鱼片模型.大瀑布带着小瀑布): Rational Unified Process统一流程(RUP):包括业务建模.需求.分析和设计.实现.测试.部署.配置和变更管理.项目管理.环境: RUP的四个阶段包括:初始

《构建之法》第十七章读后感

通过阅读<构建之法>第十七章,不能说对我造成了什么深远的影响,但是还是感触颇深: 第一,工作分配的重要性,说道工作分配,不得不说我们个小组的组长们,组长不仅仅是一个团队的领导者,更是这个团队的灵魂.它不仅需要了解随时掌握各组员的动向,更重要的是,他需要了解各组员的能力,然后根据个人的能力,然后再去非陪相应的任务,只要这样才能做到“物尽其用”,才能更好的完成我们的项目,有时甚者能更创造出以外的效果,达到更完美的状态.这不仅是组长的能力  其实其无时无刻也体现着我们这个小组的团结力和创造力.当初选

构建之法第五六章读后感

邹欣老师的这本书,写得形象生动,第五章用体育运动等团队例子引出软件开发团队的形式.软件团队形式多样,适用于不同的人员与需求.团队可能会演变的模式有:主治医师模式.明星模式.社区模式.业余剧团模式.秘密团队.特工团队.交响乐团模式.爵士乐模式.功能团队模式.官僚模式等.开发流程模式有:瀑布模式.瀑布模型的各种变形.统一流程.老板驱动的流程.渐进交付的流程等.在过去的学习生活很少有团队合作的时候,看了本章很期待后续与大家团队合作,肯定会遇到很多困难,但只有把学到的运用到实际,知识才会学得更牢靠. 看

构建之法 第6~7章读后感

第六章-敏捷流程 第六章主要详细介绍了敏捷流程,在软件工程范畴里,“敏捷流程”是一系列价值观和方法论的集合.这一章以敏捷流程的Scrum方法论而展开,而敏捷流程的精髓就是在于快速的交付. 敏捷开发的流程如下: 1.找出完成产品需要做的事情 - Product Backlog. 2.决定当前的冲刺(Sprint)需要解决的事情--Sprint Backlog. 3.冲刺(Sprint).在冲刺阶段,外部人士不能直接打扰团队成员.期间每日例会,向同伴报告进度,把问题摆在明面上.同时启动每日构建,让大

构建之法8,9,10章

8.创新分析 创新可以使改良型的,在现有的软件中增加几个新的功能,把某个程序变得更快一点,把程序移植到新的平台.颠覆性的创新,一个新的产品导致就得产品或产业发生巨大的变化或消失.但是如何按部就班地分析需求,有条理地说服别人你的创新呢?有NABCD模型. Need,你的创意解决了用户的什么需求. Approach,找到了需求,就需要使用独特的作法来领先于其他软件了.独特的作法有技术上的,比如有人脸识别技术,有超大规模的数据处理能力.还有商业模式上的,第一个团购,地域上的,第一个苏州公交系统,行业上

《构建之法》第8-10章读后感

第八章:需求分析 本章节讲述软件需求的4个步骤,(1)获取和引导需求(2)分析和定义需求(3)验证需求(4)在软件产品的生命周期中管理需求 .在软件工程中分析软件需求需要考虑相关者的利益关系,例如用户.顾客.市场分析师.监管机构.软件工程师等之间的关系. 讲述了9种用户调研方法:(1)焦点小组(2)深入面谈(3)卡片分类(4)用户调查问卷(5)用户日志研究(6)民族志/人类学调查(7)眼动跟踪研究(8)快速原型调研(9)A/B测试 第九章:项目经理 PM指的是项目经理 Product Manag

《构建之法》第四章读后感

一个人,纵使才华横溢.能力超群,如果不能较好地融入社会,不善于跟周围的人沟通.协作,他就不会在成功的路上走很远,更无法实现自己的理想与目标. 我想这句话应该可以包括第四章大意.第四章还让我们了解到我们应该对我们写的代码更加规范,使之做到简明,一度,无二义性. 代码复审,在我们生活中最长见的应该就是同伴复审了,在复审中,找到编译器没找到的错误,减少我们代码的缺陷,然而同伴复审,最好不过的就是结对编程了,在结对编程的过程中,让我们两个人相互督促,一起进步,两个人虽然可能效率不比单人快,但是起码能分担

《构建之法》前三章读后感

通过第一章讲述的概论,理解到软件工程到底是什么,又为何要叫软件工程,他对我们的生活又有什么影响. 通过一些实例我也认识到客户需求分析的重要,就阿超那样的四则运算一样,渐渐的功能和需求就多了. 在第二章中,我又认识到个人能力和测试的重要性,在一个程序中运行的要快,是几秒钟而不是几分钟. 一个好的单元测试也是有很多标准的,通过对标准的分析又能找到许多缺陷,就要写下测试的方法. 所以说如果我们不经分析就盲目优化,也许会事半功倍. 第三章软件工程师的成长,评价软件工程师水平的主要方法是什么.这个职业的发

构建之法6、7章--读后感---软件工程

第六章:敏捷流程 在 6.2节中定义好任务究竟是什么?书上敏捷第三步中有个例子写道:”去你的,要改主意,也要等老子冲刺再说!“,这句话我不是很理解,万一产品负责人改变主意,重新确定好任务,那么程序猿还得将之前的任务继续“冲刺”下去吗? 第七章:MSF 随着信息时代的高速发展,MSF也具有它的基本原则: 1.推动信息共享与沟通: 2.为共同的远景工作: 3.充分授权的信任: 4.各司其职,对项目共同负责: 5.交付增量的价值: 6.保持敏捷,预期和适应变化: 7.投资质量: 8.学习所有的经验: