category/266705.aspxzh-CNTue, 29 Apr 2008 15:03:19 GMT60zhijie435http://blog.csdn.net/zhijie435/archive/2008/04/29/2342908.aspxTue, 29 Apr 2008 15:03:00 GMThttp://blog.csdn.net/zhijie435/archive/2008/04/29/2342908.aspxcomments/2342908.aspxhttp://blog.csdn.net/zhijie435/archive/2008/04/29/2342908.aspx#Feedback0comments/commentRss/2342908.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=2342908SCRUM Master主持。会议上，SCRUM Master对每个小组成员提三个问题： 1） 昨天的工作进展如何。 2） 有否遇到困难和障碍。 3） 今天的工作打算。 会后SCRUM Master集中精力排除障碍，小组成员则进行当天的开发。 l Sprint评审会议。评审后根据对每人的工作成绩，进行相应的激励。<img src ="aggbug/2342908.aspx" width = "1" height = "1" />zhijie435http://blog.csdn.net/zhijie435/archive/2008/01/16/2046533.aspxWed, 16 Jan 2008 11:07:00 GMThttp://blog.csdn.net/zhijie435/archive/2008/01/16/2046533.aspxcomments/2046533.aspxhttp://blog.csdn.net/zhijie435/archive/2008/01/16/2046533.aspx#Feedback0comments/commentRss/2046533.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=2046533 导读： 　　此书最早出版于1966年，我还没出生，PC也还没出现，知识分子应该还没有今天的浩浩荡荡。乍一看书名，讲的是“管理”没引起什么兴趣，看了才知讲的是知识分子的自我管理，只能叹为先知先觉，昂首仰视ing…… 　　英文名字叫《The Effective Executive》，怎么看都象“有效执行”，看完了才觉得中文名译的也是经典，虽然让我误以为是一般管理的书籍差点漏过：） ［注：德鲁克的书有时比较厚，讲的有时我觉得有点罗嗦而且兴趣暂为在此，所以我看的比较少翻的比较多，不是因为我对大师不敬，不要批评偶：）。不过此书很薄，细看］ 　　以下笔记并非完全按照书中顺序，并且夹杂了少量个人理解，仅供参考 　　管理者的工作必须卓有成效 　　“谁”是管理者？ 　　在一个现代的组织中，如果一位知识工作者能够凭借其职位和知识，对该组织负有贡献的责任，因而能实质的影响该组织的经营能力及达成的成果，那么他就是一位管理者。 　　书中，“管理者”泛指知识工作者、经理人、专业人员，他们必选在工作中利用其职位和知识做出影响整体绩效和成果的决策。 　　值得注意的是，上述的定义并不以为着大部分知识工作者都是管<img src ="aggbug/2046533.aspx" width = "1" height = "1" />zhijie435http://blog.csdn.net/zhijie435/archive/2008/01/15/2045859.aspxTue, 15 Jan 2008 19:53:00 GMThttp://blog.csdn.net/zhijie435/archive/2008/01/15/2045859.aspxcomments/2045859.aspxhttp://blog.csdn.net/zhijie435/archive/2008/01/15/2045859.aspx#Feedback0comments/commentRss/2045859.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=2045859 导读： 　　　　年底正好跟猎头公司接触的很多，自己的朋友、同事、BF都在IT圈子里。就说说几大IT 　　公司的情况，给想跳槽或者有目标的朋友们借鉴一下。所谈的数字基本属于平均水平， 　　也只谈到中层，高管层不是我们所了解的，天文数字也不到这里讨论了。 　　本人是做sales的，所以以sales的情况为主，附带谈谈开发的状况。 　　1、主流IT公司的三、六、九等。 　　在猎头那边，IT公司也有三六九等之分，收入和福利是一个方面，职位的稳定性也是很 　　大的一个评分因素。 　　一类公司：IBM、MS、CISCO、EMC和NCR的某些部门…… 　　MS、CISCO是以高收入取胜：以sales和普通开发人员为例（3年工作经验左右），一般会 　　开到40万年薪，工资和奖金7/3-6/4分，sales背数字，超额的话奖金很恐怖（上下浮动 　　10%，看各人谈的本事了）。一般有8%-20%*工资的房帖，20%的基本是小leader了，公积 　　金每月2000左右，如果公司福利好有补充公积金，那就有3000多了。 　　IBM以稳定著称，基本属于老外的国企，机构庞大，内部事务冗繁，员工50%的精<img src ="aggbug/2045859.aspx" width = "1" height = "1" />zhijie435http://blog.csdn.net/zhijie435/archive/2008/01/15/2045710.aspxTue, 15 Jan 2008 17:44:00 GMThttp://blog.csdn.net/zhijie435/archive/2008/01/15/2045710.aspxcomments/2045710.aspxhttp://blog.csdn.net/zhijie435/archive/2008/01/15/2045710.aspx#Feedback0comments/commentRss/2045710.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=2045710 导读： 　　看了很多创业的case，都有点下笔千言，离题万里的情况。就是很多case都很精彩，但是公司的价值最终是落实到给创业者和投资人的回报的。因此，所有的case，最终都是，落实到盈利模式上。 　　一位投资人士说的很明确，中国的盈利模式很简单，就是两个半，广告，游戏，还有半个是电子商务。我觉得这句话如果送给很多创业中的人，他们肯定都有如梦初醒的感觉。很多人看着成功故事融入互联网创业大潮中，我觉得他首先应该明白互联网是地狱，然后才知道互联网也是天堂。 　　一方面，互联网的精神就是免费。很多网站都是提供一个范围的一种信息工具或者一种交流工具。它有个免费的过程。也就需要创业者在创业初需要考虑自己的资金是否能够支撑到盈利的时候。从这一点上，互联网就是地狱，路边餐厅，传统软件都是买的第一天开始都是赚钱的。随着前有巨头的增多，免费的门槛越来越大，创业公司的盈利周期越来越长。如果不能从细节创新，互联网就是地狱。 　　另一方面，互联网的免费让他具备了一个超乎任何传统媒介的流通速度。比如一个路边餐厅，传统软件可能第一天都赚钱，但是你的扩展性呢？路边餐厅可能在面对新的饮食习惯和本地对手。传统软<img src ="aggbug/2045710.aspx" width = "1" height = "1" />zhijie435http://blog.csdn.net/zhijie435/archive/2008/01/15/2045686.aspxTue, 15 Jan 2008 17:34:00 GMThttp://blog.csdn.net/zhijie435/archive/2008/01/15/2045686.aspxcomments/2045686.aspxhttp://blog.csdn.net/zhijie435/archive/2008/01/15/2045686.aspx#Feedback0comments/commentRss/2045686.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=2045686 导读： 　　新方法论 　　The New Methodology 　　作者：Martin Fowler 翻译：坚强2002 　　源文档&lt;http://www.martinfowler.com/articles/newMethodology.html&gt; 　　过去的几年中，敏捷开发蓬勃发展，敏捷方法被当作修正机构结构僵化的一剂良药抑或是打通软件过程奇经八脉的不二法门。本文我将探索敏捷方法的源头，不是强调它何等重要而是要把关注点放在它的适应性和以人为本这两个方面。 　　Contents 　　· 无章法里程碑敏捷 　　· 可预见性VS 适应性 　　o 泾渭分明的设计与实施 　　o 需求的不可预见性 　　o 可预见性不可能做到吗? 　　o 控制不可预见的过程—迭代 　　o 适应性的客户 　　· 以人为本 　　o 人件 　　o 程序员：重任在肩 　　o 管理以人为本的过程 　　o 度量之难 　　o 业务领导者的角色 　　· 自适应过程 　　· 敏捷开发的特点 　　o 敏捷宣言 　　o XP (极限编程) 　　o Scrum 　　o Crystal 　　o Context Dri<img src ="aggbug/2045686.aspx" width = "1" height = "1" />zhijie435http://blog.csdn.net/zhijie435/archive/2007/12/20/1956168.aspxThu, 20 Dec 2007 17:41:00 GMThttp://blog.csdn.net/zhijie435/archive/2007/12/20/1956168.aspxcomments/1956168.aspxhttp://blog.csdn.net/zhijie435/archive/2007/12/20/1956168.aspx#Feedback0comments/commentRss/1956168.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1956168 导读： 　　在项目管理的三要素TQC中，这三者在项目管理中是需要平衡的，但是更需要明白他们并不是平等的，为什么这么说呢？这也是因为软件项目的特点引起的，关于软件的项目管理的特点参见我的博客中关于CMM的文章的描述。在软件项目中进度的延迟和成本的增加很大程度上是因为质量引起的，系统的质量问题往往会导致返工，在软件项目中返工已经成为项目经理的恶梦。而返工的直接后果便是进度的拖延和成本的上升，当然还会导致团队人员的沮丧、挫折的心理，这当然都会影响到开发的效率。 　　以质量为导向的项目管理在进度控制和成本方面是最经济的。这有业界项目管理专家的统计数据可以说明。对于软件项目来讲，成本主要是来自人工成本，因此人员的效率、沟通成本、过程能力、过程积累等非常重要。另外我们的成本是指Total成本的概念，而不仅仅指开发成本。目前在很大公司都存在这样的问题，开发的预算控制很好，但是由于忽略了质量，导致这个项目在实施、维护阶段返工成本很高，甚至是重新开发，导致了客户的满意度下降，直接影响整体的成本和利润。我个人的体会是Q是这三者之中的因，T、C是结果。因此要想降低和控制成本，就要到源头来控制和找原因<img src ="aggbug/1956168.aspx" width = "1" height = "1" />zhijie435http://blog.csdn.net/zhijie435/archive/2007/12/20/1956157.aspxThu, 20 Dec 2007 17:36:00 GMThttp://blog.csdn.net/zhijie435/archive/2007/12/20/1956157.aspxcomments/1956157.aspxhttp://blog.csdn.net/zhijie435/archive/2007/12/20/1956157.aspx#Feedback0comments/commentRss/1956157.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1956157 导读： 　　在软件测试过程中，测试数据的准备是一个工作量很大而且也是一个技术活。因此如何准备大量的测试数据，而且如何准备高质量的测试数据，满足测试的需求，就是一个重要的话题。 　　首先看数据的来源，数据的来源一般来讲有三个个，一个是根据被测系统需求的分析，针对正常业务，异常情况，边界情况等来构建完整的数据，又称为“造”数据。这不仅仅包括最基本的基础数据，比如：用户、权限、配置、基础编码、原数据等，还包括上面提到的业务数据。这对于比较小型的系统来说还是可行的，对于大型的系统来说可能就是一个巨大的工程了。 　　第二种方式就是利用现有系统，这适合已有类似系统，测试是针对升级或者增加功能的产品化的系统。这种情况把已经在生产环境中运行的数据导出。在此基础上再进行数据的整理、加工为测试数据。 　　还有一种方式就是将现有非电子化的业务数据录入到系统中，在验证业务的同时也完成了测试数据的积累。即边测试边积累数据。但是这种情况积累的数据往往有一定局限性，因为已经发生的业务数据基本是正确的、一致的，而且可能缺少某些特定业务的数据（不常发生的业务）。这样就需要根据对测试需求的分析，追加新的测试数据，<img src ="aggbug/1956157.aspx" width = "1" height = "1" />zhijie435http://blog.csdn.net/zhijie435/archive/2007/12/20/1956146.aspxThu, 20 Dec 2007 17:30:00 GMThttp://blog.csdn.net/zhijie435/archive/2007/12/20/1956146.aspxcomments/1956146.aspxhttp://blog.csdn.net/zhijie435/archive/2007/12/20/1956146.aspx#Feedback0comments/commentRss/1956146.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1956146 导读： 　　序号 类型 度量指标 描述 度量频度 数据源 　　1 原始度量元 需求功能点个数 被测系统或被测模块的需求规格说明书的需求个数 测试需求分析阶段 　 　　2 系统内部接口数 单系统内部的模块之间的接口数量 测试需求分析阶段 　 　　3 跨系统外部接口数 被测系统与外部系统之间的接口数量 测试需求分析阶段 　 　　4 测试需求个数 对被测需求分析后的测试需求的个数 测试设计阶段 　 　　5 测试案例个数 测试案例的数量，可以根据测试的阶段分不同的类型，比如连接测试案例、系统集成测试案例等 测试设计阶段 　 　　6 评审缺陷数量 同行评审或者检查发现的缺陷的数量 测试需求分析和设计阶段 　 　　7 测试缺陷总数 测试发现的BUG 测试实施阶段 　 　　8 复合度量元 缺陷密度 ＝缺陷数/需求功能点个数 测试结束后 　 　　9 缺陷来源分布 根据缺陷的来源统计缺陷的分布情况 随时 　 　　10 缺陷严重程度分布 根据缺陷的严重程度统计缺陷的分布情况 随时 　 　　11 缺陷类型分布 根据缺陷的类型统计缺陷的分布情况 随时 　 　　12 缺陷位置分布 根据发现缺陷的位置统<img src ="aggbug/1956146.aspx" width = "1" height = "1" />zhijie435http://blog.csdn.net/zhijie435/archive/2007/12/20/1956142.aspxThu, 20 Dec 2007 17:27:00 GMThttp://blog.csdn.net/zhijie435/archive/2007/12/20/1956142.aspxcomments/1956142.aspxhttp://blog.csdn.net/zhijie435/archive/2007/12/20/1956142.aspx#Feedback0comments/commentRss/1956142.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1956142 导读： 　　 　　软件项目的返工问题 　　软件行业普遍利润率低，软件项目的成本超支司空见惯，到底成本到哪儿去了？ 　　软件工程师天天加班加点，说到底还是返工问题。软件项目的返工成本几乎达到 　　项目成本的一半以上。到底什么算返工，目前业界好像还没有确切的定义，我总结 　　了一下，一下情况应该算是返工： 　　返工的定义可以理解为应该并有能力做到返工后的水平的却因为各种主观因素 　　却没有一次性达到，只能用返工甚至多次返工的方法来达到目前的要求。 　　1. 隐含需求的变更； 　　2. 由潜在的需求引起的变更； 　　3. 架构选型不当引起的移植、变更； 　　4. 需求或设计的理解错误造成的变更； 　　5. 在项目范围、技术平台、技术路线决策失误造成的变更； 　　6. 设计的抽象不够，造成的开发过程中的浪费、合并、再抽象等工作； 　　7. 评审遗漏缺陷造成的变更； 　　8. 测试遗漏造成的反复修复工作量。 　　其实对比其他行业，软件行业似乎是返工最大的了，很少听说哪个大楼把地基扒 　　了三次再盖的，但是很多软件项目确实不止一次的扒掉重来。甚至很少听说哪个项目 　　是一直一步一步往前走的<img src ="aggbug/1956142.aspx" width = "1" height = "1" />zhijie435http://blog.csdn.net/zhijie435/archive/2007/12/20/1956113.aspxThu, 20 Dec 2007 17:15:00 GMThttp://blog.csdn.net/zhijie435/archive/2007/12/20/1956113.aspxcomments/1956113.aspxhttp://blog.csdn.net/zhijie435/archive/2007/12/20/1956113.aspx#Feedback0comments/commentRss/1956113.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1956113 导读： 　　 　　在以前的文章中关于项目经理做什么或者如何做好一个项目管理者/项目经理都有很多的叙述。但是最近也有很多的朋友MSN询问作为一个PM应该关注的重要的事情是哪些？ 当然其实所谓的重要的事情，如果从系统化的角度来看的话，有三个系统化教材可以得到全部的答案，这也是作为在软件行业内作为PM应该熟悉的内容，他们是SWEBOK（Software Engineering Body Of Knowledge）、SW-CMMI（Software – Capability Maturity Model Integration）、PMBOK（Project Management Body Of Knowledge）。 　　其实这样的答案跟没有回答一样，下面我还是从个人的经验和观点来看： 　　需求 　　需求是直接与项目的范围相关的，屏蔽和管理需求的风险是作为一个软件项目经理最重要的关注点。同时对需求的了解也是PM有效与外部客户与内部Team有效沟通交流的基础。 　　架构（Key Technical Points 关键技术点） 　　关于项目的架构设计，PM最需要关心的是关键技术点。因为项目<img src ="aggbug/1956113.aspx" width = "1" height = "1" />zhijie435http://blog.csdn.net/zhijie435/archive/2007/12/17/1943603.aspxMon, 17 Dec 2007 13:56:00 GMThttp://blog.csdn.net/zhijie435/archive/2007/12/17/1943603.aspxcomments/1943603.aspxhttp://blog.csdn.net/zhijie435/archive/2007/12/17/1943603.aspx#Feedback0comments/commentRss/1943603.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1943603 导读：　　作者：Rock Sun, Subversion中文站。　　如有转发请注明出处：http://www.subversion.org.cn/index.php?option=com_content&amp;amp;task=view&amp;amp;id=85&amp;amp;Itemid=9　　版本控制最关键的一件事是保证数据的安全性，不能因为磁盘损坏，程序故障造成版本库无可挽回的错误，为此必须制定较完备的备份策略。在Subversion中，我们有三种备份方式：完全备份，增量备份和同步版本库。　　1, 完全备份　　最常见和简单的备份就是直接使用拷贝命令，将版本库目录拷贝到备份目录上，就可以了。但是这样不是很安全的方式，因为如果在拷贝时版本库发生变化，将会造成备份的结果不够准确，失去备份的作用，为此Subversion提供了“svnadmin hotcopy”命令，可以防止这种问题。　　还记得我们的版本库目录吗？　　D:\SVNROOT　　├─project1　　│ ├─conf　　│ ├─dav　　│ ├─db　　│ │ ├─revprops　　│ │ <img src ="aggbug/1943603.aspx" width = "1" height = "1" />zhijie435http://blog.csdn.net/zhijie435/archive/2007/12/12/1930858.aspxWed, 12 Dec 2007 10:21:00 GMThttp://blog.csdn.net/zhijie435/archive/2007/12/12/1930858.aspxcomments/1930858.aspxhttp://blog.csdn.net/zhijie435/archive/2007/12/12/1930858.aspx#Feedback0comments/commentRss/1930858.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1930858 导读：　　在Web工程过程中，基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同，它不但需要检查和验证是否按照设计的要求运行，而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。然而，Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。因此，我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术　　本文将 web 测试分为 6 个部分：　　功能测试　　性能测试（包括负载/压力测试）　　用户界面测试　　兼容性测试　　安全测试　　接口测试　　本文的目的是覆盖 web测试的各个方面，未就某一主题进行深入说明。　　1 功能测试　　1.1 链接测试　　链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页<img src ="aggbug/1930858.aspx" width = "1" height = "1" />zhijie435http://blog.csdn.net/zhijie435/archive/2007/12/09/1925627.aspxSun, 09 Dec 2007 15:58:00 GMThttp://blog.csdn.net/zhijie435/archive/2007/12/09/1925627.aspxcomments/1925627.aspxhttp://blog.csdn.net/zhijie435/archive/2007/12/09/1925627.aspx#Feedback0comments/commentRss/1925627.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1925627要建立高新企业持续的竞争力和研发能力，必须注重过程控制，必须用制度取代“大拿”，建立 “麦当劳式”的工序研发模式，依靠有效的管理控制体系。要改变传统的研发理念，面向研发而不是面向 科研，面向项目管理而不是面向产品，面向过程控制而不是面向结果，面向技术储备和积累，而不是寄希 望于机遇，面向研发规律而不是追求研发进度，这样，才能建立正确的企业研发战略和研发组织结构，才 能真正出现“中国的微软”。不仅研发管理如此，其他各种项目的管理也应借鉴研发管理中的经验和教训。 <img src ="aggbug/1925627.aspx" width = "1" height = "1" />yoyohttp://blog.csdn.net/zhijie435/archive/2007/11/30/1908885.aspxFri, 30 Nov 2007 12:19:00 GMThttp://blog.csdn.net/zhijie435/archive/2007/11/30/1908885.aspxcomments/1908885.aspxhttp://blog.csdn.net/zhijie435/archive/2007/11/30/1908885.aspx#Feedback0comments/commentRss/1908885.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1908885一位石油业高层主管对您说：“我听说 FooBarKhan 那里有石油，我太想要了！请您赶紧用一周的时间写一份报告，告诉我那里有多少石油，在那里建油田需要花多少钱、多少时间、多少资源。”在石油业中，这样的场景是很滑稽的，为什么同样的做法反而被软件工业接受了呢？理智的石油人士知道没有预先在试验性钻探上大量投入是不可能获得答案的。只有通过调查发现了储量和地质情况的真相，作出估算或初步的计划才有可能。可是，在同样的不确定性和高复杂度的情况下，我们却奢望没有投入实际的“试验性钻探”调查就能对软件项目进行估算和计划，这不是很可笑吗？ <img src ="aggbug/1908885.aspx" width = "1" height = "1" />yoyohttp://blog.csdn.net/zhijie435/archive/2007/09/14/1785365.aspxFri, 14 Sep 2007 16:49:00 GMThttp://blog.csdn.net/zhijie435/archive/2007/09/14/1785365.aspxcomments/1785365.aspxhttp://blog.csdn.net/zhijie435/archive/2007/09/14/1785365.aspx#Feedback0comments/commentRss/1785365.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1785365Dominic Tavassoli认为，结合使用基于任务的配置管理、集成配置管理的企业级变更管理、计量面板以及敏捷的需求管理工具并遵循敏捷软件开发的根本前提条件，可以有助于确保企业级开发成功。敏捷开发在企业级的应用将健壮的变更和配置管理解决方案用作大型的复杂开发工具，可以包括分散的项目，这些项目具有遵从性方面的需求，如跟踪性和文档、客户和商业案例、需求和变更请求。团队需要快速交付高质量软件时，基于任务的配置管理方案通过为开发人员提供在早期快速识别问题的方法，来减少团队的停机时间和返工。<img src ="aggbug/1785365.aspx" width = "1" height = "1" />