当前位置：首页 > news >正文

织梦网站防止注入网站建设与管理试题答案

news 2025/11/15 5:49:49

织梦网站防止注入,网站建设与管理试题答案,19寸网站做多大,微商城网站建设平台合同[内容来自移山之道]白话MSF方法论 2.1 果冻的预习果冻#xff1a;超总#xff0c;听说你要讲MSF#xff0c;我就先预习了一下#xff0c;但是MSF的名词太多了#xff0c;我真是头大#xff0c;能不能解释一下这两句#xff1a; “MSF的一个基础原理是学习所有的经验。…[内容来自移山之道]白话MSF方法论 2.1 果冻的预习果冻超总听说你要讲MSF我就先预习了一下但是MSF的名词太多了我真是头大能不能解释一下这两句 “MSF的一个基础原理是学习所有的经验。这一原理在MSF过程模型里的关键里程碑上得到了充分的应用在过程模型里愿意学习这一关键概念成功应用这一原理所需要的。愿意学习这一概念通过后里程碑回顾的经过检验的做法在项目里得到体现。在大型的和复杂的项目里Microsoft建议是利用客观的外部服务商来确保有一个无过错的环境并把学习最大化。” 阿超你从哪里找到的绕口令果冻MSDN中文官方网站呀。果然阿超在网上找到了这一段话如图2-1所示。图2-1 他和果冻一起读了两遍最后叹了一口气。阿超本来MSF挺简单明了的这样一搞反而很神秘晦涩了。二柱是不是有意搞得如此晦涩以延缓我等的进步阻碍我国软件大业的发展? 大栓我以前听过MSF的讲座觉得这玩意儿好像对大企业才有用处。而且MSF容易被人用来忽悠我相信一帮庸人在MSF的大旗下还是庸人只不过红旗飘飘可以忽悠客户。荔荔我在网上看到IT企业有三大忽悠大栓哥说的好像是第二种 ● 程序员用UML忽悠 ● 项目经理用Process忽悠 ● 老板用企业文化忽悠。隔壁的小飞探过头来。小飞果冻听到你还预习我差点晕倒。阿超你说应该怎么学习呢小飞好不容易出了学校我现在对“学”好像兴趣不大什么东西过耳就忘要用的时候现学就可以了。果冻好像流行歌曲你经常学习那些歌词你记得很牢嘛。小飞如果是载歌载舞那倒印象深刻。可惜呀MSF 好像不能载歌载舞能不能在KTV学MSFKTV、MSF都是3个单词的英语缩写应该是兼容的吧。阿超果冻你不用预习了我会搞一个“白话MSF”你一听就懂。为了让大家记忆深刻MSF 的每个基本原则都用一首流行歌曲来代表小飞你看怎么样小飞好啊如果你能带着阶级感情讲MSF我就能声情并茂地唱KTV。阿超好那就听好了…… MSF即Microsoft Solution Framework也就是微软推荐的做软件的方法。 MSF简史约摸在1994年微软在总结了自己产品团队的开发经验和教训以及微软咨询服务部门的业务经验后推出了Microsoft 解决方案框架Microsoft Solution FrameworkMSF。当时的MSF只是这些经验和教训的松散集合。在以后的几年中MSF进一步吸收了微软各个部门和微软的合作伙伴在实际项目中的经验。在2002年随着Visual Studio .Net的发布微软发布了一系列关于MSF 3.0的白皮书针对MSF 3.0的大规模培训也在中国开始举办。当时有一个“Architect 2000”的全国巡回演讲很多IT企业都参加了。 2006年MSF 4.0随着Visual Studio Team Foundation 2005发布。它增加了不少敏捷开发的内容并且明确描述了团队协作的典型流程和在新的团队协作软件包VSTS中的应用。 2008年MSF 4.2随着Visual Studio Team Foundation 2008发布, 它在文字和表达上有一些变化但实质精神和MSF 4.0是非常一致的。果冻哪一年出的2.0呢? 阿超我们需要关心么? 荔荔果冻是怕考试时会考到这一题吧。阿超我们可以不用管MSF演化的细节要记住所有模式都不是一成不变的关键是要掌握变化的原因。 2.2 MSF基本原则MSF有8个基本原则我把它们都翻译成中文并加上了我的理解。下面来分别讨论 1推动信息共享与沟通Foster open communications 2为共同的远景而工作Work toward a shared vision 3充分授权和信任Empower team members 4各司其职对项目共同负责Establish clear accountability and shared responsibility 5重视商业价值Focus on delivering business value 6保持敏捷预期变化Stay agile, expect change 7投资质量Invest in quality 8学习所有的经验Learn from all experiences 2.2.1 推动信息共享与沟通第一个原则用大白话来说就是所有信息都保留并公开讨论要包括所有涉及的角色决定要公开并告知所有人。当然对牵涉到技术机密、安全性等信息要采取必要的保护措施。二柱我们以前都是“老板让你知道你就会知道别多问。”看起来比较好控制吧阿超以前两三个哥们一起捣鼓软件大家都知根知底好像没有意识到“沟通”的重要性但是随着项目复杂度和团队规模的增加没有信息共享与沟通是万万不行的。二柱如果有一些事情我个人也没拿准是不是要通知某一方面的人员怎么办阿超在这种情况下宁可过分沟通。小飞这是不是很烦我得不断地告诉别人——我刚做了某事我刚做了某事好像网上有不少关于 “修改了文档的一个文字错误就要发邮件告知天下” 这样的事儿 …… 阿超对人不能被规则累死最好是让这些通知能随着事件的发生而自然地传递给关心这些事情的人。例如在TFS 中你可以设置提醒Alert让TFS自动通知你你所关心的事。另外在TFS中所有和项目有关的信息都会保存起来。例如所有工作项及其历史所有源代码的修改记录。 TFS用户经常问的一个问题是在TFS中我为什么不能删除工作项答案很简单MSF的第一原则所有的信息都保留并公开。TFS的记录就像银行账户里的资金流动记录是不可以删除的。大牛有人犯了一些比较愚蠢的错误比如一个很低级的BugTFS把它们都记录下来了从个人角度来看有人会说“我知道我做错了已经改正那最好把原来的记录删除了吧”这样做不是有利于打造和谐的团队么阿超和谐的“谐”是一个“言”和一个“皆”字说的就是大家都可以发言所有的事情都要记录。记录留下来可以做事后分析给后来的同事或者别的项目的同事学习。如果删除那也就违反了第8条原则“学习所有的经验”。如果历史是一笔糊涂账某些事件被删除了或者不能提哪来的和谐我们公司要建立“对事不对人”的文化好像有一句古话把人的错误比做日食…… 果冻“君子之过也如日月之食焉过也人皆见之更也人皆仰之。”还有“人谁无过过而能改善莫大焉。” 大牛我们以前关于项目的好多事都装在几个头头的肚子里最开放的也不过是把一些问题列在Excel文件或者是MS Project文件中但是也没有历史记录。阿超看不到所有的信息那么项目进度以及项目中存在的各种问题就不能及时让所有人知道这样MSF中其他的原则也就不能实行了。没有开放的信息也就谈不上“授权”或者“建立清晰的责任和共同的职责”以及“保持敏捷预测变化”。这也是为什么“推动信息共享与沟通”是第一个基本原则。 MSF团队模型和MSF过程模型也是建立在“信息共享与沟通”原则上的。小飞对于这一个原则我要推荐庾澄庆的 “请开窗”—— 如果相爱能轻易推测出结果谁还需要用真心来沟通 …… 2.2.2 为共同的远景而工作阿超“为共同的远景而工作”对于这句话大家是怎么理解的杂曰这就是所谓同心同德。兄弟同心其利断金。我们当然是同心的啦大家都是哥们都为了移山公司的兴旺才来的。阿超好但是这里面提到一个“共同的远景”这是什么玩意杂曰就是我们移山公司以后要发阿超发是肯定的大家注意这个“共同的远景”是指产品的远景。我们做一个产品不管是应用软件、行业软件还是通用软件要明确项目的目标是什么。 1这个目标必须是明确的没有二义性 2这个目标不是当前就能达到必须是通过努力才能达到的 3这个目标不是空泛的它应该对项目成员每天的工作都有指导作用。每天你来上班如果发现你做的事情对项目的远景没有帮助你应该跟老板提出来。荔荔我们有些项目好像没法订出来这样的目标耶或者老板也不清楚我们到底要干什么。阿超那么很显然这些项目的带头人没有及格这些项目最后没有达到预期的目标也就不奇怪了因为我们连预期的目标是什么都没有搞清楚。大牛能举例说明么? 阿超比如我们村里曾经有个体育新闻网站当时它的远景号称是—— “移山体育网提供即时、准确的体育新闻它提供论坛体育用品购物网络使得体育爱好者能共享一个公平、健康、安全的交流环境。” 刚开始做得不错我也经常光顾访问但是后来好像新闻和论坛的质量都下降了购物网页没有下文几次改版之后占据头条的经常是关于体育明星的小道消息和他们传说中的女友传说中的三围尺寸还有河曲村中上层人士争喝某种饮料的消息等。我一直想问谁是主编。大牛举起手我就是移山体育网的总编刚开始我每天做的事还是和我们最初的远景相吻合的人气也不错后来我们觉得什么能吸引眼球就上什么慢慢搞成了四不像名声也搞坏了。我们的内部远景已经改为—— “移山体育网要吸引眼球和广告直到找到买家为止。” 大栓大牛你们啥时候改的远景我怎么不知道大牛这个要问阿超。阿超这样的远景也不见得错但是不要忘了我们讲的是“共同的远景”即团队的领导人要让全体成员都同意项目的远景并为之奋斗。如果一部分人还为远景1.0而奋斗但是另一半人却在为远景2.0而努力那是要出乱子的。如果没有“共同的远景”即使团队发布了产品不同的成员对项目是否成功以后如何发展也会有不同的看法因为他们心里的远景参照物是不一样的。小飞对了后来河曲村中上层人士争喝的饮料咋样了大牛别提了他们以货抵广告费放在办公室的几箱饮料后来都被我爹扛回去喂猪了。阿超另外在项目到了关键的时刻我们再和大家统一思想向往远景已经晚了。大牛我想起以前国家足球队在某次世界杯的表现预选赛到一多半的时候足协的领导叫全体队员向国旗宣誓我就觉得很搞笑如果大家平时都目标一致搞这种宣誓只是形式如果大家平时没有这样的目标突然间宣誓并不会让队员们突然更爱国脚上功夫更好一些。阿亨另一个事例说明远景也和实际工作有密切关系。大松博文在中国女排搞“魔鬼训练”的时候如果大家的远景不是世界冠军干嘛费那么大的劲每天随便练练早点洗洗睡得了。阿超对如果我们移山公司的目标只是业余玩玩网站大家干嘛费劲学什么MSF 小飞远景是由领导决定还是自下而上形成的阿超一般是由“有远见的人”提出然后公开讨论在讨论的过程中可以消除误解凝聚共识。这是一个项目的关键是项目第一阶段要达到的主要目标。二柱这是不是俗话说的“统一思想”或者另一个俗话说的“洗脑”不是说国外不兴洗脑的么阿超可以这样看但是我们下面要说另一个基本原则需要你的大脑有原创精神。小飞洗脑归洗脑我要用这首歌曲表达洗脑后的心情——“嘻唰唰” 闪闪红星里面的记载变成此时对白嘻唰唰嘻唰唰嘻唰唰嘻唰唰 …… 2.2.3 充分授权和信任这一点的关键是“授权”这个词英语是Empower是什么意思呢授权Empower有两个意思一是给某人权力和权威Give authority to somebodyto give somebody power or authority二是给予某人更多自信和自尊Inspire somebody with confidenceto give somebody a sense of confidence or self-esteem。在一个高效的团队中所有的成员都应该能得到充分的授权他们有权力在自己的职权范围内按照他们自己的承诺完成任务同时他们也充分信任其他同事也能实现各自的承诺。类似地团队的顾客包括内部和外部的顾客也认为团队能兑现承诺并进行相应的规划。二柱这样做好像很危险哪阿超那应该怎么办采用“命令”的方式充分授权的管理方式是MSF的核心观念之一。MSF团队模型就是建立在以下两个原则上的 1平等协作——成员之间、团队之间是平等协作的关系 2充分授权给团队和成员。这就是为什么MSF团队模型是网状而不是层次结构。这样做有什么好处好处有两点 1被授权的人会承担起自己对项目的责任同时也期望同事们也同样对项目负责 2MSF提倡自下而上的计划每个人有充分的权力估计并决定自己的任务需要多长时间而不是上级交给的时间这意味着让真正做这件事的人按照自己的估计去完成任务。这样做的结果是啥是人人都会支持项目的计划和时间表因为这个时间表是每个人自下而上订出来的二柱听上去很美但是我作为一个组长给我的组员充分授权到头来发现事情都没做完咋办我只好不断地问你做到哪里了还差多少阿超这要靠工具的支持在VSTS系统中由于所有工作的进展都记录在案任何延迟都会被及时发现这样组长或其他层次的领导就不用把精力花在“询问”上而在“帮助解决”上在最关键的时候提供指导和帮助。领导在项目中的角色是“支持成员完成任务”而不是“控制成员迫使他们完成任务”。充分授权在MSF团队模型的另一个含义是信任鼓励团队成员成长每人都可以在某一时段、某一领域当领导。比如二柱是程序安全性的专家他就可以带领其他成员对项目进行安全性检查。如果测试工程师斯坦刚刚学习了如何做压力测试他可以带领其他测试人员对产品进行全面的压力测试。果冻能不能推而广之如果企业的各级领导秉持充分授权的信念让员工觉得被充分授权从而对工作产生热情变得积极进而能够充分发挥自我潜力企业整体即能够产生良性循环。斯坦在《致加西亚的信》中我觉得如果没有总统对罗文的授权和信任罗文也不可能完成这一艰巨的任务。比如如果总统信不过罗文派另一个“助手”和他一起走或者让罗文每天向领导汇报进展然后决定下一步行动这样的话罗文肯定就不能把信送到。大牛斯坦我觉得你的发言不同于网上成千上万条的《致加西亚的信》读后感提供了新的视角真不容易。这一原则还对企业传统招人、用人的方式有冲击我觉得这是MSF最难在中国公司实行的一部分“授权”、“放权”的管理理念和很多公司的企业文化不相符。二柱我早就说过MSF在中国不灵的啦。果冻我国古代也有充分授权和信任的例子看这一段—— “郢人垩慢其鼻端若蝇翼使匠石斫之。匠石运斤成风听而斫之尽垩而鼻不伤。郢人立不失容。宋元君闻之召匠石曰‘尝试为寡人为之。’匠石曰‘臣则尝能斫之虽然臣之质死久矣。’自夫子之死也吾无以为质矣吾无言之矣” 大家一致反映要听白话文的解释果冻解释完了以后大家七嘴八舌地议论这里面有授权和信任么大牛有啊郢人授权匠石他并没有管匠石的操作细节用斧头还是菜刀、匕首或者手术刀然后他“立不失容”才能让整个操作成功这里面体现了信任。阿超要注意这种信任是两方面的匠石也信任郢人会“立不失容”不会缩头缩脑因此他才能“运斤成风听而斫之”。如果有互相猜疑就会出乱子例如匠石心里琢磨“我估计他会害怕脑袋会往里缩二寸我要往里再砍两寸”而郢人心里想“我得再伸出去一些这样斧子才够得着”……如果没有双方互信的基础宋元君真的敢试匠石真的敢砍这个故事里的相互信任可以与“高山流水”中伯牙、子期的相互理解相媲美。另外充分授权之后领导是不是显得有点没用了呢小飞如果团队很厉害领导就会升上去喽阿超这个我也不知道如果我能证明我的人马很厉害甚至显得我都没有什么必要那我倒是可以做一些更无足轻重的事了…… 小飞比如说总裁什么的。阿超这倒提醒了我“充分授权和信任”对于领导者提出了什么样的要求领导者能不能对手下人说“这事就交给你了你办事我放心。” 就完了大牛、阿亨、大栓你们几个是当领导的都说说看阿亨我扯得远一点这教训是不能等到自己快不行了的时候才授权。阿超授权不等同于放任不管领导者在授权之后要为手下的成功提供各种必要的帮助——技术上的培训策略上的提醒以及各方面的信息和资源。大栓我们以前的项目中也放权了并且鼓励大家勇于发表意见结果大家倒是很踊跃发表意见每个人对其他任何人的做法都发表了意见大家最后吵得不亦乐乎但是没有实际的进展。阿超这就牵涉到下一个原则。小飞等等我选的歌曲是“信任”—— 没有信任爱情就失去了颜色 …… 2.2.4 各司其职对项目共同负责团队中的每个角色都有自己的职责见表2-1如果出了问题这个角色就要负责任。表2-1 MSF团队模型和关键质量目标关键质量目标 MSF小组角色出口条件按约束条件交付产品程序管理我们的项目是在时间/资源的条件内交付的么按产品规格说明交付产品开发我们是否按照功能说明完成了各项功能保证所有问题都得到处理测试我们发现了所有的问题而且都有处理方案吗产品部署和后续管理发布管理客户是否能快速方便地部署产品和进行后续管理让产品更好用用户体验产品是否适应用户的使用习惯易学易用让客户满意产品管理客户是否在总体上满意我们的项目比如说如果产品发布后客户在部署和管理上出现了很多问题那负责“产品部署和后续管理”的角色“发布管理”人员就要站出来对此负责。与此同时团队的各个角色合起来对整个项目最终的成功负责为什么因为每个角色在其职责范围内的失败都会导致整个项目的失败。而且各个角色的工作都是互相渗透、互相依赖的。这种互相依赖的方式也鼓励团队成员在自己本职之外为其他领域做贡献。例如测试人员可以帮助“用户体验”角色更好地设计用户界面因为如果用户界面很差再好的功能也不能发挥应有的作用。问如果我要做一件事情但是周围的人有不少不同意见短时间又不能完全说服他们怎么办答对此事负责任的角色要自己拿主意。阿超我今天在“顶球”网吧看到大牛他爹老崔在下棋围观者支招的不少有的说上马有的说拱卒有的说出车。大牛他爹一会儿招法就乱了眼看局势不灵了围观者一哄而散老崔后来也没法只好认输了。一个围棋国手在一次重要的对局后听到旁观者对棋局的进程有很多不同的看法他也没有过多争辩只是说“无责任的旁观者和有重大责任的当局者的看法自然是不一样的”。无责任的旁观者在支招后如果不灵他可以面不改色地继续支招甚至可以给另一位对局者支招不管最后谁输谁赢旁观者随时都能安心地离开回家吃饭。有重大责任的当局者在走了损招或败招之后他很可能就要认输下台丢掉比赛的奖金和头衔。大家还记得父子和驴的故事吧 “父子出门子骑驴人诽之父骑驴人亦诽之父子同驴人人诽之无奈遂父子抬驴。” 这些都说明一个什么问题如果我是责任人最终还要我自己拿主意。别人的意见都只是参考。我的责任是把事情做出来而不是讨好所有人让他们知道我按照他们的意见做了。在项目进展的过程中对于每一项任务每个人都要明确以下几点 ◆ Who谁负责 ◆ What做什么具体的执行方案什么叫做“做好了” ◆ When什么时候开始什么时候结束 ◆ Why为什么是这样安排和项目的远景是否吻合在什么情况下可以变更与“信息共享与沟通”原则相呼应这样的安排能让所有人都明确自己的职责同时有“大局观”——知道别人在做什么为什么以及整个项目的目标。小飞对这种连大牛他爹都可以从中受益的原则我觉得应该选一首家喻户晓的好歌“敢问路在何方”—— 你挑着担我牵着马踏平坎坷终成大道。 …… 各司其职圆满完成任务。 2.2.5 重视商业价值阿超我们都是搞技术的但同时我们也是一个商业实体我们的项目都应该是出于商业目的如果没有商业的需求再酷的技术也没有用商业项目需要重视市场和用户技术是处于第三位的。阿毛我们村的技术在这一带是有口碑的王屋河水流经之处人们都知道王屋村的年轻人是打奶.net的好手这是我们的品牌呀。阿超一个沉溺于技术而忽略商业价值的团队就像盲人骑烈马跑起来很拉风但最终不免人仰马翻。我要给大家介绍一首歌 “错误” 词郑愁予曲罗大佑—— 我嗒嗒的马蹄是个美丽的错误我不是归人是个过客 …… 为什么他是过客因为他光知道拉风不知道他的情人在楼上等他。回首望去很多“高科技”的公司就是过客。怎样衡量一个项目的成功并不是最酷的技术而是商业的成功。一个项目的商业价值只有在它被成功地发布并运行时才能体现出来所以MSF过程模式包括了开发和发布阶段。当年在学校的时候所有课程的项目都没有真正在实际环境中运行过现在的学生应该有条件这么做了吧小飞、荔荔、九条面面相觑阿超我听说你们在软件学院比赛中做了一两个很酷的项目得了奖解决了实际问题不是么难道没有真正运行起来荔荔项目演示完了我们就没有管了好像也没有人要求我们在实际环境中运行。我们把代码交给院里过不久代码就不全了也不能编译了后来也就不了了之。阿超心想糟了软件学院领导推荐的学生就这水平也许应该找那些在外兼职的学生…… 小飞我经常听说“激情”才是最重要的写软件的大拿们当初都是激情万丈代码如泉涌…… 阿超激情可以被激发出来也可以消失或者移情别恋而且激情因人而异。当项目遇到困难的时候当项目看不到尽头的时候有人就会问世间激情为何物能叫我每天加班一个团队项目如果没有经得起考验的商业价值没有明确的远景是很难坚持下去的。看看国外的观点他们搞了很多年的商业 “Don’t start a business if you can’t explain what pain it solves, for whom, and why your product will eliminate this pain, and how the customer will pay to solve this pain.” 如果你还没有能说清楚你的产品解决了什么问题为谁解决问题为什么你的产品会解决这些问题以及客户怎样付钱让你解决问题那你就不应该贸然创业2 类似地如果我们没有搞清楚我们的项目会解决什么问题为谁解决问题为什么它会解决问题以及怎样才能拿到客户的报酬那我们的项目还不能算是真正开始。斯坦那开源/共享软件是怎么一回事如果开源了商业价值如何体现阿超这个问题问得好我估计如果开放讨论以咱们的风格三天三夜也讲不完。但是回到具体问题让我们设想一下如果我们项目成功了有人以“开源”的名义来要我们的源程序我们答应么二柱凭什么阿超对呀凭什么在软件中凝聚了我们“无差别的人类劳动”——这就是软件这一商品的价值我们的口粮、公司的水电费都得用这一价值去交换我们如果重视商业价值就要有重视商业价值的做法。有一些原来 “闭源” 的项目后来变成开源的总是有各自的原因这些原因里面商业运作的因素也很明显。二柱但是正如你所说的我们都是搞技术的那怎样才能保证我们“重视商业价值” 阿超在MSF团队模型中“用户体验”这个角色代表了用户的利益保证产品能真正易于使用“产品管理”这个角色代表了客户的利益保证了我们的产品能为顾客提供商业价值。搞技术的要尊重这两个角色因为他们代表的是我们的衣食父母。二柱我们的激情会变但是大牛才是变得最快的他隔三岔五跑来说客户有点新想法我们要做一些小改动…… 大牛那怪不得我是咱们的“衣食父母”提出来的。阿超这就扯到下一个原则。 2.2.6 保持敏捷预期变化软件工程唯一不变的是变化。所以干脆别幻想客户的需求会在第一时刻很明确然后保持不会变。要注意我们是预期变化不是期望变化。除开外部原因团队内部也在变化我们对技术的掌握每天都在提高原来认为不可能的事可能变得容易。我们对客观世界和软件系统的了解每天都在深化原来觉得没问题的小细节忽然成了大问题。甚至原来一起打拼的同事忽然要离开……这些都要求我们团队保持敏捷的身段。大牛最近业界有人总结项目需求的生存期是18个月就是说如果一个项目的需求是18个月前确定的而产品还没有做出来那几乎就可以不做了因为需求肯定已经发生了很大变化。大牛大家有没有注意到微软的一些成功项目的各个版本之间也是间隔18~24个月。有些别的公司产品发布的间隔更短。小飞那为什么SQL Server要5年后才更新大牛清了清嗓子在座的哪位能分析一下阿超5年发布一个新的版本肯定是有不少问题。例如我们可以想象一下在2000年根据市场占有率的分析和预测某个产品说我们一定要支持Win2000和Win9x平台因此产品组做了不少技术攻关保证代码同时可以在两个平台上运行代码复杂度也因此上去了测试组也要花大力气 “保证所有问题都得到处理”两年过去了2002年大家终于实现了预期目标。然而产品并没有发布Windows XP/Windows 2003 Server正成为市场新宠大家开始讨论是否有必要保持Win2000/9x的一致性因为它增加了开发和测试的难度到了2004年这个产品还没有发布当时的决定看起来像一个笑话管理层开始讨论是否砍掉Win9x平台的测试预算。2005年底产品终于发布了这时谁还关心Win9x呢前几年的投资有回报么斯坦既然总会变那么似乎没有必要在每一步骤都保持高质量阿超你的潜台词是因为变了之后以前做的事就没有意义了。但是高质量在任何时候都是有益的低质量的工作会误导客户和团队也许会导致错误的变化。达到高质量是有代价的关键是要给客户提供及时、准确的信息根据客户的反馈进行修改。质量是重要的但是如果你的功能不能满足客户不断变化的需求注意是“不断变化的需求”那么再高的质量也没有用处。软件的质量在敏捷的开发流程中处于什么样的地位请看下一节。小飞等等我觉得最符合这一原则的歌曲是“不是我不明白”—— 不是我不明白这世界变化快 …… 反复多次直至声嘶力竭为止 2.2.7 投资质量对质量的重视引起对质量的投资引起对人、过程和工具的投资。大牛为什么叫投资干脆叫“质量第一”或者“全面质量管理”不就完了么阿超之所以叫“投资”是很有道理的。听我慢慢道来。 1投资要讲效率。软件开发过程大部分时间花在了解/设计/变更/再了解/再设计的过程中。我们要重视质量但并不是要不惜一切代价达到最高的质量标准听众中有人倒吸了一口凉气因为提高人/过程/工具的质量是要花成本的我们不是为提高质量而提高质量。我们要讲投资的效率。比如在做快速原形的过程中有些部分可以做得粗糙一点。 2投资要讲时机比如说对于某项技术的培训最好的做法是在即将需要的时候进行培训。太超前或滞后都不灵。 3投资是长期的。和投资股票/不动产一样真正的投资者看重的是长线的收益人的成长、团队的成熟都需要时间不可能短期内立竿见影。那些“短平快”的东西叫投机不叫投资。大牛对投机的事儿多了。比如有些公司听说国家要求软件企业必须达到CMM某个等级才能参与投标于是花了两个月的时间公司就奇迹般地提高到CMM 3级这是投机不是投资。阿毛另外什么叫软件的质量每当一个大型软件发布之后紧接着这个软件“服务包——Service Pack”就会出动。然后我经常看到报道说微软的Windows或者Office有几千个Bug没有解决就发布了。我们移山公司的质量尺度是什么呢不会像微软那样吧。大牛如果我们能做出Windows或者Office占领全世界80%到90%的个人电脑市场我个人很愿意像微软那样。不愿意的同志别来和我争这个利润。阿超我觉得和人类血型类似大家的“软件血型”也可以分4种 A型他们知道优秀的软件公司会发布有已知缺陷的软件 B型他们不相信这一点 O型他们不知道这一点因此嘴巴惊讶成O型 AB型他们对于自己开发的软件是A型对于别人开发的软件是B型。觉得自己是A型的举手……好大约一半人举手是A型好像大部分是工作了几年的同事。那么剩下的另一半人没举手就是B型了小飞我在犹豫。我可能算AB型。呵呵。阿毛我虽然觉得我可能是错的但是我目前确诊是B型。而且我们老师曾教导我们QA的使命就是不让一个Bug跑掉。阿超B型的人会发现搞软件开发是很痛苦的事。要说明的一点是所有软件公司都希望能够把缺陷都改正了才发布软件但是第一什么叫“缺陷”如果只是一些无关大局的问题用户可以绕过去的荔荔是不是英语叫Workaround?我们非得马上解决么第二什么叫“改正”如果改正的方案中又有“缺陷”怎么办我们做商用软件的人都在为此苦恼只有优秀的软件公司能找到一个平衡点及时发布能够解决用户问题的软件并且能及时修改软件中的问题——注意这两个“及时”并不一定是同一个时间。做非商用软件比如为了演示、交作业可以不用管这两个及时交了卷就万事大吉了。所以MSF没有提“质量第一”或者“全面质量管理”我希望移山公司不是质量第一而是解决用户的问题第一。我也不希望移山公司是“全面质量管理”因为“全面”之后会出现“大道废有仁义”的现象大家都讲“全面质量管理”往往意味着我们的质量管理没有抓到点子上。而且有些庸人往往会以“要达到高质量”为由阻碍正常的工作进程。大牛对现在社会上到处讲诚信、荣耻事实上说明这个社会是很有问题的。杂曰对呀……[在此略去大家对社会现象的讨论5000字] 小飞我要选一首歌“爱的代价”正如对爱的追求对高质量的追求也是有代价的。大家一齐哼哼那些为爱所付出的代价是永远都难忘的啊 …… 2.2.8 学习所有的经验阿超古今中外人们对经验的学习还是比较重视的我们经常听到“忘记过去的人注定会重复过去的错误”等类似的谚语。咱们中国的老祖宗也没少唠叨哪位能提供一些成语典故杂曰数典忘祖好了伤疤忘了痛一朝被蛇咬十年怕井绳…… 阿超停“一朝被蛇咬十年怕井绳”并不是“学习所有的经验”而恰恰是没有学习不敢分析蛇和井绳的区别。我们要重视经验但是不能错误地沿用过去的经验——寓言里讲过这样的故事驴子驼着两袋盐过河不小心跌在水中起来后觉得货物轻了不少暗喜后来它驮着两大包棉花过河也故伎重演但是效果却适得其反。在学习过去的经验的同时也要避免让过去的经验妨碍解决现在的问题。荔荔那为什么在软件开发中我们往往没有吸取前人的经验教训杂曰“没时间” “每一个项目都有自己的特色不宜生搬硬套” “项目的经验都在各人的脑子里” “项目结束后大家都散伙了没人组织总结或者写总结的人有偏心” “有时总结变成互相指责搞得不欢而散” …… 阿超这一原则有两个含义—— 1把经验总结出来 2分享经验。为什么要坚持总结和分享是为了—— 1让团队成员从别人的成果和失败的例子中学到东西 2帮助新项目重复以往成功的做法 3培育团队总结的习惯和“批评与自我批评”的文化。 MSF在每一个里程碑结束时都要做一个“里程碑回顾”这个回顾不必等到整个项目结束才做。这样做的好处是大家对最近的成败都记忆犹新能提供比较准确和全面的反馈如果发现了错误可以马上研究解决办法在下一个里程碑中通过实践来验证。另外一些好的做法可以及时得到总结和推广。在项目结束时MSF推荐请团队以外的专家来主持召开“事后诸葛亮”会这样的专家会比较系统地总结团队的成功经验和失败教训同时也客观评价团队的一些特性和团队的开发过程管理这样能促使团队成员以客观、向前看、解决问题的心态来参加“事后诸葛亮”会避免主观臆断或相互指责。二柱但是这样的做法是否能符合国情我们文明古国讲的是“以德报怨”有一些错误交了学费就算了不要拉下脸皮嘛。最后大家聚餐一下灌醉了领导和同事擦干嘴边的油渍又继续前进了。斯坦似乎国外有说法是什么“打你的左脸你要把右脸也凑上去……” 阿超我们似乎也扯得太远了。我只知道文明古国的孔子好像是反对“以德报怨”的吧。果冻孔子他老人家说过“以德报怨何以报德”他老人家主张“以德报德以直报怨”我的理解是别人做了错事特别是对你做了错事你要指出来并且争取得到改正。由此看来MSF还是比较符合儒家思想的。斯坦微软的同志们没想到用“儒家思想”这一招牌来给VSTS做广告否则早就卖火了。小飞我还没有想起什么儒家思想的歌曲姑且用这一首歌吧——“改变所有的错” 改变所有的错让我从头爱过改变所有的错再错也不回头改变所有的错就是我的承诺 …… 二柱哇总共有8项基本原则之多有没有搞错我们上学的时候只要求能背4项就可以了。果冻8项的确太多如果在工作中忘了几项怎么办阿超记住我们的目标是把软件做出来不是记住条文。当你记不住这些东西的时候想想怎么样才能把软件做出来实现我们的远景该干嘛就干嘛。 2.3 MSF团队模型MSF团队模型定义了小组同级成员的一些角色和职责如图2-2所示。 MSF团队模型认为任何技术项目都必须达到特定的关键质量目标才能够被认为是成功的项目。如果任何一个角色无法实现其目标都将危及整个项目。因此每个角色都被认为是同等重要的重要的决定都要共同做出。相关的目标和角色如表2-1所示。图2-2 团队模型说白了一个项目要达到的目标很多MSF团队模型让不同的角色去实现这些目标。在一个项目结束的时候每个角色都问自己这样的问题——我是否达到了我的质量目标最后比如测试团队角色测试要保证“我发现的所有问题都得到解决”那么测试团队就会做以下两件事 1发现产品的问题 2保证这些问题都得到处理。要注意的是保证这些问题都得到“处理”和得到“解决”是不一样的有些问题目前不能得到完美的解决但是可以有让用户满意的处理方案项目团队不能回避这些问题。问我们发现了问题但是我们目前的“处理”不能让用户满意怎么办答测试团队就要和别的角色如产品管理/程序管理/开发一起研究用户需求在可能的方案中选出一个比如 1按照目前的状态交付向用户说明如在某个操作系统/浏览器版本下某个功能不能正常工作 2推迟交付时间让团队有足够的时间来解决问题 3修改产品的约束条件如要求客户的操作系统/浏览器必须是某一个版本以上或者增加一个附加条件产品发布后半年会出新的插件解决问题。在讨论处理方案的时候每个角色从自己的质量目标出发对自己的质量目标负责。问那有冲突怎么办答那就吵呗众笑。各个角色的利益是有一定的冲突的MSF没有掩饰这一点。MSF团队模型的核心是成功的技术项目必须符合各种利益相关人stake holder完全不同且常常对立的质量观点。问这么说在团队中有矛盾是正常的了答对例如用户代表觉得新增加一个功能很酷因为新功能“让产品更好用”但是程序管理角色觉得会影响“按约束条件内交付产品”的目标测试会觉得“保证所有问题都得到处理”的目标受到威胁用大白话说就是“我没有时间测试你的新功能因此不能加这个功能”。这就要各方在整个项目的共同利益之下协商解决。问我原来认为测试人员说“我没有时间测试你的新功能因此不能加这个功能”是态度问题会被开发人员鄙视的。答这是对产品质量负责的态度你要代表你角色的利益如果你有充分的授权和信任你就要直言不讳。除了项目的各个角色之外MSF团队模型还可以推广到包括操作、业务和用户等外部因素。在对立中寻找共同利益在冲突中达到平衡。MSF团队模型推动了不同利益代表在追求共同利益过程中的融合。果冻“在对立中寻找共同利益在冲突中达到平衡”其实我们的孔夫子对此早看得门儿清—— 子曰君子和而不同小人同而不和。二柱儒家思想这么厉害干脆让孔子和他的三千弟子开发软件得了。那么后来也不会有C语言用《论语》就可以写操作系统了。果冻《论语》本来就是操作系统呀半部《论语》就可以治天下何况操作系统乎 2.4 MSF过程模型每个项目都要经过一个生命周期图2-3是MSF过程模型生命周期的一个简图。图2-3 过程模型 MSF过程模型是从传统的软件开发瀑布模型和螺旋模型发展而来的它把瀑布模型中基于里程碑的规划优势与螺旋模型中增量迭代的长处结合了起来。 MSF过程模型的基本元素是阶段和里程碑。所谓“阶段”就是在这一段时间里团队集中精力做某一类事情每个阶段的结束都代表了项目的进展和团队工作重心的变化。比如在“开发阶段”结束后团队就不再允许设计/实现新的功能除非有充分理由的“变更请求”。问我觉得这样也太理想化了一个10多人以上的团队不可能在某月某日同时完成某一阶段然后第二天进入下一阶段。答对各个阶段之间会有缓冲区团队中各个功能组的进度是各有区别的不必强求一律。团队用里程碑来检查工作是否结束和同步各个角色的进度以此来确定当前阶段的目标是否已经实现。此外里程碑标志着每个阶段的结束团队在此时应该引导成员转移工作的重心并鼓励队员以新的视角来看待下一阶段的目标。在上一个阶段产生的各种交付内容将成为下一阶段的起始点。 2.5 MSF敏捷开发模式在Visual Studio 2005中MSF演化为以下两个分支 ◆ MSF敏捷开发模式 ◆ MSF CMMI开发模式。我的感觉是MSF敏捷开发模式吸收了近几年来在软件业界流行的各种“敏捷”开发模式的优点认识到目前大部分软件是以网络应用相联系强调和用户更紧密地交流快速叠代避免不必要的过程。在继承MSF 3.0基本原则的基础上MSF敏捷开发模式和以前有什么不同有以下几点。 2.5.1 更强调与用户的交流项目的商业价值要由用户说了算那些“我觉得用户会喜欢”的东西要及早和用户交流。因为“我觉得”和“用户觉得”是两码事。小飞我说一句可能不太中听的话我觉得有时用户好像很嗯很不愿意交流很自负。有时又很傻很天真。和他们交流有时好像是对牛弹琴。二柱那就派大牛去弹好了。大牛有这么几种情况—— 1用户不懂他想要什么。有些用户只有一个模糊的需求他们说我们企业要上ERP你给我整出来。这种情况下我们得和用户一起做需求分析先把牛找出来2用户想要的和商业价值无关。比如有些用户说我想让每个按钮都是半透明的还要有三维效果就像一些网络聊天软件一样酷这些要求和他的企业管理项目的价值没有直接联系。也许这个用户代表是一头牛而不是用户代表我们要找管牛的人 3用户想要的我们还不懂。这种情况下我们是牛用户是在对我们弹琴 4大家心里想的不是牛也不想弄清牛想什么只要有钱就行。例如客户你能不能做3G 我们上3G干啥我们还搞不懂3G好像没有人真正需要3G。客户对我也不懂3G但是我手里有三百万预算要花掉。我们啊呀你干吗不早说那咱们就搞一个三百万的3G项目好了 2.5.2 质量——防患于未然防止缺陷的发生成为团队质量控制的首要任务所有的角色都要对防止缺陷的发生和确保缺陷被修复负责。有一些团队把开发和测试有意无意地对立起来好像二者是矛盾的。一个典型的例子是有时开发人员不想给测试人员足够的信息好像不想“帮”测试人员找到缺陷与此同时测试人员一旦找到缺陷会有一些得意的表示——“看你写的代码那么臭我又发现了N个Bug”。这种对立情绪也许在短期内能刺激成员的工作热情而从长远来看是有害的。很少有人会希望在这种充满对立情绪的环境中工作。微软公司内部做过统计在一个中大规模的团队中一个“缺陷”从发生到被改正中间经过了近20道工序平均总的时间开销是12小时。最好的事情是可能的缺陷在设计阶段之前就讨论过并且在代码中已经避免了因此在“缺陷跟踪系统”中并没有出现很多缺陷记录在案但是软件的质量仍然很高。 2.5.3 重视在实战条件下的质量这一点要求我们保持随时可以发布的高质量。如果用户说时间到了网站要上马。我们应该很快地交给用户一个可用的版本也许有不少功能没有加入但是版本中包括的功能都可用。这就要求我们必须保证项目的质量是“随时可用”。为了达到这一点我们要重视产品的安装和发布——产品要尽早能够达到随时安装、发布的标准。在我们以前的项目中安装和发布都是最后阶段才做这就导致几个问题 1开发过程中测试团队很难安装产品阻碍了测试团队的进展。很多情况下测试人员不得不从多个源头拷贝不同的文件到测试环境中才能开始测试。浪费了很多时间 2关于安装的缺陷得不到重视——用户拿到一个Beta版意见最大的就是安装不上或者好不容易装好了却卸载不了不得不重新安装系统。二柱好像这个VSTS早期的版本就有这个问题真是具有讽刺意义呀。鼓励团队在实战条件下使用产品就是“吃自己的狗食Dogfood”或者叫“自作自受”。大栓所谓“dogfood”也不难理解比如我们小学食堂的伙食都很差简直可以和“狗食”媲美。众人大笑但是食堂领导无动于衷因为食堂的领导和职工都是吃自己的小灶。如果食堂的领导实行“dogfood”制身体力行和食堂员工一起吃给学生做的大锅饭、大锅菜。我想这个问题应该很快就能得到解决。小飞我们要做的项目怎么才能dogfood 大栓那我们就自己注册成为用户和商户然后在系统上做一些交易吧。阿超这就要求我们的安装程序能够随时安装最新的版本同时对于我们服务器端的数据迁移提出了很实际的要求。果冻听说微软成功的秘密之一就是“狗食”看来我们也要掌握这一秘密武器了不过狗食有没有副作用众笑阿超好像是有的。狗食过分的话会让软件开发人员不自觉地把自己当成了典型用户造成的一个结果是开发出来的软件只适合技术人员使用一般的用户往往不得其门而入。比如好多功能都深藏不露如果你问一个技术人员技术人员往往略带不屑地告诉你把菜单中的“工具 | 选项”打开在某个“高级选项”下改某个参数即可。但是我们的客户谁有这种技术水平谁有胆在“工具 | 选项 | 高级”里乱按实战条件下质量的另一方面是进行经常性的迭代小的里程碑使用户能够及时看到产品并提供反馈。小飞这不就是快速原型法阿超这不完全等同于快速原型法用户看到的功能应该是能够马上使用的而不只是一个原型。 2.5.4 精简过程直奔主题我们一帮人吭哧吭哧干活是为了什么主题是什么是为了解决用户的问题。用户给项目投资了成千上万不是为了看到一堆过时的文档。同样在团队成员之间的交流要简明不必为了交接而搞出许多文档。另外一个重要的因素是如果团队在整个软件生命周期都使用团队协作服务器TFS那么很多活动、决定、文档都自然地记录在TFS上不必额外去为了文档而再写一些东西。大栓这几点还讲得我心有戚戚焉。 2.6 MSF CMMI开发模式阿超听说大牛以前参加过CMM的脱产培训还给一些同事现炒现卖过就叫大牛给大家讲讲CMMI。大牛我虽然参加过但是都是“俱往矣”的事情了。再说现在后面又多出来一个字母可能已经发生了质变。另外一些时髦的产品都是把这个“I”放在前面像iPod、iTune为什么CMM的I是在后面大伙拜托我们以前已经搞过CMM了像背政治课文一样。不要让我们吃二遍苦受二茬罪了吧。阿超那大牛能不能讲得深入浅出图文并茂大牛那我试试。阿超如果你讲得能让小飞这样的同志记下一些有意义的要点那就是成功了。大牛硬着头皮讲了一通CMMI讲座之后阿超看了看果冻和小飞的笔记。 2.6.1 果冻的笔记 CMMI是什么 CMMI是英文Capacity Maturity Model Integrated能力成熟度集成模型的简称。CMMI是CMM模型的最新版本——CMM已经被淘汰了果冻批注一叹。资料显示运用CMMI模型管理的项目不仅降低了项目的成本而且提高了项目的质量与按期完成率。因此美国在国防工程项目中全面地推广CMMI模型规定在国防工程项目的招标中达到CMMI一定等级的公司才有参加竞标的资格。该模型包括了连续模型和阶段模型这两种表示方法一个组织根据自己的过程改进要求可以自由选择合适的表示方法来使用。 CMMI有两种不同的实施方法其级别表示不同的内容。 1连续式主要是衡量一个企业的项目能力。企业在接受评估时可以选择自己希望评估的项目来进行评估。因为是企业自己挑选项目其评估通过的可能性就较大一点。但是它反映的内容也比较窄一点。它仅仅表示企业在该项目或类似项目的实施能力达到了某一等级。 2阶段性。它主要是衡量一个企业的成熟度亦即企业在项目实施上的综合实力。就是说处于某一阶段的企业做大部分项目都要到达某一要求。一般地讲一个企业要想在阶段性评估中得到三级其企业内部的大部分项目要达到三级小部分项目可以在二级但绝不能够只有一级。阶段性实施方法的难度要大一些。 CMMI虽然源于美国但在世界各地得到了广泛的推广与接受。CMMI在印度的应用甚至超过了美国。据SEI统计世界软件企业评估达到5级的共有25个印度占了其中的16个。果冻批注会考试这也是印度软件业得以迅速发展的一个原因。 CMMI目前已成为许多大型软件业者用于改善组织内部软件工程所采行的软件评估标准CMMI也陆续应用于系统工程及软件采购方面成为国际间通用的一种软件生产程序标准。有专家预测在未来的几年内CMMI将成为ISO9000之后的又一个国际标准。实施CMMI的意义很多人认为实施CMMI的意义在于项目工程走向世界可以在西方国家接到订单。实际上更为重要的意义则是CMMI的实施能够提高我国企业的管理水平降低企业的成本。事实表明企业实施CMMI技术的投入都会得到丰厚的回报。据SEI统计用于软件项目上的CMMI的投资其回报率在5:1到8:1之间。果冻批注何以算出来8:1由此可见为什么这么多的企业纷纷实施CMMI项目管理技术。 CMMI一级完成级。在完成级水平上企业对项目的目标与要做的努力很清晰项目的目标得以实现。但是由于任务的完成带有很大的偶然性企业无法保证在实施同类项目的时候仍然能够完成任务。企业在一级上的项目实施对实施人员有很大的依赖性。 CMMI二级管理级。在管理级水平上企业在项目实施上能够遵守既定的计划与流程有资源准备权责到人对相关的项目实施人员有相应的培训对整个流程有监测与控制并联合上级单位对项目与流程进行审查。企业在二级水平上体现了对项目的一系列管理程序。这一系列的管理手段排除了企业在一级时完成任务的随机性保证了企业的所有项目实施都会得到成功。 CMMI三级明确定义级。在定义级水平上企业不仅能够对项目的实施有一整套的管理措施并保障项目的完成而且企业能够根据自身的特殊情况以及自己的标准流程将这套管理体系与流程予以制度化。这样企业不仅能够在同类的项目上成功地实施CMMI也能在不同类的项目上成功地实施。 CMMI四级量化管理级。在量化管理级水平上企业的项目管理不仅形成了一种制度而且要实现数字化的管理。通过量化技术来实现流程的稳定性实现管理的精度降低项目实施在质量上的波动。 CMMI五级优化级。在优化级水平上企业的项目管理达到了最高的境界。企业不仅能够通过信息手段与数字化手段来实现对项目的管理而且能够充分利用信息资料对企业在项目实施的过程中可能出现的次品予以预防。能够主动地改善流程运用新技术实现流程的优化。由上述的5个级别我们可以看出每一个级别都是更高一级的基石。要上高层台阶必须首先踏上较低一层台阶。 MSF for CMMI能做什么能帮助团队加速达到CMMI第三级“明确”阶段。但是MSF的过程模板只实现了第三级所要求的21个过程的17个因此它并不能保证团队自动获得第三级的评估但是加以一定程度的管理规章和文档管理第三级应该不难实现。 2.6.2 小飞的笔记小飞我的感觉是CMMI 在所有的流程上都加了一个“提议”Proposed阶段通过“审核”或者决定“开始调查”处于“提议”阶段的工作项可以变为“激活”状态。如果调查的结果不是要开始着手工作那么工作项可以退回到“提议”状态。以缺陷类型Bug为例如图2-4所示图2-4 其他的工作项类型如问题Issue、需求Requirement、复审Review、风险Risk任务Task都是类似的流程这里就不一一列举了。阿超小飞你选了什么歌曲来表达你的心情小飞我选了歌曲——“不要挡在我的面前”希望MSF CMMI不要挡着我写软件—— 因为我已渐渐成熟必须坦然接受生活的考验因为我已渐渐成熟我的软件你们都将看见 …… 2.7 本章讨论荔荔我体会最深的是——“如果你问一个技术人员技术人员往往略带不屑地告诉你——把“工具 | 选项”打开在某个“高级选项”下改某个参数即可”这一段。移山公司的一些技术人员特别是开发人员甚至还带有一些轻蔑的眼神。参照这一新闻北京禁止售货员用轻蔑审视的眼光扫视顾客3我大胆地提一个建议——“移山公司禁止开发人员用轻蔑审视的眼光扫视测试人员” 大牛我同意而且要扩展到“禁止开发人员用轻蔑审视的眼光扫视非开发人员” 斯坦西方管理学大师戴明曾经说“Eliminate numerical goals, numerical quotas and management by objectives. Substitute (that with) leadership”意思就是说在团队中要消除以数字定义的目标、份额以及以类目标为基础的管理原则。我们要用领导能力取而代之。这和“数量化的管理”级别的要求有没有冲突二柱软件工程讲的净是一些奇妙玄幻的概念拗口的专业名词加上纷繁复杂的流程其实做软件完全没那么难主要靠的还是程序员自身的修养和完成工作的素质。小飞能否有一个打折扣的MSF让一个团队一下子接受MSF的“8项基本原则”似乎并非易事那么我们可以打折扣地贯彻MSF吗如果可以应该如何实施呢阿超这些原则都是相互依赖、相互促进的。如果只实施了50%的原则也许只有10%的作用。九条越是充分授权和信任很多人在团队中越不自觉结果写的代码都是敷衍了事大学里面的团队很多都是这样需要用什么激励机制来促进吗还是说只能依靠团队成员的个人自觉阿超那我们要问一下这个项目的商业价值是什么如果这个项目没有任何商业价值我想你也不好意思照搬商业软件的做法。但是也许这个项目对个人而言很有价值提高个人技术的价值那些有心锻炼自己的同学能够自我驱动值得你去“授权”和“信任”。 [1] 作者也作为讲师介绍了微软的开发方法。 2 Joel Spolsky, http://www.joelonsoftware.com/articles/Micro-ISV.html。 3 http://news.sina.com.cn/c/2006-11-30/202110650498s.shtml。

查看全文

http://www.zqtcl.cn/news/204253/