《构建之法》第五次随笔

MSF,即微软解决方案框架,也就是微软推荐的软件开发方法,大约在1993年,微软在总结了自己产品团队的开发经验和教训,以及微软咨询服务部门的业务经验后推出的。MSF基本的原则:1.推动信息共享与沟通;2.为共同的远景而工作;3.充分授权和信任;4.各司其职,对项目共同负责;5.交付增量的价值;6.保持敏捷,预期和适应变化;7.投资质量;8.学习所有的经验;9.与顾客合作。

第一个原则,就是所有信息都保留并公开,讨论要包括所有设计的角色,决定要公开并告知所有人,MSF团队模型和MSF过程模型也是建立在“信息共享与沟通”原则上的。授权是关键,有两个意思:一是给某人权力和权威;二是给予某人更多自信与自尊,所有的成员在一个高效的团队中都应该得到充分的授权,同时他们也充分信任其他同事能实现各自的承诺。团队中的每个角色都有自己的职责,如果出了问题,这个角色就要负责任。软件工程,唯一不变的是变化,我们是预期变化,不是期望变化。除开外部原因,团队内部也在变化,我们对技术的掌握每天都在提高,原来认为不可能的事可能变得容易。我们对客观世界和软件系统的了解每天都在深化,原来觉得没问题的小细节忽然成了大问题。对质量的重视,引发对质量的投资,引发对人?过程和工具的投资。我们要学习所有的经验,MSF在每一个里程碑结束时都要做一个”里程碑回顾“,这个惠顾不必等到整个项目结束才做。这样做的好处是大家对最近的成败都记忆犹新,能提供比较准确和全面的反馈,如果发现了错误可以马上研究解决方法。MSF强调产品团队与顾客的交流与合作,因为”我觉得“和”用户觉得“是两码事。

编程可以是一门理论,也可以是一门工程,还可以是一门手艺,我们要学好编程。

时间: 2024-10-27 21:40:51

《构建之法》第五次随笔的相关文章

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

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

构建之法第五章学习

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

构建之法 第五次心得

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

读《构建之法》的第一次随笔

在收到纸质书籍到手之前,我简单的看了一些多看阅读上的试读章节.第一章开始便以程序猿们编程遇到的各种问题引出了软件工程的重要性.在一个工程的进展过程中,各种的不确定性因素会以多种不同的方式阻碍项目的正常运转,例如,软件的质量提升,特殊需求的引入,文档.流程和工具的正确性等都会蚕食项目的工期和质量.如果不加以控制和规范化,越是大型的项目,导致失败潜在的危机越是巨大. 根据多年的工作经验学习以及前人留下的案例,作者邹欣老师也总结了程序(算法.数据结构)是基本功,但在算法和数据之上,软件工程决定了软件的

构建之法第五篇阅读笔记

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

构建之法第六次随笔

我这个礼拜阅读了构建之法第12,13章. 其中,第十二章讲的是用户体验,我们要考虑用户体验的不同角度,用户的第一印象就很重要,用户第一次使用软件,就很大程度上决定了用户对软件的评价.软件服务始终都要记住用户的选择,从用户的角度考虑,要有一颗同理心.理解用户的处境,心理,动机的能力有着一颗为用户着想的同理心,是好的产品设计的出发点.也不要让用户犯简单的错误,所以要不停改进,高明的设计能让用户不需要花费额外的注意力,也不需要经验与专业知识即可凭借直觉完成正确的操作. 对于一个软件的用户界面,有一些原

《构建之法》第二次随笔

阅读了<构建之法>第一章中软件工程的概论,我学习到了"软件=程序+软件工程"这个黄金公式,并且对软件工程充满了兴趣和信心.但是,一个好的软件工程开发团队需要首先确保团队里的每个成员是合格的工程师,为此我们得先普及一些基本概念和技术,即单元测试.回归测试和效能分析工具.书的第二章讲述了个人技术和流程,给我们着重介绍了PSP(个人软件开发流程). 绝大部分软件都是由多人合作完成的,大家的工作相互有依赖关系.怎么才算一个好的单元测试?单元测试应该准确.快速地保证基本模块的正确性:

构建之法——第五篇

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

构建之法第五六章读后感

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

重新回答构建之法的五个问题

问题一:这本书一直在强调合作,我不是很理解这个合作的具体含义,我认为的编程是项目经理安排任务然后每个人只要完成自己的任务就好.所谓的合作我认为的不外乎就是沟通.各种接口对接等等.可能会有会议讨论等等.但是合作是不是就是沟通确实不是很清楚. 答:沟通是信息传递的重要方式,只有通过沟通,信息才能在部门与部门之间.员工与员工之间得以传播.工作的开展在很大程度上来讲,就是通过从上到下的层层沟通采得以进行的.沟通是一个双向的行为,沟通双方一个要善于表达,一个要善于倾听,通过双方沟通.倾听.反馈再沟通.倾听