构建之法五项问题

  大致通读了一遍构建之法,目前有如下几个问题:

  1.我认为重复的工作会磨灭创新性,不停做同一件事,往往会忽视而难以发现新的东西。那么作为一个软件工程师,如何在团队工作中保留自己的创新能力呢?

  2.在团队中有可能会有这样的情况:“为什么他的任务比我的少?”,“为什么他工资比我高?”。那么团队中这样的分配是否要找到一个平衡点?还是说告诉他“绝对公平本来就不存在”?

  3.当发现之前设计会影响后面集成工作的进度,但是如果改弦更张会延误工期时要如何抉择?(进退两难,不知该怎样才好,因此在这里作为问题提出)

  4.前面的阐述感觉更侧重于强调需求分析和设计的重要性,而敏捷强调“速成”,似乎与软件工程有所冲突?

  5.对于用户来说,一个软件不光要实用,还要界面美观:现在有这样一个问题,客户给的资金、时间都有限,我们只能保证功能完备和界面美观二选其一,这样应该如何抉择呢?

<此篇随笔方便老师阅读,提交过后会规整到构建之法——现代软件工程 第二版 阅读笔记中并删除此帖>

时间: 2025-01-14 10:46:04

构建之法五项问题的相关文章

构建之法五、六章读后感

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

构建之法五个问题

1. P144页,章节7.2.8 提到学习所有的经验 提到总结经验和经验分享是在每次里程碑结束时进行,我很疑惑,每天进行站立会议时,是不是也可以进行经验总结和分享? 2. P137页,章节7.2.3提到成员授权和信任问题.我的问题是在实际开发中,当项目开始前所信任的有能力干活的人中途离开了或者在开发过程中这个人遇到技术难题,长时间未解决,其他成员对这个人产生能力质疑时,如何解决这个问题?由谁来主导这个问题的解决?项目负责人? 3. P121页,章节6.2提到了长期任务,这种任务比较艰难且对项目又

[读书报告]构建之法(五)

今天读了<构建之法>的第十一章和第十二章 第十一章,软件设计与实现主,要讲了以下几个问题: 1.从规格到实现 主要要经历以下阶段: 1.估计开发所需时间 2.写一些原型代码,看看效果 3.写设计文档 4.按照文档写代码 5.对照设计文档和代码指南进行复审 6.创建或更新单元测试 7.进行单元测试 8.得到一个可以的测试版本 9.修复测试人员发现的问题,请同事复审 10.根据代码复审意见修改代码,签入代码 2.开发阶段的日常管理 一个比较重要的问题是实现每日构建. 书中宣称,经调查,成功的公司中

构建之法学习回顾(二)

学习完构建之法五到八章之后,发现这本书更加贴近于当代,一般的软工教材为了追求更广更久的接受度,在内容上会趋于保守,而这本书不同,许多生硬的知识都得到了新的活力. 在第五章的学习中,主要讲了典型的软件团队模式和开发流程.以及我们也将讨论团队模式和开发效率之间的一些关系. 团队有一致的集体目标,团队要一起完成这个目标.一个团队的成员不一定要同时工作.团队成员有各自的分工,互相依赖合作,共同完成任务.只有我们当做一个团队一样进行工作和学习才能取得更大的成就. 第六章的学习中讲了敏捷流程及其原则,Bac

构建之法现代软件工程(第五次)

构建之法现代软件工程(第五次) 这周我阅读了<构建之法>第六第七章 敏捷开发的原则: (1)尽早并持续地交付有价值的软件以满足顾客的需求: (2)敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势: (3)经常发布可用的软件,发布间隔可以从几周到几个月,能短则短: (4)业务人员和开发人员在项目开发过程中应该每天共同工作: (5)以有进取心的人为项目核心,充分支持信任他们: (6)无论团队内外,面对面的交流始终是最有效的沟通方式: (7)可用的软件是衡量项目进展的主要指标: (8)敏捷

构建之法 第五次心得

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

实验五—读《构建之法》的心得体会

在段老师的极力推荐下,我们这学期有幸读到<构建之法>一本好书!其实你如果停下来认真读一读这本书,是非常有趣的.软件=程序+软件工程,这本书对于软件工程的方方面面:需求.设计.开发.测试.团队协作以及个人成长等都有所涉及且内容简洁.精炼可以很轻松的一口气读完,不过读完了,还要亲自动手实践,这样才能内化为你自己的知识.在我读到书中的第五章团队与流程,第12章用户体验,第16章创新,第17章职业道德时,有很大收获的,测试那张也很有趣. 在看到代码规范这章时懂得了一个良好的代码风格规范是一个软件开发人

第五次博客作业-读《构建之法》心得

读<构建之法>心得 首先,这是一本全景式图书,会让你更了解这个行业,能让毕业生在对行业从陌生到熟悉的过程中,较少地感到惊讶和出乎意料,这是一本与现实接轨的教材. 其次,这是一本最佳实践式的书,涵盖了科学.健康的软件工程开展中的每个方面,介绍了种种方法论,但不是高高在上.纲领性的方法论,而是方法论的最佳实践,确实可用,拿来就用. 第三,这本书让人有情怀,学生对“古老的”瀑布教材或“舶来的”敏捷书籍,难免会缺乏信心:这东西行吗?适用于现代吗?适用于中国吗?而如果到各大论坛.社区.或者询问“过来人”

第五次作业《读构建之法的心得》

<读构建之法的体会> <构建之法>这本书是软件大大神邹欣的作品之一,这本书体现邹欣老师的情怀,很简洁的讲述了软件设计的各个阶段,描述了一个微软软件大神对软件的理解.构建之法对我帮助挺大的,通过构建之法这本书使我对软件的构建很清晰的了解,让我对软件设计更加的清晰的认识,增加了我对软件的认识的兴趣,好了,现在来讲述讲述里面的内容,第一张讲概论:软件等于程序加文档,软件工程是什么,第二章讲 个人技术和流程 单元测试,效能分析工具,个人开发流程第三章讲软件工程师的成长 个人能力的衡量与发展