中国的网站做欧美风,东道设计公司介绍,邵阳整站优化,制作图片怎么做[这是 现代软件工程讲义 的一篇]
一个软件团队经历了计划/设计/开发等阶段, 达成代码完成 (Code Complete) 这一目标#xff0c;似乎后面的事情就水到渠成了. 其实不然, 软件生命周期的最后阶段往往是最考验团队的#xff0c;不但考验团队项目管理水平#xff0c;应变能力…[这是 现代软件工程讲义 的一篇]
一个软件团队经历了计划/设计/开发等阶段, 达成代码完成 (Code Complete) 这一目标似乎后面的事情就水到渠成了. 其实不然, 软件生命周期的最后阶段往往是最考验团队的不但考验团队项目管理水平应变能力也考验团队的血型。 原计划的软件发布时间快到了但是软件还是有这样那样的bug怎么办 优秀的软件团队会发布有已知缺陷的软件么? 我觉得和人类血型类似软件团队的“软件血型”也可以分4种 A型他们知道优秀的软件公司会发布有已知缺陷的软件 B型他们不相信这一点 O型他们不知道这一点因此嘴巴惊讶成O型 AB型他们对于自己开发的软件是A型对于别人开发的软件是B型。 B型的人会发现搞软件开发是很痛苦的事。要说明的一点是所有软件公司都希望能够把缺陷都改正了才发布软件但是第一什么叫“缺陷”如果只是一些无关大局的问题用户可以绕过去的我们非得马上解决么第二什么叫“改正”如果改正的方案中又有“缺陷”怎么办 做商用软件的人都在为此苦恼只有优秀的软件公司能找到一个平衡点及时发布能够解决用户问题的软件并且能及时修改软件中的问题——注意这两个“及时”并不一定是同一个时间。做“大作业”的软件比如为了演示、交作业可以不用管这两个及时交了卷就万事大吉了。
说到“质量”我们不提“全面质量管理”因为“全面”之后会出现“大道废有仁义”的现象大家都讲“全面质量管理”往往意味着我们的质量管理没有抓到点子上。而且有些庸人往往会以“高质量”为由阻碍正常的工作进程。而那些口口声声要求“高质量”的人士往往是出于下列情况 a) 缺乏对用户、行业、软件开发的洞察力对于“高质量”并没有具体的定义。 b) 没有具体的招数让软件达到所谓的“高质量”。 c) 害怕真实世界的反馈因此不发布软件能拖一天是一天。 可以看看这两个例子, 推断出这些团队的血型: STG 游戏的跳票 为了完美推迟了 7 天但是7天之后也没有发布… 英语学习软件 说了 “明早发布”但是明早一直没到
有些同学会马上举出世界有名的公司推出完美软件的例子, 例如苹果 永远的毁灭公爵等等…. 请问: iPhone 的第一个版本是完美的么? 它连 复制/粘贴 的功能都没有。 那么从软件的Code Complete 到最后发布, 我们要经历哪些步骤有哪些招数让我们能以比较大的共识比较小的痛苦走完这血腥的流程需要什么样血型血性的团队才能按时推出优秀软件 首先看看一些常用的名词
Alpha: 指集成了主要功能的第一个试用版本。有些小功能并没有实现。事实上很多软件的Alpha版本只是在内部使用。给外部用户使用的版本会起一个比较美妙的名字Technical Preview, 等等。
Beta: 功能基本完备稳定性较Alpha版本高用户可以在实际工作中小范围使用可以有Beta1、Beta2、Beta3……
ZBBZero Bug Build: 某天的版本要把在48 小时前记录的bug 都解决掉。
RCRelease Candidate: 发布候选版本RC1、RC2……直到RTM为止版本间隔时间较短。
RTMRelease To Manufacturer: 最终发布版本。如果某一个RC版本没有很大的问题那么这一RC就会成为最终的版本, 通常情况下软件公司会把最终的版本和相关的文件及其他资料交给另一个团队Manufacturer去包装、刻软盘、光盘。在AppStore/MarketPlace 的年代 , 我们有相应的 RTM Release To Market。
RTWRelease To Web: 和RTM类似对于网络应用来说我们无须依赖“Manufacturer/Market”来制造软件的光盘或者管理软件的发布渠道但是我们要依赖“Web”来发布我们的最终版本。如果软件产品是一个网站服务那软件系统一般会交给网站运营团队Operation Team去管理这样的发布也可以叫做RTORelease To Operation, 运营团队和研发团队一起决定什么时候系统上线Go Live。 会诊小组Triage Team
软件团队的各个角色代表 (pm/dev/test/UX 等) 组成会诊小组。处理每一个影响产品发布的问题。 打个比喻, 就像医院的门诊或急诊室 Triage Room, 如果一下蜂拥进来好多病人, 但是医院里人手和设备有限, 值班的医生护士要根据病人的情况安排。 另一个类似但比较紧急的场景是, 在战地医院里, 两次战斗的间隙, 医护人员冲上硝烟尚未散尽的战场搜救伤员, 有些做简单包扎即可, 有些要抬担架, 有些伤情太重的, 只好放下不管了。 大家的血型和勇气在这一次次的triage 会议中得到了展现。 下面的招数都是在会诊小组的领导下进行的。
对于每一个bug, 会诊小组要做出下面的决定:
- 修复- 设计本来如此 (as designed)- 不修复 (won‘t fix) - 推迟 (postpone) //如果我们的软件是真正解决用户问题的 是有价值的那它一定会有下一个版本。 招数: 设计变更Design Chang Request
经过Alpha / Beta阶段移山团队收到了不少用户的反馈有些是意料之中的有些是意料之外的。大家都看到原来的设计也有不少要改进的地方。有了用户反馈大家也能够取得比较一致的意见。另外大家也有了很多新想法。一时间众说纷纭很多人都嚷嚷着——DCRDCR!
重写或者是重构
小飞我们的某某模块真是太烂了我觉得必须重写而且现在又有了新的技术叫 “我佩服”WPF [或插入任一最近时髦的技术]它能做很酷的效果为什么不呢
二柱我们先要看看原来烂到什么程度现在是否能完成功能你所说的问题有多严重是功能不能实现或者界面有问题或者不能扩展例如不能支持更多用户
大栓另外是重构还是重写 重构——在尽量保持原有界面的基础上优化部分代码。 重写——重新实现原有功能同时要分清是全部重复原有功能还是偷偷加上许多新的功能Feature Sneak 小飞咱们找领导去超总看看我新写的功能。
阿超你不是在修理这个模块的 bug 么怎么开始写新的功能了
小飞对但是你是不是觉得我加的这个新功能很酷嗯……现在是有点慢但是如果数据库再做一些对应的修改比如增加一个缓冲之类的那就更好了。
阿超用户提到了这个功能么这和我们项目的远景有什么关系数据库修改后原来的用户数据要如何迁移到新的Schema下面
小飞嗯但是用户如果看到了就会喜欢的。
阿超很多程序员有这样的冲动在做修改的同时想到自己还能做更多的事有一个“东西”一直想做但是提出几次都没人重视那现在有机会就 “加进去” 算了。或者还有很多灵机一动的想法。打一个比喻——本来是要修厨房顶上一个有时漏水的水管结果修理工来了修好了水管同时灵机一动加了一个带淋浴的豪华卫生间。
小飞但这毕竟是新的想法我以为你会喜欢的。
阿超记住我们在项目的当前阶段是一个阻尼振荡的过程要收敛和稳定。等到下个版本开始的时候再进行发散的思考吧。如果你觉得目前的设计有问题我们要用DCR 来管理。
对所有提出来的问题都列表标题注明 Beta Feedback阿超给大家列出了DCR的要点
1如何提出DCR a. 在提交一个DCR的时候选用任务作为工作件类型并在标题中标明DCR。 b. 在DCR的描述文字中说明 i. 问题在哪里问题的影响 ii. 如果不做修改会有什么后果 iii. 几种修改的方案各种方案的优缺点以及成本。
2如何决定DCR的执行次序 a. 会诊所有DCR。 b. 按照影响、成本排序得到一个自上而下的名单根据现有资源按照名单执行。
另外, 适合在Beta分支实现的修改并不一定适用于主分支Main Branch, 我们要做好源代码管理。 招数: ZBB
团队要有把bug 都搞定的执行力。ZBB Zero Bug Build即这一版本的构建把所有已知的Bug都解决掉了。
Zero Bug Bounce通常在一个Zero Bug Build之后Bug数目会以惊人的速度反弹故称Bounce。系统要经历几次bounce像阻尼震荡一样Bug的数目在反弹了几次之后最后固定在或者无限逼近于0。
要注意必须要保证Bug的数量到0以防止一些问题拖而未决, 有些bug 长期拖而未决, 其实它们掩盖了深层次的设计问题, 要早把这些问题暴露出来, 而且划定一个时间期限, 一定要解决。
下图是一个60人的团队的“预想ZBB 进军图”。每个小组的Bug数量累加起来就是团队的Bug总量。下图中的黑线表明修复的Bug总量。 项目ZBB 此次构建中所有两天 (48 小时)以前报告的缺陷都已经处理。
移山公司的例子
第一个ZBB达到了同时产生了一个ZBB 的构建由于这个构建质量很好因此测试团队铆足了劲把各个部分都测试了一遍。同时也测试了复杂的场景进行了效能和压力测试。结果报告出来不少新问题。因此ZBB 之后的 Bounce 就跳得特别高。第二次ZBB 后由于各个模块质量的提高这一次的反弹就低很多随着每次ZBB 过程中质量的加强Bug 的数目会越来越少。同时也有几个功能被砍掉这些功能的Bug 也就不计入总数。下面ZBB 的趋势图显示了Bug 经过几次反弹逐渐到0的情况。 图15-9 bug ZBB趋势图横坐标是构建的版本号 招数: 砍掉功能
有一个模块看来不能实现预期的设计需求时间快到了怎么办
砍
芸芸可是我们花了很多心血才把设计做到目前的地步好像再努一把力就可以成功了。现在撤退我真是不忍心呀这不是浪费以前的投入么
果冻对呀我们可能只需要额外的三天不只要额外的三个通宵就可以了。再说我们可以以后接着修复任何新问题。
阿超这些话好像有理但是细一想都没道理。芸芸你听说过 “沉没成本Sunk Cost” 这个词没有没有的话应该上网查一查好好学学。果冻从你做事的历史来看如果类似的功能需要N个单位时间才能最终完成那么我们没有理由相信新功能会花少于N个单位时间。我们再回顾一下以前看过的功能/资源/时间的平衡图, 我们要不断保持这些因素的平衡: 招数: 修复bug 的门槛逐渐提高
在beta 期间, 修复bug 的门槛要逐渐提高, 昨天修复了同样类型的bug, 今天如果还找到了类似的问题, 团队未必要修复。 在RC 阶段, 只有影响巨大的bug 才能修复。 其它优先级较低的的bug 就只好在一边等着。 如果有严重的bug 要修复, 那么这些不严重的bug 也许有机会跟着一起修复。
在alpha 阶段, 如果开发人员拿到一个bug, 那他/她 就可以马上去修复, 只是在签入之后告诉大家做了什么样的修改。
在beta 阶段, 在新代码签入之前, 就要告诉会诊小组这个修改潜在的风险是什么, 如何应对等等。
在RC 阶段, 开发人员拿到 bug 进行修复工作之前, 就要和会诊小组沟通, 看看这个bug 是否值得花时间。 招数: 逐步冻结
随着程序功能的完善我们要让程序的各个方面有次序地“冻结”这样才能把稳定的软件交付给用户。一般来说程序的人机交互界面最先开始“冻结”不能再随意修改因为很多项目的文字信息要被本地化成多种语言当人机界面所用的文字和排版layout 固定后我们才能把这些文字交给负责本地化的部门。随着时间的推移一些功能也可以“冻结”这些功能都经过全面测试所有的Bug 都解决了功能进入稳定状态。在下一个版本前不要再碰和此功能相关的代码。如果有新的功能要写怎么办? 那就把源代码分支 (fork), 在新代码分支里开发下一个版本的功能。 [注: 大部分内容来自 移山之道]
