构建之法 第五次心得

构建之法9、10、11章

第九章

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

在做软件时,销售人员需要将客户需求告诉开发人员,但是销售人员不能直接把那些语言翻译成程序员能懂的规格说明书,所以需要专门的人来翻译,所以就出现了项目经理这个头衔。负责一个功能的开发和测试的人员和相关PM合作,再由PM和别的小组或客户打交道,大大降低了交流的成本,也大大的加快了效率。

虽然PM很重要,但是PM的盛行也是有缺点的。如果做一个PM没有强烈的责任感和强大的推动力,只是满足于不断讨论得到团队共识,那么团队的项目很有可能不能跟上市场的变化,一直中规中矩,不能吸引用户。作为PM,还要进行风险管理,对技术方面,预算方面以及法律法规方面进行风险分析。

作为PM,需要很多能力:1.观察、理解和快速学习能力2.分析管理能力3.一定的专业能力4.自省的能力。在一个团队中,PM至关重要,作为一个PM,要充分做好自己的分内工作,做好带队工作。

第十章

做一个产品,首先考虑的就是用户需求,不同的用户有不同的需求,但是一个产品不可能完全满足所有用户的需求,哪怕把产品的扩展性做的很好,产品说不定就会出现安全问题。所以我们在做产品时,不是一昧的满足客户需求,而是要知道客户语言或者动机后的真正的需求,针对不同典型用户的需求做出产品。

一个典型用户往往描述了一组用户的典型技巧、能力、需要、想法、工作习惯和工作环境等等。当我们定义了最初的典型用户之后,需要真正去理解用户,了解他们的真实想法,不断细化典型用户。

当我们完善了典型用户的定义之后,就需要创立场景,深入理解用户需求。用户和系统有无数种可能的交互情况,写场景时要有针对性。场景需要设计场景入口,来描述场景如何开始,并且描述用户在这个场景中所处的内部和外部环境,最后给场景划分优先级,按优先级排序写场景。

用例也是很常用的需求分析工具。用例有五个因素:标题、角色、主要成功场景、步骤、扩展场景。使用用例,可以让团队成员更快找到用户的需求和软件的功能点,这些功能点及需求都应该有具体的行动描述。

做软件也需要写规格说明书,分为:软件功能说明书和软件技术说明书。功能说明书要定义好相关的概念,规范好一些假设,避免一些误解,界定一些边界条件,描述主流的用户/软件交互步骤,说明功能的副作用,还有对服务质量的说明。技术说明书用于描述开发者如何实现某一功能,或者相互联系的一组功能。功能驱动的设计也非常重要,把用户需求变成团队成员可以直接操作的开发工作。

第十一章

这一章讲的是软件设计与实现,写软件就是要解决用户的需求,所以软件设计就是要充分了解到用户需求,并且尽量去实现。分析和设计有很多方法:以文字为主的文档,用图形为主构造的模型,用数学语言的描述,用类自然语言+代码构造的描述,源代码加注释也能描述。对于软件的分析,需要给事物事建造出一个模型,来描述事物、各个事物间的联系。可用思维导图、实体关系图、表达控制流、统一的表达方式。软件设计不是只有一种方法,有形式化的方法、文学化编程,很多软件需求可以抽象为对符号的运算和变换。写代码时,我们还需要写一些注释,但是修改代码时,不能及时修改注释,也会很麻烦。

写软件时,往往会有很多问题,然后就需要不断地查找参阅,以及和同事沟通,这样的话开发软件工作时间有时候会超过预期。

时间: 2024-10-25 21:24:45

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

构建之法 第三次心得

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

通读构建之法提出五个问题

我是通过`软件工程课`认识这本书的.老师要求读一遍构建之法.自己偷懒,其实没读完,大致翻了翻.翻看粗读后,初步有一下感受: 1. 这不是一本传统的教材,没那么多晦涩的概念. 2. 排版挺好看的,文章穿插图表,很精致. 3.语言幽默好懂. 在没读此书之前,只是觉得为什么软件工程里还会有这么多方法,软件工程不就是一些人合作做个项目就好了嘛?但现实远远没有想象的那么简单.<构建之法>一书一共有17章.每个章节讲述不同的重点.构建之法的每一章都是独立的子章节,并且涵盖了测试.项目经理.开发人员.用户体

构建之法第五章学习

今天我学习了<构建之法>第五章 团队和流程.首先我了解了写了再改模式(Code-and-Fix) 史蒂夫·迈克康奈尔(Steve McConnell)在这里提到了不少开发流程.第一个提到的开发流程.这个流程也有好处,不需要太多其他准备或相关知识,大家上来就写代码,也许就能写出来,写不出来就改,也许能改好.当面临下面的任务时,也许这个方法是有用的.但是,要写一个有实际用户.解决实际需求的软件,这个方法的缺点就太大了. 然后我学习了瀑布模型 当软件行业还在年幼的时期,它从别的成熟行业(硬件设计,建

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

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

构建之法第五篇阅读笔记

今天将构建之法剩下的阅读完了,主要讲述如何组队一起设计一款软件软件设计与实现过程中,着实有这么一句话:在理论上,理论和实践是一回事:在实践上,理论与实践却是两回事.若是只是在理论阶段讨论着实践,就永远不知道想象中的目标实现难度与实际的目标实现难度差距有多么的大.这在课程结对编程中有所体现,也感触颇深,动手前将设计思路商量地基本完美,大多会遇到的问题也都通通解决,然而到了实现环节就出问题了,发现原来之前商量的方法并不可行,还有很多突发的问题没有考虑到……所以,有的程序可以“一拍”即得,有的不行.构

构建之法 第六次心得

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

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

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

构建之法 第七次心得

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

构建之法——第五篇

上一周对于需求分析那一模块的内容还存留一点的疑问,经过一周的学习,弄清楚了以下几个方面. 对于软件需求的类型,以及利益相关者,我们根据不同的角度进行了以下的划分,对产品功能性的需求,对产品开发过程的需求,非功能性需求,综合需求:因此,对于软件产品的利益相关者而言,我们要弄清楚"他们想从软件中得到什么".当获取用户需求以及进行用户调查的时候,我们可以采用焦点小组,深入面谈,卡片分类,用户调查问卷,用户日志研究,人类学调查,眼动跟踪研究,快速原型调研,A/B测试. 竞争性需求分析的框架,根