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

2007-7-17 13:19 | 读微软研发制胜策略(2)

保持进度
如果没有未雨绸缪,那只有坐以待毙。在你期望保持进度之前,能否总结出影响进度的各方面因素并制定相应的应对措施。只有切实的做好了项目的风险管理,进度才能够有效的保障。
 
能否每天都问自己,有什么事情我今天能做,而且会帮助项目在未来几个月内进行顺利的。项目在进度紧张情况下不会给你任何的知识和技能的学习时间,所以这种预见性就显得额外重要。
 
以我的经验,最有效的除错方式是对程序进行Debug,通过设定断点来检查变量的值的正确性。这往往比我们凭空猜测要有效的多。因此一个优秀的程序员也应该是一个Debug高手。高手就在于你花一天找不出问题的,高手可能只需要1个小时甚至更短的时间。
 
解决问题前请先确定真正的问题在哪里?问题的根源是什么,然后再考虑如何用简单有效的方法去改正它。人口开头想要的东西往往并不是他们真正需要的,所以处理这种要求时候先挖掘出用户的潜在想法和需求。
 
项目主管要勇于说不,不要为了讨好别人而伤害双方的工作进程,你永远要根据自己的目标,作适当的决策。
 
项目进度的有效控制方法是进行挣值法分析成本和进度的偏差。增量迭代和多个检查点和里程碑的设置可以有效的做到这点。
 
项目主管可以排到以周为单位的项目进度计划,模块的负责人应该细排出以天为单位的工作计划,通过采用每日构建,每天需要完成的功能清单及时的发现到进度的偏差。对于突发事件,疑难问题解决引起的偏差往往通过赶工可以很好解决外;对于进度估算不准,如生产率数据太乐观引起的偏差则需要及时对整个项目计划进行调整,重新分配资源。
 
通过实用和易用极大的满足用户需求是软件产品终极目标,与次不相关的有趣,花哨的功能,或开发人员把自己个性强加到系统中,都将是系统的败笔。
 
……
编辑 | 阅读全文(1136) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | 读微软研发制胜策略(1)

微软的项目经理
除了项目管理相关工作外,强调了最重要的一点是训练项目成员,而微软项目经理一般由资深的程序设计人员担任。所以微软项目管理应该是更偏技术型的,同时也驳斥了项目经理不需要懂技术的一些说法。训练项目成员除了提升项目成员的开发技能外,更重要的还是整个团队精神的塑造。微软项目经理偶尔也会写些程序,但那是次要的工作。
 
专注再专注
软件开发的真理是任何不能改善产品的工作,都是在浪费时间和偏离方向。团队出问题的一个原因往往是项目成员花太多时间做他们不该做的事情,如参加毫无价值的会议,回复邮件,准备冗余的文档。

项目经理的任务是消除项目成员工作中的一切障碍。让项目成员全力专注在真正重要的工作上-改善产品。

如果把太多杂事分配出去的目的仅仅是为了减轻项目经理个人负担,实际上你做的是伤害团队生产力的事情。别人能够做这件事情,并不代表必须做。

有太多的项目经理在不该授权的时候授权,让项目成员为了与产品无关的事情疲于奔命,让外界的杂事干扰项目正常的进度,以致于项目进度不断延误。

Email的目的就是要让程序设计师的思维不被打断,所以不必要有事情没事情就去瞧瞧它。我只能告诫新进人员回复Email要分批去做,而不是实时去做。
 
清晰详细的项目目标
不要把设定目标这件事情理解的太玄,设定目标只不过是把你要完成的事用清晰的语言描述出来,让每个人都有明确的概念。明确目标之所以带来效率,是让你可以格外的专注与目标相关的事情,做好时间管理,分清轻重缓急。

开发阶段的进度,特别像敏捷团队工作目标会细化到每天,通过每日构建来检查每天完成的工作情况,及时的纠正偏离。长期加班和饱受压力的小组,多半是工作漫无目标的后果。

程序设计上对性能,质量,安全,可维护性等的优先级考虑顺序必须要和项目的目标保持一致。因此项目质量目标往往和项目……
编辑 | 阅读全文(1155) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | 不要把工具和技术等同

我们在自己写简历或看别人写简历的时候最多看到的就是把工具和技术混淆起来,而且过多的去强调工具使用的熟练程度而忽略了技术能力这个本质问题的描述。工具仅仅是提高我们工作效率的一个辅助工具,对工具的学习周期远远短于对技术知识的学习,你掌握了某种工具的使用并不能代表你具备了某种解决,分析和系统思维的能力。而一个具备了较高技术知识和能力的人往往仅仅需要几天时间就可以掌握一种工具的使用,工具可以提高我们的工作效率,但当你把重点放在工具的使用上时候说明还处于学习的低级层次上面。
 
1.能熟练使用PowerDesigner,ERWin等工具,并不代表你具备了完善的数据库分析和建模能力,对于一个复杂系统的数据库建模可能也无从下手,也不知道对实体对象的分析,ER图,从概念模型到物理模型的转换。只有真正理解了关系模型,实体关系图,遵循从逻辑数据库设计到物理数据库设计的方法学,才能够真正具备设计大型应用系统数据库的能力。
 
2.掌握了UML语言,能够熟练使用ROSE,Together等工具,并不代表你具备了完整的面向对象分析和设计的能力。当拿到一个大型系统时候仍然觉得无从下手,不知道面向对象分析和设计应该遵循的步骤和具体的方法论,也没有面向对象基础知识的积累,感到举步维艰。或许这个时候应该结合一门语句学习面向对象的封装继承和多态等基本特征,学习对象识别基本方法;或许应该仔细阅读了RUP的方法论,遵循用例驱动,从分析模型入手,寻求相关的实体类,边界类和控制类,再朝详细的设计模型转换,其中可能还会用到系统工程,设计模式,业务建模等多方面的知识和积累。
 
3.最近我也经常在使用思维导图MindManager这个工具,也感觉到拿到这个工具有时候却很难画出很好的东西。因为工具仅仅是展现你的思维,但你是否具备了完整的思维和思考能力却往往需要学习,……
编辑 | 阅读全文(925) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | 还差最后一场了

前面从8强开始的比赛全部预测对了,这次真的是太准确了。
冠军开打8强就想好了,意大利夺冠,四星级的意大利诞生了。
 
1.12年前巴乔的泪水,12年后一轮回,这回看到了是齐达内的泪水。足球不能太完美,必须要有些遗憾,这个遗憾留给最伟大的中场-齐达内。
 
2.90年德国在意大利家门口夺冠,今年意大利在德国夺冠,也算换个人情
 
3.后防双方不相上下,中前场法国占优,守门员布冯占绝对优势。在这种关键比赛中防护就更重要了。
编辑 | 阅读全文(882) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | 神奇的天路

 
清晨我站在青青的牧场
看到神鹰披着那霞光
像一片祥云飞过蓝天
为藏家儿女带来吉祥
那是一条神奇的天路哎…
把人间的温暖送到边疆
从此山不再高路不再漫长
各族儿女欢聚一堂
 
黄昏我站在高高的山冈
看那铁路修到我家乡
一条条巨龙翻山越岭
为雪域高原送来安康
那是一条神奇的天路哎…
带我们走进人间天堂
青稞酒酥油茶会更加香甜
幸福的歌声传遍四方
幸福的歌声传遍四方
编辑 | 阅读全文(849) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | IT项目管理书架

还有很多好书,没有看过的就不列出来了。
 
软件开发项目管理-栾跃(很多微软的实践,内容全面)
软件项目管理实践-施平安翻译(印度InfoSys公司最佳实践)
软件项目管理:一个统一的框架(实施RUP下项目管理必看)
敏捷项目管理(实施敏捷项目管理参考书)
CMMI——过程集成与产品改进指南
PMBOK2004版
 
人月神话(没有银弹)
最后期限(汤普金斯的经验总结)
人件集(方法,工具,技术,过程,团队,模型)
软件工艺
 
你的灯亮着吗- 温伯格-理解清楚真正的问题
程序开发心理学-温伯格
系统化思维导论-温伯格
 
死亡之旅-周浩宇翻译
与熊共舞-软件项目风险管理
软件工程实践导论—有关方法、设计、实现、管理之三十六计
道法自然-理解面向对象的技术体系
凌波微步:软件开发警戒案例集
微软项目-求生法则
微软项目-制胜策略
Rational 统一过程导论
敏捷软件开发
微软软件开发解决方案框架MSF-(有很多电子版)
 
以下书籍电驴可以直接搜索要英文版-这些可以留做参考需要时候再详细翻看
The Art of Project Management
Wiley - Project Management Methodologies (2006)
MS Press - Agile Project Management with SCRUM
Metrics and Models in Software Quality Engineering, 2ed [Addison Wesley'2002]

Software Measures And The Cmm
Ieee Software Quality Metrics Methodology
CRC.……
编辑 | 阅读全文(1128) | 回复(0),人月&神话 发表于 2007-7-17 13:19
这些连接是去年年初的收集了,一直没有更新,仅做个人收藏。
 
需求分析
编写高质量的软件需求说明书: http://www.sawin.cn/doc/SA/REQ/blueski75.htm
用例建模指南: http://www.sawin.cn/doc/SA/REQ/blueski17.htm
需求分析概述 http://www.sawin.cn/doc/SA/REQ/reqgeneral.htm
五步描述软件需求管理过程 http://www.sawin.cn/doc/SA/REQ/5step.htm
如何进行软件需求分析 http://www.sawin.cn/doc/SA/REQ/howtoreq.htm
RequistPro需求管理步骤 http://www.sawin.cn/doc/SA/REQ/blueski06.htm
以上链接全部来自 http://www.sawin.cn/general/column.asp 系统分析之窗(里面有很多好资源不一一列出)
 
相关网站列表
http://blog.joycode.com/ 博客堂 主要是微软专家的帖子,内容较新
http://www.cnblogs.com/ 博客园
编辑 | 阅读全文(1378) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | CMM实施案例

该文比较老,具体的原出处已经找不到了。
 
案例1:
V公司和竞争对手相比,在技术上并不占有优势,于是V公司采用了“快速响应”的策略。无论是面对瞬息的市场,还是多变的用户需求。V公司总能够抢先于竞争对手推出产品,为此受到了市场的肯定。但是V公司在实施CMM的时候,却错误地选择了“瀑布式”的开发模型,加上相对复杂的实施流程,如果研发体系严格按照要求去做,那么对市场的响应速度必然大大降低,企业的核心竞争力受到威胁。但是如果H公司坚定“快速响应”的策略,现有CMM的实施就无法有效进行。V企业走入两难的境地。
 
V企业实施CMM并没有错,错的是他们在实施CMM的时候并没有考虑到企业的核心竞争力和总体战略,采用了错误的生命周期模型和相对复杂的实施流程,最后导致了这样的结果。

对公司的战略影响是一个方面,另外一个方面是,CMM的实施涉及到机构的重组,如果我们不能在组织架构,薪酬待遇,绩效考核等方面辅助以适当的政策的话,CMM的实施不可能顺利进行。
 
案例2:
W公司为了推行CMM,组建了独立的QA部门。尽管在W公司的内部宣传材料上对QA的作用进行了大肆的宣传,认为其对于CMM的推行和项目管理都具有重要作用,但是实际上QA人员的资历都相对较浅,对开发过程,技术和工具都缺乏必要的了解。只能够照搬一些条文来要求开发人员,开发人员对此并不认账,认为QA人员是没事找事。另外,QA这个岗位在薪酬和升迁方面毫不吸引人。

为了避免QA部门成为新手和项目组淘汰人员的集中地,QA部门经理设法推行项目经理锻炼制度,让项目经理到QA部门锻炼一段时间,然后继续担任项目经理或者升迁。但是因为此项制度没有得到有效的支持,项目经理在QA部门工作一段时间以后竟然没有开发部门愿意接收,就更谈不上升迁了。QA部门在W公司的威望江河日下。

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

2007-7-17 13:19 | 太久没关注技术了

太久没有关注微软技术方面的网站了,今天专门去看了下,了解了下现在技术的一些发展情况。其中最关注的还是Windows Communication Foundation,值得期待。
 
Spy++推出了DotNet下可以使用的版本ManagedSpy,这个工具对做性能分析,单元测试和异常的Debug是非常有用的,可以试下具体的使用:
 
关于提高UI显示性能问题
1.为了在第一时间把UI界面显示给用户,可以使用后台线程来载入可以推迟显示的内容
2.对于一个UI有多个TabPage的时候,最好对初次不显示的Tab都采用惰性载入的方法,在TabChange时候再载入
3.DotNet2.0引入BeginUpdate和EndUpdate方法,可以对集合类控件ListView,TreeView等批量更新
4.数据绑定控件的优化,对于联动的组合框控件一定要注意防止多次Load的情况。
 
智能客户端后的王道
微软推迟了XAML的发布,XAML将随Vista和WinFX一起在Visual Studio的下一个版本Orcas中发布了,XAML可以真正实现BS和CS的完美统一。
 
This article is an introduction to developing a Windows Vista application using the Windows Presentation Foundation ……
编辑 | 阅读全文(1259) | 回复(0),人月&神话 发表于 2007-7-17 13:19
参考文档:《Software Measures And The CMM
 
先写一些处理,有些还没有理解清楚。感觉CMMI四级对度量的要求更加高,如果说度量数据收集和度量分析2,3级都谈的比较多的话。四级更强调度量控制这个概念,强调要采用相关的统计方法和分析技术来对度量数据进行分析控制,并即使的采取措施纠正偏差。
 
1.进度方面
实际进度的计划进度的偏差情况,Gantt图和Pert图。
返工时间占项目总时间的比例情况
项目能够容忍的最大的处理变更的时间
三级强调了偏差的范围,四级强调严格的上下限控制(控制图)
 
2.工作量
实际工作量和计划工作量的偏差
三级增加对好质量成本和坏质量成本相关工作量的度量(COGQ,COPQ)
对项目返工,评审,测试和处理变更工作量的分别度量
 
3.成本
计划成本和实际成本的偏差
三级强调了成本和进度的性能指示器(挣值分析)
三级强调了偏差的范围,四级强调严格的上下限控制(控制图)
五级强调了会提供可选择的过程改进和缺陷预防策略供选择,而这个是在对项目的成本和效益做了比较和平衡后得出的。
 
4.软件质量保证
不合格项的信息
SQA具体的审核信息
 
5.Review的结果
Review的活动项的状态
 
6.问题报告
问题项的具体状态(打开,处理,关闭)
问题的原因的分析,对问题的分类的统计
问题的平均处理周期度量
 
7.同行评审和缺陷
同行评审的缺陷的打开和关闭的情况统计
缺陷密度
缺陷移除率和缺陷泄漏率
同行评审的效率,评审速率的度量
同行评审的覆盖率
四级强调对缺陷分类后的帕累托分析
四级强调对同行评审的关键特征项的控制图分析

8.需求的度量
需求的规模的……
编辑 | 阅读全文(1682) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | 提问的智慧和原则

D.H.Grand的提问的智慧很多论坛都作为了置顶贴,在网上也可以搜索到相关的文章。这里仅根据自己的理解把读书的一些心得写下,同时结合《你的灯亮着吗》这本书把提问的一些原则再简单的总结下:
 
原则一:明白自己遇到的真正问题
1.明天自己遇到的真正的问题,或说是明白根源性的问题
2.不要认为的去翻译问题,不要把自己解决了一半遇到的问题作为需要提问的问题
3.清楚的明白自己遇到问题的特定条件和特定场景
 
原则二:提问前先自己尝试解决问题
1.在手册或FAQ里面找寻答案
2.向你身边熟练的有经验的专家打听或请教
3.上网自己搜索答案
 
如果你没有自我知识库或资料库的积累,可能你解决问题的效率已经比别人慢了半拍。这里我们强调的是在你解决了一个复杂的问题时候必须进行总结,将解决问题的步骤,方法,经验,技术等内容进行分解,入到自己的知识库里面。这是后续问题解决的宝贵财富,而很多人可能并不在意这种知识和技能的积累,解决问题的技能也就很难谈得上不断提高。
 
黑客或高手需要你提出的问题是值得他们深思的问题,这样帮你解决问题后自我技能可以提高而且可以得到极大的满足。如果你老提出太简单或鸡毛蒜皮的问题,那仅仅是在耗费高手宝贵的时间,所以需要认识到的是不仅浪费自己时间可耻,浪费他人时间同样可耻。
 
提出问题时候,可以给出一些自己思考的解决方法或方案,请求高手印证。这是一种对问题积极思考的态度,我们反对的是拿到问题后自己不加思索就发问的人,这样对自我能力基本无任何锻炼。
 
你的问题90%以上别人也同样遇到过,所以上网搜索问题的答案是一种常用的方法。这里要注意的两个问题是:1是要对问题中的关键字有敏锐的分析和洞察力,选择准确和适当的关键字会让你找到答案的过程事半功倍;2是……
编辑 | 阅读全文(2056) | 回复(0),人月&神话 发表于 2007-7-17 13:19
原则三:根据用户行为和有关用户的资料确定产品特牲及其优先顺序
 
对于一个开发项目而言,如何确定最终产品中应包含什么特性通常是比较困难的一件事。为此微软采用了一个称之为“基于行为制定计划”的方式来进行特性选择与优先级安排。
 
基于行为制定计划法从对用户行为,诸如写信或做预算,做系统研究开始。然后,根据某一特性在支持重要的或者是经常的用户行为上的程序对其进行评价。这样做的优点是对特性取舍更具理性:讨论对顾客想要做什么加以更好的安排,对某个给定特性是否方便了特定任务的更集中的辩论,可读性更强的说明,以及在市场营销、用户教育和产品开发中更好地同步。
 
特性选择和优先级安排中的基于行为制定计划
基于行为制定计划法中的关键点在于按用户行为、产品特性以及行为和特性之间的内部联系来分析产品。程序经理和产品计划者把产品试图支持的用户任务或方案分成大约20个“行为”,然后他们努力把行为(以及任何子行为)映射入微软的现行特性和竞争对手产品的特性中去。他们也把行为映射到不同的顾客形象或不同的市场部分中去。
 
当说明产品的新版本时,基于行为制定计划法帮助程序经理和开发员集中他们的精力与创造力。象Excel之类的项目,争取在每个新版本中加入的主要行为不超过四个。绝大多数特性直接映射入这些行为之中。该做法使项目可以按特性对用户的价值来进行分级。通过分级,促使程序经理和开发人员都行动起来,使他们的特性支持尽可能多的行为。这种良性竞争对于用户有益,同时也利于提高生产率。
 
(这个原则充分的体现了微软产品完全由用户驱动,软件创造客户价值)
 
由于基于行为制定计划法是从整个产品的观点着眼,因此有助于在不同职能上工作的项目成员理解产品做什么,以及其他产品的相应特性如何可能支持那些需要或不需要其他应用软……
编辑 | 阅读全文(1084) | 回复(0),人月&神话 发表于 2007-7-17 13:19
原则一:将大项目分成若干里程碑式的重要阶段,各阶段之间有缓冲时间,但不进行单独的产品维护。
 
微软通常采用“同步-稳定产品开发法”。典型项目的生命周期包括三个阶段:
计划阶段:完成功能的说明和进度表的最后制定
开发阶段:写出完整的的源代码
稳定化阶段:完成产品,使之能够批量生产(Roll Out)
这三个大阶段以及阶段间内在的循环方法与传统的“瀑布”(Water Fall)式开发方式很不相同,后者是由需求、详尽设计、模块化的代码设计与测试、集成测试以及系统测试组成的。而微软的三个阶段更像是风险驱动的、渐进的“螺旋”式的生命周期模型。
 
在开发和稳定化阶段的所有时间中,一个项目通常会将2/3的时间用于开发,1/3的时间用于稳定化。这种里程碑式的工作过程使微软经理们可以清楚地了解产品开发过程进行到了哪一步,也使他们在开发阶段的后期有能力灵活地删去一些产品特性以满足进度要求。
 
计划阶段
 
这里我总结了一下,主要是做以下事情
1.把你准备做什么样一个产品搞清楚,这个产品有什么特性
2.这个产品有没有市场,用户为何需要这个产品,已经该产品的走势
3.这个产品大概是个什么样子,是否有个大概的原型展示方便高层决策
4.设计的功能,目标,优先级,大概的进度。
 
所以微软指的这个计划阶段保护了很多可行性研究和产品规划的内容在里面,更多的是一个产品规划的内容。

开发阶段
开发阶段的计划对三四个主要的里程碑版本都逐个分配一组特性,规定出特性的细节和技术上的相关性,记录下单个开发员的任务以及对进度的估计。在开发阶段中,开发员在功能性说明的指导下写源代码,测试员写出测试项目组以检查产品的特性与工作范围是否正常,用户教育人员(User Education)则编写出文档草……
编辑 | 阅读全文(856) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | 有没有完美生活

许巍的完美生活是我比较喜欢的一首歌。在这首歌的歌词里面或许你可以找到属于你自己的完美生活。这里面还是一个心态的问题,如果老去想生活中不如意的事情,受挫折的事情那是不能有完美生活,或许酸甜苦辣的生活才是完美的生活。
 
青春的岁月,燃烧的梦想,有梦想的生活就是完美的生活!
 
体会这狂野,体会孤独,体会快乐和爱恨离别。五味的生活就是完美的生活!
 
再一次释放自己,胸中灿烂的情感,人生难得一知己,有知己的生活是完美生活!
 
编辑 | 阅读全文(955) | 回复(0),人月&神话 发表于 2007-7-17 13:19
(共 973 条) 1 2 ... 22 23 24 25 26 ... 64 65 翻页至

仅列出标题