Sat, 10 Jan 2009 10:22:00 GMT态度决定高度，努力造就实力！http://blog.csdn.net/zhijie435/http://blog.csdn.net/zhijie435/archive/2009/01/10/3745154.aspxhttp://blog.csdn.net/zhijie435/comments/3745154.aspx0http://blog.csdn.net/zhijie435/comments/commentRss/3745154.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=3745154<span class="Apple-style-span" style="color: rgb(0, 0, 0); font-family: Tahoma; line-height: 18px; -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; ">  IPD – 集成产品开发，华为花重金从IBM购买的一套产品集成开发流程，业界有一本书，PACE讲的就是这一套IPD流程，而IPD并不去讲你的开发要怎么做，IPD做的就是“投资决策、市场驱动”，更多的是决定做不做这个事情，做这个事情对于投资人员是不是受控的，所以在IPD里面会有DCP点（决策评审点），每个点上都会去考虑该不该做、值不值得去做，在引入这个东西以前，华为实际上是技术驱动的，并不是市场驱动的，就是说以前华为听说有个新技术，然后就开始做，做了很多这样的东西，但是后来都卖不出去，所以后来就引入了IPD，以市场驱动。在引入IPD后，是解决了做什么的问题，但是怎么做，还是按照自己的想法去做，后来就引入了CMM，引入CMM后对华为确<img src ="http://blog.csdn.net/zhijie435/aggbug/3745154.aspx" width = "1" height = "1" />Sat, 10 Jan 2009 18:22:00 +0800zhijie435http://blog.csdn.net/zhijie435/archive/2009/01/10/3745154.aspx#Feedbackhttp://blog.csdn.net/zhijie435/archive/2009/01/10/3745154.aspxzhijie435http://blog.csdn.net/zhijie435/archive/2009/01/08/3732352.aspxhttp://blog.csdn.net/zhijie435/comments/3732352.aspx0http://blog.csdn.net/zhijie435/comments/commentRss/3732352.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=3732352<span class="Apple-style-span" style="color: rgb(0, 0, 0); font-family: verdana; line-height: 18px; "><p style="margin-top: 1em; margin-right: 0px; margin-bottom: 0.5em; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 0px; text-indent: 2em; line-height: 22px; font-size: 14px; ">    1，把合适的工作分给合适的人<br>    显然，每个人都不是全能选手，每个人都有所长和所短。领导应该了解自己的下属，包括他们的特长和所好，让每个人做其最擅长和喜欢的工作。下发工作最好不要是强制性的，先征求他们的意见和建议，问一下他们的看法，一定对完成工作有很大的帮助。因为不是所有的领导其脑子都比下属聪明，相反，在具体的微观的细节上，下属往往比领<img src ="http://blog.csdn.net/zhijie435/aggbug/3732352.aspx" width = "1" height = "1" />Thu, 08 Jan 2009 17:25:00 +0800zhijie435http://blog.csdn.net/zhijie435/archive/2009/01/08/3732352.aspx#Feedbackhttp://blog.csdn.net/zhijie435/archive/2009/01/08/3732352.aspxzhijie435http://blog.csdn.net/zhijie435/archive/2008/12/30/3644707.aspxhttp://blog.csdn.net/zhijie435/comments/3644707.aspx0http://blog.csdn.net/zhijie435/comments/commentRss/3644707.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=3644707<P><SPAN class=Apple-style-span style="WORD-SPACING: 0px; FONT: 14px/25px Arial; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate; TEXT-ALIGN: left; orphans: 2; widows: 2; webkit-border-horizontal-spacing: 0px; webkit-border-vertical-spacing: 0px; webkit-text-decorations-in-effect: none; webkit-text-size-adjust: auto; webkit-text-stroke-width: 0">JavaEye新闻上次发表了“<A style="COLOR: rgb(0,102,153); TEXT-DECORATION: under<img src ="http://blog.csdn.net/zhijie435/aggbug/3644707.aspx" width = "1" height = "1" />Tue, 30 Dec 2008 17:36:00 +0800zhijie435http://blog.csdn.net/zhijie435/archive/2008/12/30/3644707.aspx#Feedbackhttp://blog.csdn.net/zhijie435/archive/2008/12/30/3644707.aspxzhijie435http://blog.csdn.net/zhijie435/archive/2008/12/18/3551898.aspxhttp://blog.csdn.net/zhijie435/comments/3551898.aspx0http://blog.csdn.net/zhijie435/comments/commentRss/3551898.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=3551898Minimize HTTP Requests<br />tag: content<br />80% of the end-user response time is spent on the front-end. Most of this time is tied up in downloading all the components in the page: images, stylesheets, scripts, Flash, etc. Reducing the number of components in turn reduces the number of HTTP requests required to render the page. This is the key to faster pages.<br />One way to reduce the number of components in the page is to simplify the page's design. But is there a way to build pages with ri<img src ="http://blog.csdn.net/zhijie435/aggbug/3551898.aspx" width = "1" height = "1" />Fri, 19 Dec 2008 02:40:00 +0800zhijie435http://blog.csdn.net/zhijie435/archive/2008/12/18/3551898.aspx#Feedbackhttp://blog.csdn.net/zhijie435/archive/2008/12/18/3551898.aspxzhijie435http://blog.csdn.net/zhijie435/archive/2008/12/10/3490388.aspxhttp://blog.csdn.net/zhijie435/comments/3490388.aspx0http://blog.csdn.net/zhijie435/comments/commentRss/3490388.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=3490388<br />        一个好的办法是每日构建（daily builds）。 每日构建意味着自动地，每天，完整地构建整个代码树、（译者按：“代码树”，原文为source tree，意思是将整个项目源代码的目录，子目录，文件的位置尽可能事先固定下来，这样在开发过程中各个模块间，各个文件间的相对位置都不会混乱。源代码树指的就是一个项目所有的已经组织好的代码文件。通常代码树应该用版本控制软件管理起来。虽然这个概念很基本，但是据我的观察，国内还是有软件公司在这方面做的不够好的，所以有必要解释一下。）<br /><br />自动地 － 因为你设定代码每天在固定的时间构建。在Unix环境下使用cron，在windows下使用“任务计划”。<br />每天 － 或者更频繁. 当然每天构建的次数越多越好啦。但是有时候构建次数还是有上限的，原因和版本控制有关系，等会儿我会谈到的。<br />完整地 －很可能你的代码有多个版本。多语言版本，多操作系统版本，或者高端低端版本。每日构建（daily build）需要构建所有这些版本。并且每个文件都需要从头编译，而不是使用编译器的不完美的增量编译功能。<br<img src ="http://blog.csdn.net/zhijie435/aggbug/3490388.aspx" width = "1" height = "1" />Wed, 10 Dec 2008 22:20:00 +0800zhijie435http://blog.csdn.net/zhijie435/archive/2008/12/10/3490388.aspx#Feedbackhttp://blog.csdn.net/zhijie435/archive/2008/12/10/3490388.aspxzhijie435http://blog.csdn.net/zhijie435/archive/2008/12/10/3488388.aspxhttp://blog.csdn.net/zhijie435/comments/3488388.aspx0http://blog.csdn.net/zhijie435/comments/commentRss/3488388.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=3488388对于软件项目团队，人员的技巧和经验可能对生产率产生高达10倍的影响。在《人月神话》中曾提到对于一个100人的团队，最好是只保留25个经验丰富的项目经理进行开发，而解散其它成员。当实际上一个软件团队不可能要求每个人都经验丰富，经过充分的培训和智商奇高，都是牛人的团队往往更容易出现混乱。因此 需要谨慎实施只雇佣优秀开发人员的想法，一个更好的方式是多考虑如何去建设一个有战斗力的团队或者是如何真正去保证团队的有效性。<br /><br />平衡和工作匹配是软件项目团队的重要方面。只要失去了平衡，团队就会变得脆弱。正如一个成功的橄榄球队，进攻，防守，教练，替补，传球等各种角色和活动都不可少，伟大的球队需要在每个位置都有关键球员，但是球队中不可能每个人都是球星。因此球员应该更多关注如何赢得比赛胜利，而不是单纯的个人荣誉。<br /><br />团队合作远比个人总和重要，因此项目经理需要真正做到人尽其材，每个人才都能够真正找到适合自己的位置，这样人才的配置才能达到一个平衡状态。对于如何为软件项目提供人员时候，波姆提出以下五项原则:<br /><br />1.顶尖人才原则-使用更好和更少的人员<br <img src ="http://blog.csdn.net/zhijie435/aggbug/3488388.aspx" width = "1" height = "1" />Wed, 10 Dec 2008 17:04:00 +0800zhijie435http://blog.csdn.net/zhijie435/archive/2008/12/10/3488388.aspx#Feedbackhttp://blog.csdn.net/zhijie435/archive/2008/12/10/3488388.aspxzhijie435http://blog.csdn.net/zhijie435/archive/2008/11/18/3325365.aspxhttp://blog.csdn.net/zhijie435/comments/3325365.aspx0http://blog.csdn.net/zhijie435/comments/commentRss/3325365.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=3325365对开发人员采用拉的方式而不是用领导者推的方式. <br /><br />激励开发人员就好比是像要向前移动一根绳索，最好的办法不是在绳子的这一端推而是在另外一端拉。 <br /><br />如果对工作人员激励不到位，也不管他们工作时间多长，管理者将得不到40小时的产出.因为很有可能他们上本只是为了应付，或者为了避免到了截至日期完不成任务而产生坏的影响. <br /><br />需要少量的超时就可以了。不要过度要求。 <br /><br />开发人员一般能自我激励，因为要使他们加班的关键就是诱发他们自我激励，即创造一个使他们自己想加班而不是逼他们加班的环境。通常来说激励开发人员最好的五种办法是： <br /><br />ａ，成就感　――――给开发者一个有意义的工作机会 <br /><br />b，成长的可能 ---提供项目能使开发人员在个人素质和专业上都能得到成长. <br /><br />C ，工作本身 ----分配任务时应该让开发任务是觉得工作是有意义的，赶到要为结果负责并且能看到结果. <br /><br />D , 个人技术生活 ---向开发人员表明你尊重他们的兴趣及个人爱好。 <<img src ="http://blog.csdn.net/zhijie435/aggbug/3325365.aspx" width = "1" height = "1" />Tue, 18 Nov 2008 21:18:00 +0800zhijie435http://blog.csdn.net/zhijie435/archive/2008/11/18/3325365.aspx#Feedbackhttp://blog.csdn.net/zhijie435/archive/2008/11/18/3325365.aspxzhijie435http://blog.csdn.net/zhijie435/archive/2008/11/13/3288842.aspxhttp://blog.csdn.net/zhijie435/comments/3288842.aspx0http://blog.csdn.net/zhijie435/comments/commentRss/3288842.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=3288842    对于软件开发来说，源于丰田生产管理系统中的“看板系统”是一种用于安排工作的非迭代方法。它并不使用固定时长的迭代和计划会议的工作方式，而是完成先前的工作后才从backlog中取得新的故事来做的工作方式。Dave Nicolette （Valtech公司的一个敏捷教练）说道：“在敏捷社区中，有一些人似乎变成了干零活的人。他们仅掌握一种敏捷工作的方法，却把它来遇到的解决所有问题．当你只会接管道时，那么所有的事情在你眼里就都都成了管道。”全面学习并扩展敏捷技能而不仅仅是那些SCRUM或XP的基础是非常重要的，比如熟悉像看板等其它工具。在软件开发团队中有各种各样的方法来实现看板系统。James Shore（《敏捷开发的艺术》一书的作者）就写过一种：“团队从backlog中拿到一个故事后，实现它，一旦完成就交付它。然后再拿下一个故事，实现并交付它。他们的工作就是完成并尽快地交付它，团队一次只做一个故事。”依James所说，让看板真正发挥作用有几个关键因素：最小化可交付的特性（MMF）：一个MMF是最小粒度且有商业价值的特性。MMF被放在一个队列中维护，（<img src ="http://blog.csdn.net/zhijie435/aggbug/3288842.aspx" width = "1" height = "1" />Thu, 13 Nov 2008 17:12:00 +0800zhijie435http://blog.csdn.net/zhijie435/archive/2008/11/13/3288842.aspx#Feedbackhttp://blog.csdn.net/zhijie435/archive/2008/11/13/3288842.aspxzhijie435http://blog.csdn.net/zhijie435/archive/2008/10/25/3141285.aspxhttp://blog.csdn.net/zhijie435/comments/3141285.aspx0http://blog.csdn.net/zhijie435/comments/commentRss/3141285.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=3141285<br /><br /> 如今，CTO下面带三个部门：研发、产品、用户体验设计（UED），几乎成了成熟互联网企业的标准配置。在整个行业对于“用户体验”认识还不够的时候，这样做比较有利于产品体验的提升。但，随着用户体验工作不断的深入，问题逐渐呈现。1、关注并参与到产品的用户体验设计，应该是整个公司的责任。但，往往正因为有了UED这样一个部门配置，导致其他角色冷眼旁观，或者被凉到了一边。用户体验，不是一个部门的事情。2、无论从权利还是能力的角度来讲，对UED都是很大的压力。很多时候产品体验不好，不一定就是设计的原因，更不一定是用户体验设计师的原因。但，只要体验不好就是你不好，谁让你叫UED！3、用户体验设计一直在深入，我们从最早的UI到人机交互，又到信息架构、内容设计，不断的切入到呈现层的每一个环节。虽然看似并没有触及到“产品方向/策略”的事情，但，对于呈现层甚至重要于结构层的网络产品来说，UED的工作和产品团队的工作重合度越来越高。矛盾也越来越大。当一个UED去讨论UI之外的设计时，从“身份”来讲就已经被别人不认可了，直接影响对“设计”本身的接受程度。4、对于产品部门，这也是一件特别痛苦的事<img src ="http://blog.csdn.net/zhijie435/aggbug/3141285.aspx" width = "1" height = "1" />Sat, 25 Oct 2008 16:50:00 +0800zhijie435http://blog.csdn.net/zhijie435/archive/2008/10/25/3141285.aspx#Feedbackhttp://blog.csdn.net/zhijie435/archive/2008/10/25/3141285.aspxzhijie435http://blog.csdn.net/zhijie435/archive/2008/10/24/3136292.aspxhttp://blog.csdn.net/zhijie435/comments/3136292.aspx0http://blog.csdn.net/zhijie435/comments/commentRss/3136292.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=3136292<br /><br /> 导读： 介绍 — Java 6中的线程优化Sun、IBM、BEA和其他公司在各自实现的Java 6虚拟机上都花费了大量的精力优化锁的管理和同步。诸如偏向锁（biased locking）、锁粗化（lock coarsening）、由逸出（escape）分析产生的锁省略、自适应自旋锁（adaptive spinning）这些特性，都是通过在应用程序线程之间更高效地共享数据，从而提高并发效率。尽管这些特性都是成熟且有趣的，但是问题在于：它们的承诺真的能实现么？在这篇由两部分组成的文章里，我将逐一探究这些特性，并尝试在单一线程基准的协助下，回答关于性能的问题。相关厂商内容InfoQ中文站电子杂志《架构师》试刊号发布 Java 6中的线程优化真的有效么？ 迷你书下载：代码之美（精选版） SOY Framework：Java富客户端快速开发框架 IDC：《软件商成长路线图》白皮书免费下载 相关赞助商 InfoQ中文站Java社区，关注企业Java社区的变化与创新，通过新闻、文章、视频访谈和演讲以及迷你书等为中国Java技术社区提供一流资讯。悲观锁模型Java支<img src ="http://blog.csdn.net/zhijie435/aggbug/3136292.aspx" width = "1" height = "1" />Fri, 24 Oct 2008 21:52:00 +0800zhijie435http://blog.csdn.net/zhijie435/archive/2008/10/24/3136292.aspx#Feedbackhttp://blog.csdn.net/zhijie435/archive/2008/10/24/3136292.aspxzhijie435