《人月神话》阅读笔记(二)

本书当中有一个要点十分重要。

要保证项目的概念的完整性 。

书中提出了外科手术式的团队组织:

在软件开发组织上的过份民主,往往带来的是没有效率和责任,参与其中的人想法太多,层面参差不齐。

所以,软件开发的组织,应该借鉴外科手术式的团队方式,有一个主要的负责人,其他人都是分工协作的副手,这样效率最好,结果最好。

那么在此种团队组织中,交流就是一个润滑剂了,保证了进程的各个部件的协调进行。

以上的小总结:软件项目的核心概念要由很少的人来完成,以保证概念的完整性

       少就是多,项目的定位需要和功能多少的权衡。太多的想法,使项目没有焦点,什么都要放进去,结果什么都做不像。

         其中项目最大的风险并非技术,而是缺少交流。

众多书籍中,提及要点就是交流。

无论团队内部交流,还是与用户交流,信息交互永远提醒着方向,不断将自己的方向偏向正确。

(团队交流能让项目能够更加稳定地进行下去,而非漏洞百出;与用户的交流,是能了解用户正真的需求,能让软件能够实现目标,存在价值)

时间: 2024-10-10 15:48:34

《人月神话》阅读笔记(二)的相关文章

掌握需求过程阅读笔记01

掌握需求过程 第一章什么是需求 阅读笔记 我们为什么要进行需求呢? 这样是为了使效率更高,并且减少错误步骤所不必付出的代价. 在我们构造产品之前就要知道客户的需求是什么,大多数的组织都是通过系统分析来进行的,但是需求过程与系统分析并不是一回事,虽然他们之间有联系,但并不完全相同.除了系统分析以外,需求也是很有必要的.他可以对你的分析师生涯有更进一步的促进.当我们接触到一个新的产品时,业务事件和使用情况逐渐清晰了起来,系统分析可以对产品进行更清楚的建模,并为需求过程提供有价值的反馈.对需求的了解增

《探索需求》阅读笔记二

在任何相当规模的开发项目当中,孤军奋战显然是像是一种幻想,为了获得一个团队所能提供的容量和差异性,我们必须放弃任何个人英雄主义的幻想,为和他人合作付出代价.而这种人际的花费在会议中体现的最为明显,会议也是一种工具,一种社交工具.很多人都会感觉会议是很可怕的,它有的时候并不会产生什么效果,但是我们离不开它,一旦离开会议,就只能开发出最简单的产品.每一个会议能达到的结果是度量需求工作的健康状态,一个糟糕的会议,说明了需求过程的不完善.要想每一个参与者都完全的参与进会议中,这个会议就必须是稳定的,我们

掌握需求过程阅读笔记—2

通过对事件驱动的用况.网罗需求.功能性需求这三个章节的阅读.使我们明白了在事件的驱动用况上,我们需要通过一些经验法则来定义用况,发现合适的用况:在网罗需求上,我们最需要做的就是进我们的一切可能去罗列用户的需求,并能及时的与用户沟通交流,确保产品符合最新的要求:在功能性需求方面上我们应当明白它是因为产品的存在的根本原因而存在的需求,它描述的是产品的动作,并能够形成一份完整的尽量避免二异性的功能描述. 事件驱动的用况是业务实践相应(活动和数据)的一部分,这些事件响应有产品来执行.用况成为了需求的锚,

寒假阅读笔记二

大型网站技术架构-阅读笔记二 模式:每一个模式描述了一个在我们周围不断发生的问题及该问题解决方案的核心.这样你就能一次又一次地使用该方案而不必做重复工作. 分层:将系统在横向维度上切分成几个部分,每个部分负责一部分相对比较单一的职责,然后通过上层对下层的依赖和调用组成一个完整的系统.分层时必须合理规划层次边界和接口,在开发过程中,严格遵循分层架构的约束,禁止跨层次的调用(应用层直接调用数据层)及你想调用(数据层调用服务层,或者服务层调用运用层). 分割:网站越大,功能越复杂,服务和数据处理的种类

构建之法--阅读笔记二

阅读笔记二—代码规范 代码的风格的原则就是:简明,易读,无二义性.我虽然是计算机系的学生,但是我以前却没有秉着这个原则来编写代码,现在阅读了构建之法后,我明白了如何让你的代码变得简明,更容易理解. 代码在编写的过程中注意: 用Tab键缩进 要注意行宽,最多限定100字符的行宽 在复杂的条件表达式中,用括号清楚地表达逻辑优先级 要注意断行与空白的{ }行,有明确的“{”和“}”来判断程序的结构 不要把过多的语句放在同一行上 对变量命名要有实际的意义 用下划线来分隔变量名字中的作用域标注和变量的语义

软件需求分析教程阅读笔记二

软件需求分析教程阅读笔记二 管理人员在要求开发一个系统时并不会理解进行需求分析的重要性,他们只知道能不能尽快开发出相应的系统来方便使用,但是如果不做好需求分析,最终开发出的系统也不会有人用. 客户的需求认识并不像软件开发人员这样,了解的比较清楚,客户通常并不懂得从系统的实际用户处得到信息的重要性,然而从产品的实际用户处收集需求有着不可替代的必要性,所以导致项目最终失败的两个原因,一个是缺乏用户参与,另一个是不完整的需求规格说明. 在进行需求分析时,只有系统的实际使用者才能清楚的描述他们要用此系统

《逻辑思维简易入门》(第2版) 阅读笔记二

<逻辑思维简易入门>(第2版) 阅读笔记二 本周阅读的是<逻辑思维简易入门>的第三章,也就是说,本书的第一部分就已经读完了. 第三章.信念的优点 信念和负信念是人们在接受一个事物时一种心理态度,延伸来说也就是对事物的认知态度.因为我们在研究 逻辑思维的时候,都有一个前提:“以正常情况以及说话者真诚”,所以有人如果对于一件事物不做回应,我们可以认为这是一种既不相信,也不怀疑的的态度. 信念的优缺点有很多,在书中主要介绍了下面几种: 1.准确性 好的信念实在准确的表达事实,同样真的信念

《掌握需求过程》阅读笔记二

了解了一些需求过程中的方法和问题,接下来就要网罗需求.网罗工作是由需求分析师来策划的,但是要完成这个工作需要分析师.用户和其他风险承担者相互合作,要明确每一个角色各自的职责.意识到的需求是指那些用户最先想到的需求,这通常表明用户希望改进的一些事情:无意识的需求是指用户没有言明的事情:未梦想过的需求是指那些一旦用户认识到它们可能时就会要求的事情.在网罗活动的过程中,必须揭示和捕获所有的需求,网罗活动具有多面性,它使用了一些来自启动阶段活动的输出结果:业务事件在网罗活动中占主导地位. 需求网罗的第一

《软件需求十步走》阅读笔记二

这一段时间阅读了<软件需求分析十步走>的第三四章,写一写书中一些个人感觉比较好的说法以及阅读感受. 首先是第三章<软件需求工程概论>. 需求工程和软件工程之间的关系界定没有质的变化,只是将需求工程从软件工程中剥离出来,将需求分析的分析工作和管理工作定义为需求工程.需求工程是面向全局的.系统顶层的.着眼未来的工程,是将客户业务作为内部研究对象,将软件工程全过程作为外部研究对象的工程.需求工程是圆心,软件工程是圆点. 需求工程的特征具有:全局性.主导性.主动性.过程性.规范性.可验证性

《探索需求-设计前的质量》阅读笔记二

软件是以人为中心的,所以说需求也是以人为中心的,而在使用一些工具的时候往往会忽略人的因素从而导致含混性.由于需求阶段所发问题越多,以后付出的成本就会越少,所以说含混性是非常重要的.整个需求与系统范围边界是有相似之处的,只要划定了什么是我们的需求,什么不是我们的需求,那就会很容易地,感觉这个也相当于是把复杂的问题简单化地过程,而基本上所有的问题都会是这样一个解决的模式,这也说明了事物之间的共性.而且,要在探索中发现乐趣会别有一番风味. 含混性是由于对事物的不同理解而产生了不同的解释,在对于含混性难