导航↓ 相册|收藏博客|加入友情链接|给博主留言
我要啦免费统计阅读使人充实,会谈使人敏捷,写作与笔记使人精确。史鉴使人明智;诗歌使人巧慧;数学使人精细;博物使人深沉;伦理之学使人庄重;逻辑与修辞使人善辩。-培根
黑猫大队长
2018-1-15 21:46

™™™
2017-10-18 10:12
™™™
2017-10-18 10:11
™™™
2017-10-18 9:52
Z浪迹天涯
2017-10-16 1:3
sunnyrl
2017-9-13 12:2
pangdan2007
2017-7-10 19:54
  • 创建:2007/2/23
  • 文章:973
  • 评论:5127
  • 访问:954841
  •  
1.收集和净化开发过程中各种度量数据。
 
收集包括工作量,规模,进度,范围,需求变更,代码行,缺陷泄漏,测试BUG分布,生产率,评审,返工等各项数据。
 
注意的是这些数据的收集要分散到整个项目监控过程中去,最好数据收集细化到周跟踪中,要得到第一手的数据项目中最好能够推广使用PSP Studio等相关工具,保证数据的真实性和准确性。
 
复盘一词应该来源于围棋,围棋一般下完棋后马上进行复盘,目的是双方都还可以清楚记得过程中得每个步骤和细节,而对于软件项目生命周期长得时候,靠复盘再去回忆是不可能完全记得清楚得,因此需要我们平时记录好这些度量数据,或者中间增加多个里程碑和检查点,及时得收集和分析数据。
 
2.总结项目经验教训
 
项目一个版本完成后,肯定既有做得好得地方也有做得不好得地方,项目本身要总结同时项目中得每个成员都应该进行自我总结。总结得目的一个是形成相关得规范和标准,避免后续版本犯同样得错误,另外一个就是形成相关得方法或模式。项目在进度紧张时候很难有足够得时间去分析和决策究竟选择那种方法或解决方案,这块每个项目必须形成相关得模式,以后遇到类似得场景就知道如何去分析和解决问题。
 
3.为后续版本估算提供足够得数据支持
 
一个项目中需求,设计,开发各阶段工作量比例究竟如何,项目得平均生产率大概在一个什么样得水平,项目在估算中评审,测试究竟需要留多少得时间?这些经验数据都需要我们从前续版本得复盘中来获取。刚开始做我们得估算很难做得准备,是因为我们没有历史经验数据可以参加,项目版本做多了,多注意复盘收集和分析数据,完全可以使我们得估算做到很准确。
 
复盘得实际值并不一定不加分析完全用于下一个版本得估算,实际数据本身可能也存在问题……
编辑 | 阅读全文(1294) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | CMMI集成项目管理-IPM

编辑 | 阅读全文(2801) | 回复(2),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | 十大管理技巧-(转载)

作者Blog:
 
你是否有过这样的经历:某一天,你雄心勃勃地准备把手底下的事清理干净,可到头来却一事无成?也许每个人都曾有过这样的经历,但在某些人身上表现得格外明显。时间管理可以帮助你把每一天、每一周甚至每个月的时间进行有效的合理安排。运用这些时间管理技巧帮你统筹时间,对于每个人来说都是非常重要的。
  组织技巧相对于其他技巧来说是最简单的一种。比如,所有的时间管理建议都包括在一些表格当中,在表格中你需要把你想要完成的任务填进去。对很多人来说,这是最简单和普通的了。当然,制表格和填表对一些人来说是有困难的。这是一个天份问题,与一个人的逻辑能力、空间想象力、创造力和抽象思维能力无关。时间管理需要一定的训练,如果你没有准备好接受专门训练的话,你将不能成为一个优秀的时间管理者。
  下面我把自己总结出来的十大时间管理方法介绍给您。值得注意的是,我没有称之为“最好的方法”。不过这些方法对我是有帮助的,希望对您也能有所帮助。
  1、每天清晨把一天要做的事都列出清单
  如果你不是按照办事顺序去做事情的话,那么你的时间管理也不会是有效率的。在每一天的早上或是前一天晚上,把一天要做的事情列一个清单出来。这个清单包括公务和私事两类内容,把它们记录在纸上、工作簿上、你的PDA或是其他什么上面。在一天的工作过程中,要经常地进行查阅。举个例子,在开会前十分钟的时候,看一眼你的事情记录,如果还有一封电子邮件要发的话,你完全可以利用这段空隙把这项任务完成。当你做完记录上面所有事的时候,最好要再检查一遍。如果你和我有同样的感觉,那么,在完成工作后通过检查每一个项目,你体会到一种满足感。
  2、把接下来要完成的工作也同样记录在你……
编辑 | 阅读全文(2326) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | 期待捷克的表现

 
今晚12:00捷克对美国,比分预测2:1或3:1。东欧球队技术都比较细腻,而且捷克对的中场应该算排得上好得,内德维德,波波斯基,罗西基都是厉害角色。
 
波波斯基从96年欧洲杯吊射一举成名,中间低迷了多年,但04年欧洲杯应该说又重新找回了感觉,他犀利右边路进攻可以和罗本左边路媲美。特别是可以传出很有威胁德好球,而做为杀手的巴罗什决定不会浪费任何一次机会。
 
杀手就是在需要你的一瞬间出现,正如古龙的小说,你根本没有看到刀出鞘,看到仅仅是刀上在流血。
 
年龄老化不是问题,大赛更多的是经验,相信捷克可以走的更远。
编辑 | 阅读全文(928) | 回复(0),人月&神话 发表于 2007-7-17 13:19
1、人之所以痛苦,在于追求错误的东西。 
2、与其说是别人让你痛苦,不如说自己的修养不够。 
3、如果你不给自己烦恼,别人也永远不可能给你烦恼。因为你自己的内心,你放不下。
4、好好的管教你自己,不要管别人。 
5、不宽恕众生,不原谅众生,是苦了你自己。 
6、别说别人可怜,自己更可怜,自己修行又如何?自己又懂得人生多少? 
7、福报不够的人,就会常常听到是非;福报够的人,从来就没听到过是非。 
8、你永远要感谢给你逆境的众生。
9、你永远要宽恕众生,不论他有多坏,甚至他伤害过你,你一定要放下,才能得到真正的快乐。
10、这个世界本来就是痛苦的,没有例外的。 
11、当你快乐时,你要想,这快乐不是永恒的。当你痛苦时你要想这痛苦也不是永恒的。
12、认识自己,降伏自己,改变自己,才能改变别人。
13、不要浪费你的生命,在你一定会后悔的地方上。
14、你什么时候放下,什么时候就没有烦恼。
15、每一种创伤,都是一种成熟。
16、当你知道迷惑时,并不可怜, 当你不知道迷惑时,才是最可怜的。
17、狂妄的人有救,自卑的人没有救。
18、你不要一直不满人家,你应该一直检讨自己才对。不满人家,是苦了你自己。
19、你要包容那些意见跟你不同的人,这样子日子比较好过。你要是一直想改变他,那样子你会很痛苦。要学学怎样忍受他才是。你要学学怎样包容他才是。
20、承认自己的伟大,就是认同自己的愚疑。
21、一个人如果不能从内心去原谅别人,那他就永远不会心安理得。
22、心中装满着自己的看法与想法的人,永远听不见别人的心声。
23、毁灭人只要一句话,培植一个人却要千句话,请你多口下留情。
24、当你劝告别人时,若不顾及别人的自尊心,那么再好的言语都没有用的。
25、不要在你的智慧中夹杂着傲慢。不要使你的谦虚心缺乏智慧……
编辑 | 阅读全文(1203) | 回复(1),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | 编程规则-转载

规则一 这世界上唯一的真理就是不要盲目相信真理
从某种意义看,原则、规矩这类东西就是用来打破的。所谓原则,就是对历史上某种经验的总结。如果我们踏入的河流和前人非常接近,我们可以参考前人的经验。我们是主动地拿来,而不是被动的遵守。
 
规则二 未蕴而变,自欺也;知律而变,智者之道也
这句话谈的是学词,必须先了解格律,然后才谈得上变化,否则就是自欺欺人了。在编程上,也是一样。在有资格打破一条原则前,首先要了解这条原则。先了解事物的规律,然后才是变化和灵活的应用。不要打倒自己不了解的东西。
 
规则三 寻找结构和成本的平衡点。当结构不能容纳变化时,重构代码到新的平衡点
开闭原则要求:一个软件实体应该对扩展开放,对修改关闭。即软件的结构要达到:允许在不修改软件的前提下扩展软件功能。
但好结构是要花成本的。程序员总是在折衷,寻找结构和成本的平衡点。我们会放一些余量,让结构能承受一定的变化。
 
规则四 要针对接口编程,不要针对应用编程
前面谈过了。我们总希望通过工作得到一些收获,积累一些经验。只有将代码分解成尽可能独立的模块,然后针对接口编程,才能保护我们的成果,让我们有所积累。
 
规则五 最少知识原则:模块对外界的了解应当尽可能少
前面也谈过了。所谓“圣人之治”,经常是“虚其心,实其腹;弱其志,强其骨,常使民无知无欲”。让被管理的对象尽可能得弱,对象间的关系尽可能得简单,可以降低管理的成本。
在面向对象编程中“组合优于继承”,就是因为继承将基类的实现细节暴露给子类,两者的耦合性太强了。另外,继承的实现是静态的,而组合可以更灵活地实现。
 
规则六 尊重习惯
在任何领域编程,应该尽量了解这个领域的习惯,尽量符合这些习惯。这样,别人可以更容易地理解和使用我们……
编辑 | 阅读全文(1396) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | RUP过程误解清单

您认为起始阶段 = 需求;细化阶段 = 设计;构造阶段 = 实现。
 
您认为细化阶段的目的是为了完整细致地定义模型,并在构造阶段将它翻译成代码。
 
您认为在细化阶段只需创建原型(事实上,应该在细化阶段针对高风险的架构元素编程实现具有产品级质量的核心子系统)。
 
您试图在开始设计或实现之前定义绝大部分的需求,或者在开始实现之前完成绝大部分的设计。
 
您认为一个合适的迭代长度只能以月为单位来计算,而不是周。
 
您认为编程之前的 UML 绘图和设计活动阶段是为了完整地、精确地定义极其详尽的设计与模型,认为编程只是简单、机械地把模型翻译成代码。
 
您企图从头至尾详细地计划一个项目,然后把工作分配到每一个迭代;竭尽全力地企图预测所有的迭代以及在每一个迭代中发生的情况。
 
一个组织在进入细化阶段之前,就要求获得可信的计划和估算。
 
一个组织认为实施 RUP 就意味着从事尽可能多的活动或创建大量的文档,把 RUP 当作一个有许多步骤需要遵循的规范过程来运用。
编辑 | 阅读全文(1750) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | 软件开发过程法则

Software is a knowledge medium.
软件是知识的载体
 
The "product" is the knowledge contained in the software.
我们真正创造的产品不是软件本身,而是蕴涵在软件中的知识和学问。
 
The activity of developing software is the activity of acquiring specific types of knowledge and translating that knowledge into a specific language form known as "code."
软件开发的过程就是我们去获取特定类型知识的过程。而我们所知的编码活动就是将我们获取的知识转化为系统中的一个功能或表单。
 
求知的五重境界
0OI: I have the answer. Developing a system is simply a matter of transcribing what I already know, into the appropriate programming instructions
我知道答案,开发系统简单的仅仅是将我所知道的东西翻译为适当的程序指令。
 
1OI: I have the question, and I either know how to get the answer to it (I have 0OI about the activity of answer acquisition) or I do not know how to get the answer (I have 1OI about answer acquisiti……
编辑 | 阅读全文(1624) | 回复(0),人月&神话 发表于 2007-7-17 13:19
阿昌开了家医疗器械代理公司,聘用了四名刚刚毕业的大学生,小赵,小钱,小孙和小李,做为营销员,四个狗的月薪相差无几,都在每月一千二至一一千五之间,并按销售业绩12%的比例提成,做为奖金收入。两个月后,四名营销员的业绩如下:
 
小赵:他老实听话,但稍一放松管理就偷懒,工作不指派到头上决计不会主动动手,叫苦的时间远比干活的时间更多。他工作时间最长,但业绩为零,两个多月一无建树,没有完 
成一个订单。
 
小钱:为狗聪明机灵,表面上对老板唯唯诺诺,其实自己另有鬼主意,特别会干面子活,是得到老板夸奖最多的员工。自从他进入公司以来,在第一个月和第二个分别完成两笔订单,共售出产品6台。
  
小孙:勤奋耐劳,善于死缠乱打,他除了跑业务还经常被老板指派一些其它方面的工作,目前他是唯一任劳任怨的员工。虽然他来的时间不长,却也在第二个月勉强完成一笔订单,售出产品1台。
  
小李:为狗心思灵活,眼观六路,耳听八方,有小钱的聪明,但不象小赵那样懒,只是工作时不象小孙那样憨,目前小邓正在全力推动与一家大客户的商谈,对方有意向一次性订购产品60台。
  
三个月的试用期马上就要结束了,因为阿昌的公司较小,他决定四个狗中只留下一个,予以重用。
  
那么你认为老板阿昌会留下谁?理由是什么?阿昌决定员工去留的标准又是什么?
  
□小赵? □小钱? □小孙? □小李?
 
说明:如果你选择留下的狗是没有业绩和能力的小赵的话,这本书你就不需要看了,你已经完成了职场进化的全部程序,可以纵横职场予取予求,无往而不胜了。
 
反之,如果你选择留下的狗不是小赵,而是其它三个狗的话,那么你的职场政治智慧还停留在蠢驴、野牛、刺猬和老鼠的阶段,你会在职场上遭遇到许多不快的事情,甚至会影响到……
编辑 | 阅读全文(1569) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | 项目概念思维导图

编辑 | 阅读全文(1592) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | 微软软件开发过程模型

微软产品周期模型是微软28年实际开发经验的精髓,微软的所有产品,从最初的产品策划到编程,Beta版发行,正式版本的发布,下一个版本的开发,都遵循该周期模型。微软产品周期模型是整个微软开发流程的核心和基础。微软开发团队模型是以“三驾马车”架构为核心的矩阵模型,合理的人员配置、合理的团队架构保证了团队成员各司其职,充分沟通,开发出符合用户需求的高质量产品。
 
软件开发过程模型比较
微软是世界上最大的软件公司,但微软并没有通过CMM认证,不使用RUP,也不使用XP。微软有自己的软件开发过程PCM。他们之间有什么区别?有什么共同点?微软是否有从CMM、TSP、PSP中取长补短?而中国软件企业又如何从这些林林总总的开发过程模型中选取适合自己的方法?CMM真的对中国软件企业有帮助么?来听听微软资深项目经理的现身说法吧。
  
源代码管理与每日编译

源代码控制(Source Control,又称源代码管理、版本控制、软件配置管理等)和每日编译(Daily Build,又称Nightly Build、持续集成等)是软件开发过程中最重要的方法,也是实施其他各种流程的必须基础(例如变更管理、缺陷管理、自动测试等)。
  
上兵伐谋:微软产品规划方法
  
好的起点是成功的一半,只有正确的制定产品开发策略,才能使产品在推向市场后被用户接受,在交付客户后令客户满意。在这个专题中,您将了解到微软如何策划新软件的特性、进行市场调研、了解和分析客户需求、收集用户反馈等。
  
发布零缺陷软件:缺陷管理
  
Bug管理是软件开发中非常重要的一个环节。在大型的商业软件开发中,没有Bug管理是不可想象的。Bug管理在微软的软件开发流程中同样起到举足轻重的作用,无论是Windows、Office这样大型的软件,还是内部使用的各种各样……
编辑 | 阅读全文(1714) | 回复(0),人月&神话 发表于 2007-7-17 13:19
注:该文未经允许不要随便转载
 
虽写明该文不允许转载,但仍然被CSDN随意转载,在此将该文删除。
需要学习敏捷开发的推荐看该文作者翻译的《敏捷软件开发-原则模式与实践》一书。
 
 
 
 
编辑 | 阅读全文(1315) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | Martin Fowler的XP主题演讲

可能Sidney先生把我说得太好了,我有点不敢当了。如果大家感到失望的话,请原谅我。我今天想把主要的精力放在探讨敏捷式开发方面。
  
软件开发行业目前同时存在两种情况,它既是一个非常成功的又是具有很多问题的行业。一方面软件已变成我们在日常生活中不可缺少的部分。有些可能不是非常明显,直至有问题出现的时候才发现。一个非常有名的例子就是几年前有家航空公司的计算机系统有一天不能正常工作,结果造成了很大的混乱和巨大的经济损失。我并不是要仔细分析问题的所在,只是想指出软件在各个行业中扮演的角色越来越重要,互联网的使用已极大地改变了人们的生活、工作方式。在西方,普通客户购买东西的过程中,经常把决策的过程使用在互联网上。所有这些软件所带来的影响,对于三、四十年前的人来说几乎是不可想象的。
  
尽管有成功的方面,但软件开发过程中还是经常会遇到一些问题,很多企业在软件方面花了大量的金钱和经历,但并不是很清楚软件到底能给他们带来什么。一些调查发现世界上很多软件项目其实都失败了,也许这是因为在软件开发过程中,很难定义成功与失败这两个不同的概念。我们在软件界就是注重怎么预见软件开发的不可预知性,我们想象出了各种各样的技术、工具以及流程使得软件开发的过程变得越来越可以控制、预测。这种方法有一个很大的问题就是无法有效评估软件开发过程的有效性。在很多其他的产业界,可以用简单的办法评价过程的进程及有效性,但是对于软件开发过程,很难用一种标准来衡量它的进度和有效性。一个结果就是很难有效判断两种有效的方法哪种更好,使得软件技术、工具以及流程方面的很多讨论都被这种现象所左右。软件开发的过程中有各种问题,并不是新提出的概念。在六十年代末期的时候北约一个软件开发室提出了软件危机的概念,因此他们提出了非常有纪律性的方法即软件工程学,试图从电子工程学、技术工程学提炼出一些东西来用于软件工程学,他们……
编辑 | 阅读全文(1014) | 回复(0),人月&神话 发表于 2007-7-17 13:19
(共 973 条) 1 2 ... 18 19 20 21 22 ... 64 65 翻页至

仅列出标题