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

今天读了《构建之法》的第十一章和第十二章

第十一章,软件设计与实现主,要讲了以下几个问题:

1.从规格到实现

  主要要经历以下阶段:

  1.估计开发所需时间

  2.写一些原型代码,看看效果

  3.写设计文档

  4.按照文档写代码

  5.对照设计文档和代码指南进行复审

  6.创建或更新单元测试

  7.进行单元测试

  8.得到一个可以的测试版本

  9.修复测试人员发现的问题,请同事复审

  10.根据代码复审意见修改代码,签入代码

2.开发阶段的日常管理

  一个比较重要的问题是实现每日构建。

  书中宣称,经调查,成功的公司中有94%每天或至少每周完成构建。

  构建中可能遇到的问题是可能会把大部分时间花在没有价值的"同步/编译/验证/再同步"的循环中。

  一种解决方案是对于每一个步骤,如果团队成员的行为只是影响到个人,就让个人根据自己的情况处理。如果会影响到团队,就应该严格控制。比如要求每个人可以自由签出而要在每天的固定时间签入。

  书中讲的小强地狱也很有意思。设计一个阈值,使5%~30%进入小强地狱。入狱的人必须先使bug的数量低于阈值才能继续进行开发工作。

这一章有两句话使我印象深刻

1.当有一个能运行的系统时,即使只是一个简单的系统,(团队的)积极性也会上升

2.在理论上,理论和实践是一回事,而在实践上,理论和实践是两回事

第十二章,用户体验,讲了以下几个方面

用户体验的要素

1.用户的第一印象

  使用5H1W方法对设计做出判断

  Who:谁是你的目标用户?

  When:他们会在什么时间使用你的产品?

  Where:目标用户会在哪里和你的产品交互?

  What:你的产品是什么?用户的期待是什么?

  Why:用户为什么要使用你的产品?他们的动机是什么?在众多竞争产品中,用户为什么会选择你的产品?

  How:用户是如何与你的产品发生交互的?

2.从用户的角度考虑问题

  使用户操作尽可能简单的方便

3.软件服务始终要记住用户的选择

  软件应该越用越好用

4.要把短期此时转化为长期影响

  要使能让用户眼前一亮的功能易于被长期使用

5.不让用户犯简单的错误

  应该将有副作用的操作和常用操作分开

用户体验设计的步骤

概要设计:用户要解决的痛苦是什么,如何给用户提供价值?在此之前,可以做用户调研。

行为(交互)设计:通过一系列用户和软件系统的互动,帮助用户解决问题。

界面设计:通过读取用户的输入,以及创造和改进交行的媒介,帮助用户进行交互

评价标准

1.尽快提供可感触的反馈

2.系统界面符合用户的现实惯例

3.用户有自由控制权

4.一致化和标准化

5.适合各种类型的用户

6.帮助用户识别、诊断并修复错误

7.有必要的提示和帮助文档

时间: 2024-10-13 07:32:26

[读书报告]构建之法(五)的相关文章

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

今天读了<构建之法>的第八章. 第八章讲需求分析.需求分析有以下几个步骤: 1.获取和引导需求 找到软件的利益相关者,了解和挖掘他们对软件的需求,引导他们表达出对软件的需求. 2.分析和定义需求 对从各个方面获取的需求进行规整,定义需求的内涵,从各个角度将需求量化. 3.验证需求 通过分析报告.用户调查等形式向利益相关者验证团队对需求的认知. 4.在软件产品的生命周期中管理需求 在软件的声明周期中不断对需求进行重新审核并作出调整 需求分为以下几个方面: 1.对产品功能性的需求 要求产品必须实现

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

今天读了<构建之法>的第15章:稳定和发布阶段 Alpha:指集成了主要功能的第一个试用版本. Beat:功能基本完备,稳定性较Alpha版本高,用户可以在实际工作中小范围使用. ZBB:某天的版本把在之前记录的Bug都解决掉 RC:发布候选版本 RTM:最终发布版本 RTW:和RTM类似 会诊小组 软件团队的各个角色代表组成了会诊小组,处理每一个影响产品发布的问题. 决定对每一个Bug采取以下哪一种行动: 1.修复 2.设计本来如此 3.不修复 4.推迟 复杂项目的会诊 第一步:开发者提交惨

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

今天阅读了<构建之法>从67页到139页的部分,思考和体会如下. 1.第四章 这章讲的是两人合作.主要的点有代码规范.极限编程和结对编程,也讲到了与别人交流的一些技巧. 代码是给机器看的,也是给人看的,但我觉得代码更多是给人看的.因为我一直觉得不论何种科学或者技术发展到了什么程度,人都是最根本的.书中对代码规范方面讲的比较细致,形式上的包括我比较熟悉的缩进.括号.分行.命名.注释.大小写等问题和以前没考虑过的行宽.下划线等问题.我在平时写代码时,关于形式上的规范,首先考虑的是风格的一致性和代码

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

今天读了<构建之法>的第十四章,这章讲质量保障. 软件质量=程序质量+软件工程质量 程序的质量体现在软件外在功能的质量.衡量程序的质量,基本的判断可以用“是|否”来判定. 软件工程的质量与“快”和“省”相关,主要体现在以下方面: 1.软件开发过程的可见性 2.软件开发过程的风险控制 3.软件内部模块,项目中间阶段的交付质量,项目管理工具的因素 4.软件开发成本的控制 5.内部质量指标的完成情况 衡量软件工程质量的方法——CMMI(能力成熟度模型集成) 一级:初始级.在这一水平上,企业项目的目标

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

今天读了<构建之法>的第10章 这章讲典型用户和场景. 定义典型用户,需要全面考虑.软件系统中有受欢迎的用户,但也有不受欢迎的用户. 典型用户可以包括以下内容: 1.名字 2.年龄 3.收入 4.带便的用户在市场上的比例和重要性 5.使用这个软件的典型场景 6.使用本软件/服务的环境 7.生活/工作情况 8.知识能力层次 9.用户的动机.目的和困难 10.用户的偏好 需要注意:一个软件不是为所有人服务的 有个典型用户之后,还要决定每一个典型用户的目标——使用系统想要达到什么目的.对每一个目标,

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

今天我阅读了邹欣老师的<构建之法>从前言到正文的第66页,一些思考和体会如下: 1.前言 从前言可以看出邹欣老师对软件工程课的定位和对这本书作为教材的评价还是很高的.从前言可以知道这本书是邹欣老师结合了在一些高校的软件工程授课经验和自己的心得体验,写出的一本强调通过动手实践学习软件工程的教材. 2.给任课老师和助教的建议 这部分可以看书邹欣老师对同学们的要求很高,预期每个学生需要每周花费8个小时在这门课上.我个人而言,在个人项目和团队项目中每周花费的时间要超过8个小时.在团队项目中如果算上开会

构建之法五、六章读后感

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

构建之法五个问题

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

构建之法五项问题

大致通读了一遍构建之法,目前有如下几个问题: 1.我认为重复的工作会磨灭创新性,不停做同一件事,往往会忽视而难以发现新的东西.那么作为一个软件工程师,如何在团队工作中保留自己的创新能力呢? 2.在团队中有可能会有这样的情况:“为什么他的任务比我的少?”,“为什么他工资比我高?”.那么团队中这样的分配是否要找到一个平衡点?还是说告诉他“绝对公平本来就不存在”? 3.当发现之前设计会影响后面集成工作的进度,但是如果改弦更张会延误工期时要如何抉择?(进退两难,不知该怎样才好,因此在这里作为问题提出)