| green's profile我的共享空间PhotosBlogLists |  Tools  Help |
|
3/29/2007 Jolt AwardsBooks (Practical/General Developer Interest) Agile Software Development: The Cooperative Game (Addison-Wesley) by Alistair Cockburn Books (Technical) Code Quality (Addison-Wesley) by Diomidis Spinellis Change and Configuration Management AccuRev 4.5 with AccuWorkflow (Accurev) Collaboration Tools Adobe Acrobat Connect Professional (Adobe Systems) Database Engines and Data Tools Coral8 Engine (Coral8) Design and Modeling Compuware OptimalJ (Compuware) Development Environments EiffelStudio Open Source Edition (Eiffel Software) Enterprise Tools Cape Clear ESB Platform (Cape Clear Software) Libraries, Frameworks and Components JViews (ILOG) Mobile Development AccuSPEECH (Vangard Voice Systems) Project Mangement Tools 6th Sense Analytics (6th Sense Analytics) Security AppScan (Watchfire) Automated Testing Tools AgitarOne (Agitar Software) Bug and Defect Tracking Tools JIRA (Atlassian Software Systems) Utilities Adobe Captivate 2 (Adobe Systems) Web Development Adobe Flex 2 (Adobe Systems) Web Sites/Developer Networks CM Crossroads (CMC Media) 业知识管理实施的五个步骤————企业经营者必读随着信息化建设的深入，IT不仅成为企业运营的基础平台，而且在ERP、CRM、OA等信息系统内沉淀了大量的知识，成为企业创新的知识源泉，于是知识管理逐渐提上了大中企业信息化建设的议事日程。如何实施知识管理呢？ 第一步:认知 认知是企业实施知识管理的第一步，主要任务是统一企业对知识管理的认知，梳理知识管理对企业管理的意义，评估企业的知识管理现状。帮助企业认识是否需要知识管理，并确定知识管理实施的正确方向。 主要工作包括:全面完整的认识知识管理，对企业中高层进行知识管理认知培训，特别是让企业高层认识知识管理；利用知识管理成熟度模型等评价工具多方位评估企业知识管理现状及通过调研分析企业管理的主要问题；评估知识管理为企业带来的长、短期效果；从而为是否推进知识管理实践提供决策支持；制定知识管理战略和推进方向等。 该阶段是企业接触知识管理的第一步，因此需要特别注意两点。一是，企业文化和管理模式对知识管理采用何种实施方法有着决定性的作用，因此应特别注意不要忽略企业文化和管理现状；另一方面，知识管理的推广需要企业流程、组织、绩效等管理机制的配合，同时也需要深入企业业务层，必须得到高层重视，并将知识管理提升到战略高度，才能保证知识管理在企业中顺利推进；再者，由于知识管理需要长期的推进，需要对知识管理的效益进行准确量化评估，才能转化为长期发展的动力。 认知阶段多数企业会邀请外部的一些培训、咨询公司参与，关键在于了解业界标杆企业的做法和选择合适自己现状的解决方案。 第二步:规划 知识管理的推进是一套系统工程，在充分认知企业需求的基础上，详细规划也是确保知识管理实施效果的重要环节。这个环节主要是通过对知识管理现状、知识类型的详细分析，并结合业务流程等多角度，进行知识管理规划。在规划中，切记知识管理只是过程，而不能为了知识管理而进行知识管理，把知识管理充分溶入企业管理之中，才能充分发挥知识管理的实施效果。 主要工作包括:从战略、业务流程及岗位来进行知识管理规划；企业管理现状与知识管理发展的真实性分析；制订知识管理相关战略目标和实施策略，并对流程进行合理化改造；知识管理落地的需求分析及规划；在企业全面建立知识管理的理论基础。 规划阶段的难点主要包括:知识管理和企业战略目标与流程的结合；知识管理与其他管理制度如人力资源管理的结合及管理思想的转变；以知识管理思想为基础的业务流程的改造；知识管理的文化氛围的建立；知识管理规划与企业实际情况结合，建立适合企业自身特点的实践形式。本阶段建议由咨询公司和企业中高层统一认识共同来参与规划，确定知识管理实施的解决方案。 第三步:试点 此阶段是第二阶段的延续和实践，按照规划选取适当的部门和流程依照规划基础进行知识管理实践。并从短期效果来评估知识管理规划，同时结合试点中出现的问题进行修正。 主要工作内容:每个企业都有不同的业务体系，包括:生产、研发、销售等，各不同业务体系的任务特性均不相同，其完成任务所需要的知识亦有不同，因此需要根据不同业务体系的任务特性和知识应用特点，拟订最合适、成本最低的知识管理方法，这称为知识管理模式分析KMPA。另外，考虑到一种业务体系下有多方面的知识，如何识别关键知识，并判断关键知识的现状，进而在KM模式的指导下采取有针对性的提升行为，这可以称为知识管理策略规划KSP。 所以，此阶段的重点是结合企业业务模式进行知识体系梳理，并对知识梳理结果进行分析，以确定知识管理具体策略和提升行为。 本阶段是知识管理从战略规划到落地实施的阶段，根据对企业试点部门的知识管理现状、需求和提升计划的分析，应该考虑引入支撑知识管理落地的知识管理IT系统。根据前几个阶段的规划和分析，选择适合企业现状的IT落地方法，如带知识管理功能的办公协同系统、知识管理系统、知识门户落地等等。可以说，本阶段在知识管理系统实施中难度最大，需要建立强有力的项目保障团队，做好业务部门、咨询公司、系统开发商等多方面协调工作。 难点:选择合适的部门进行试点；知识体系的建立及知识管理模式和策略分析；针对性的提升行动计划。 第四步:推广和支持 在试点阶段不断修正知识管理规划的基础上，知识管理将大规模在企业推广，以全面实现其价值。 推广内容:知识管理试点部门的实践，在企业中其他部门的复制；知识管理全面的溶入企业业务流程和价值链；知识管理制度初步建立；知识管理系统的全面运用；实现社区，学习型组织、头脑风暴等知识管理提升计划的全面运行，并将其制度化。 难点:对全面推广造成的混乱进行控制和对知识管理实施全局的把握；知识管理融入业务流程和日常工作；文化、管理、技术的协调发展；知识管理对战略目标的支持；对诸如思想观念转变等人为因素的控制以及利益再分配；建立知识管理的有效激励机制和绩效体系。 第五步:制度化 制度化阶段既是知识管理项目实施的结束，又是企业知识管理的一个新开端，同时也是一个自我完善的过程。要完成这一阶段，企业必须重新定义战略，并进行组织构架及业务流程的重组，准确评估知识管理在企业中实现的价值。 这一阶段，企业开始意识到知识管理是企业运作的一种战略，而且有必要成为综合企业运作机制的一部分，从而把知识管理全面融入企业战略、流程、组织、绩效等管理体系。在此基础上，知识管理将逐渐演变企业核心竞争力的一部分，有力促进企业每一位员工的发展。 重点:知识管理深入业务体系；知识管理的广义推广；知识管理提供战略支持；知识管理新实践的创新。 难点:知识管理深入业务体系的流程调整；知识管理思想推广到其它管理体系中；知识管理文化氛围的建立；知识管理新实践和方法的创新。 纵观国外知识管理的发展轨迹，结合国内知识管理的应用现状，可以预见在不久的将来，知识管理将逐渐成长为一种管理思想，进而形成一种管理标准，如同质量管理、流程管理一样，将成为体现组织核心能力的关键要素。因此，企业成功实施知识管理对企业核心竞争的增强和企业的长久发展将具有重大的意义。 然而，知识管理从知到行，决不是简单的、盲目的，而是需要涉及多个层面的综合解决方案，企业在推进知识管理过程中，只有透查现状、明确问题，才能合理设计实施路径，发挥出知识管理的真正价值。 知识共享（转）通常，知识共享并不是公司文化的一部分，公司象学校其他组织一样，只奖励那些掌握有独特知识技能的员工。Best Practices咨询公司的分析师Adam Bianchi就谈到：经常，你对公司的价值取决于你所知道的而其他人并不知晓的知识。 但越来越多的开明企业开始实施新的旨在改变这种落后观念的策略，他们使用各种激励方法来表明他们对共享知识很重视。例如，有的公司有对于知识共享员工的奖励及认知计划，它们包括公司通讯稿上的奖励，薪金提升等。还有的公司根据员工参与知识共享活动的程度决定他们的升职及额外的休假。 Lighthouse咨询集团公司的总裁Albert Ray Edwards认为：教育是克服知识共享障碍的关键，公司应向员工表明共享知识是他们的利益所在，例如，精通评估财产风陷的保险经纪人若有理由相信能从同事那获得交流的信息，他将很乐意公布自己拥有的信息。根据Edwards的认识，只有在组织具体量化并能衡量知识共享计划成功尺度基础上，教育方法才能发挥最佳作用，而且最重要的是公司必须向员工表明知识共享能为他们带来什么，能如何帮助他们改进工作。 其他观察家则认为知识共享的成功还须使用更多的方法。Laurence Prusak，IBM知识管理学院的执行总裁谈到：组织虽然也能通过个人激励及教育等手段取得某种程度的成功，但只有进行彻底的变革，如建立新型的社会团体，才能取得巨大的成功，其实目前公司里已有不少共享活动，它们仅在小组内部，若想扩大共享活动，就必须使更多的人加入小组中。但无论公司采取什么方法，耐心是很重要的，因为你谈论实施的不是一个计算机系统，而是一整套文化，这须花一段时间。 传统的激励方法，如奖金，已不足已改变员工行为。在最近的一次战略调查中，我们了解了七家公司关于如何激励员工知识共享的方法。由于这些方法计划刚起步，他们还不准备宣称已取得完全成功，但每家公司都对知识共享立场坚定。许多专家认为这种承诺已是进行变革的最重要的第一步。 1、雇佣愿意共享知识的员工--Collective Technologies公司的经验。 “若你希望有共享知识的员工，最好是从开始做起”，Collective Technologies 总裁谈到；“要创立一个员工共享知识的文化必须从招聘员工这一步开始，因此，我们仅招聘那些我们的员工感觉能够与之进行良好工作的人员。”所以，公司的应聘过程通常持续连续几天，要求应聘者与现在的员工进行广泛的商业及社会交流。这种过程最后以群体讨论的形式达到高潮，员工将对应聘者的表现评估，只要有一个反对意见，应聘者就不能录取。此外，Collective还以员工回答了多少公布的问题，多快能回答问题，当他们获得答案后，是否能经常总结问题并将问题及时公布于公司内部网上等标准来对员工进行绩效评估。 2、发展信任--Buckman Laboratories的方法 该公司并没有较多的激励计划，它依靠在员工之间及员工与公司之间建立信任的氛围来鼓励员工共享知识，“谁是你共同分享思想的人？当然是那些值得信任的人。”Robert H. Buckman,，公司前总裁谈到。这种建立信任的过程开始于公司的10点道德标语：我们尊敬地对待每一个员工，致力于持续而又积极的交流方式----- 我们充分承认并奖励每一个员工的贡献。但这些标语只有在员工相信公司将认真实施它们时，才能起到鼓励员工的作用。因此公司始终都以标语的原则作为决策基础。例如，员工评估表上的评估分数表明了他的行为是否符合标语原则。虽说标语并没有明确指出知识共享，公司的文化却强调了这一观念。主管们通常以员工是否经常对于其他人提出的问题作出反应或他们是否经常在公司内部网上提出问题来考虑员工的升职。但即使是这种周密的方法也不能保证一定成功，公司将尽最大努力塑照信任文化来鼓励知识共享。 3、多层激励--Cap Gemini Ernst & Young的方法 “若你想改变公司结构，你必须触动每个阶层”。 John DiStefano，公司知识管理部经理谈到，“公司内部任何事物，从办公桌上的留言板到会议室中的讨论稿，都必须反映知识共享的需要。”为了在员工中灌输这种意识，知识管理部门领导使用一种三层次方法，针对组织内部的不同层次设计出不同的激励方法。在行政管理层，必须让行政人员知道共享知识是很迫切的，向他们表明潜在的商业效果，并根据他们知晓公司市场行销次数及新产品上市的缩短天数等情况的程度来衡量知识共享的结果。在部门管理层，则必须表明知识共享给他们各自部门带来的益处。举例说，开展一项新的服务涉及到很多部门的运作，包括研究，行销，销售等。每个部门都有各自的责任，都须以其独特方法激励他们共享知识。比如说，我们会对销售人员谈触发销售，对行销人员谈市场推广。在员工管理层次，公司应明确认定出那些他们希望激励员工所做的事与那些他们希望员工不做的事，并对员工的积极行为进行奖励。比如在公司里应有忠诚计划，每个曾发表研究报告或将信息交于讨论组的员工，在其他员工使用其信息后，都可得到忠诚分数，这些分数将决定员工所拥有的特殊福利。同时，公司也将知识共享作为评估员工的因素来衡量绩效，通常，绩效尺度为2-5，若员工未参加知识共享活动，他们的绩效尺度达不到4分以上。 4、公众承认--Harris Government Communications Systems的做法 在该公司有很强的知识共享文化氛围，每个员工都经常参加会议，阅读内部刊物，参加 e-mail 讨论，公司还积极实行导师制以辅导员工。 虽燃如此，坚持仍是必要的。Michael Zeitfuss，公司战略管理部的主席谈到：我们始终坚持寻找维持并加强这种文化的方法，为达到这个目的，公司建立了两个表扬计划，一个是“荣誉墙”的建立，它是人们经常进入大楼的一段走廊，其墙壁的瓷片上刻有那些积极参与知识共享员工的姓名。第二个计划表扬那些运用知识对公司作出贡献的员工。他们将得到证书，在公司的新闻稿中得到提名表扬，其荣誉也将记入永久档案中。 这两个计划之所以有用，关键在于两个原因，一是它重视奖励员工。二是它表明了公司对于知识共享的承诺 5、为共享而重组--Northrop Grumman Air Combat Systems的做法 人们通常与同组的人共享知识，Scott Shaffer, 该公司知识管理项目经理指出。因此，公司可使用各种激励手段鼓励不同小组之间人们的共享，或者，重组组织使人们能成为不同小组的成员，从而增加共享知识范围。现在，该公司已建立综合产品小组，员工们都成为核心功能小组的成员，如工程，制造，产品及原料支持小组。同时，公司还通过会议，课程教授，导师培训等方式鼓励相互小组之间的知识共享。员工们经过一段时间调整，也将充分利用这种新的分组方式，实现共享。公司则依据员工在各小组中交往联系的能力，对他们评估。 6、创建社区--世界银行 世界银行为了促进知识共享，建立了许多知识社区。它们是由拥有共同兴趣专长及技术的员工组成。社区的成员通过电话，电子邮件，在线留言板等方式保持联系。Denning，世界银行知识管理项目官员谈到：世界银行一直注重新的通讯技术的使用，但员工们通常只与他们认识的人共享知识。当建立了社区后，组织扩大了每个员工与其他同事共享知识的范围，即使他们之间并未见过面。 组成社区的基础是员工的兴趣，并不是组织的命令，人们通常也愿意与拥有共同兴趣的人共享知识。从这点来说，以兴趣为核心建立团体成为激励知识共享的最好方式，在这些团体中，知识共享都是不自觉情况下发生。例如，目前该组织已建立一个250个人员组成的委员会来对不同兴趣主题的社区提出议案，这些提案让人非常吃惊，范围极其广泛，一旦实施，将对组织共享起极大作用。 7、发展领导--Capital One Financial的做法 有时，公司内部一小群知识管理的热爱者能成为促进知识共享的催化剂。大约一年半前，Ann Noles 与该公司的四个员工非常着迷于知识管理，公司允许他们参加各种会议，花时间编制知识管理案例，最后，Ann Noles被授予“知识管理先锋”一职，她全力投入，并通过会议，备忘录等形式以鼓励公司的员工共享知识。今年7月，她还成立了一个从事知识共享项目开展的小组。第一步，她组织了知识共享项目的问卷调查，以用来评估目前知识共享的状况。接着，她鼓励小组成立各种主题团队，如客户发展，风险分析团队。加入这些团队的员工通过日常会议和电子邮件列组等形式进行交流。今年秋季要进行的第二次问卷调查将对这种分组方式对于知识共享的过程改进进行评估。 她还与人力资源部合作发展知识共享的培训计划。虽然现在还不知道这些努力是否会成功，但她将始终致力于知识共享的促进，这一点就足够推动其他人也向这个方向努力。 来源:登龙门人力资源网络 用JIRA、CVS、XPlanner、WIKI来进行软件开发项目管理（转）JIRA，一个非常出色的Issue跟踪系统，这里的Issue不单单是指BUG， 很多时候也可以是TASK， IMPROVEMENT， NEW FEATURE， 甚至是一个QUESTION。在多年前， 我曾经尝试使用过那个经典的的Bugzilla，但是一个项目作下来，大家都反映那个东西的界面实在是太粗糙，简直无法忍受而且报表功能也是在太弱。最后大家就讨论自己作一个BUG的跟踪系统，就在大家已经完成了设计文档准备编码的时候， 我们发现JIRA原来就是我们要找的东西，而且比我们要的更多。 它内置一个可以配置的工作流引擎(osworkflow)，一个快捷的全文检索功能(基予Apache Lucene).和一个可以配置的Dashboard(portlet)， 以及一个和CVS连接的引擎，通过这个连接，在一个Issue中直接可以看到修改的文件名称，如果配置了viewcvs的话，还直接直接定位到行， 根据一个问题可以跟踪到代码的行，这正式我们梦寐一求的功能。 也正是这种特性，才使我们能够把一个个Issue当作发布和版本管理的一个单元。 基于ISSUE的发布管理 从版本管理的角度来考虑， 最理想的发布方法就是把CVS中的代码拿下来， 打上一个tag， 编译并且测试一直到发布。这样的管理方式的确是很简单的， 但事实上用户可不买帐的， 用户觉得在新的版本中某个新的功能他还不想要，这可能是他还没有整理好业务初始数据或者在实际的业务流程上或人员上没有做好准备， 上帝说了不要咱就不能把这个新功能发布。在这个情况下，基于Issue的发布管理是一个好的方案。 1）防止一些没有经验的程序员无意义的提交， 比如一个小子今天提交了一个java文件，明天发现这个变量命名有点不爽，修改后就要提交， 在这种情况下， 这个提交是没有意义的，如果测试组已经测试这个Issue， 是否测试组要重新测试？为一个变量名称化这样的时间和冒险是可嫩的。 小伙子还是在第一次提交的时候就把变量名想好了再提交。 六种全面质量管理工具(还是转哦)随着质量运动的迅速铺开，许多人耗费大量时间和精力在自己的企业内实施质量管理。可是，他们经常失望地发现，他们很难知道哪种质量工具和技术最适合哪些具体场合。 以下介绍几种质量工具及如何运 用它们解决日常业务问题。每种工具的讨论都包括下列内容：何时用、何时不用、培训、能达到何目的、注意事项和使用程式。 一、鱼缸会议 这是一种组织会议的方式。不同的群体本着合作的精神，一起分享各自的观点和资讯。因此，让销售部门与客户服务部、或高层管理人员与管理顾问碰头，这种做法一定管用。 何时用：鱼缸会议使某些群体与顾客、供应商和经理等其他与之利益攸关的群体加强沟通。 何时不用：如果用这种方法不能明确地分清各群体的职责，就不宜使用。 培训：会议召集人需要接受培训。 能达到何目的：迅速增进了解、扫除误解。 注意事项：这类会议影响巨大。可能会暴露实情，使内情人和旁观者感到受威胁，因此需要精心组织。 使用程式：把与会者安排成内外两圈。内圈人员会上比较活跃，外圈人员则从旁观察、倾听，必要时提供资讯。会议结束时推荐改进方案，取得外圈人员的赞同。 二、横向思维 这是一种爲老问题寻找新解决方案的工具。 何时用：由於老方法、旧思路不再管用或已经不够好，需要寻找新方法、新思路时使用。 何时不用：种种制约使这种全新的思维方式无法发挥作用时不要用。 培训：建议读Edward de Bono（爱德华）写的Lateral Thinking for Management（管理中的横向思维）一书。 能达到何目标：开创新思路，激发创意，找出可行的解决方案。 注意事项： 需要传统的逻辑思维加以支援。爱德华建议，只有10%的解决问题过程采用横向思维。 使用程式：确定问题。运用幽默、随机排列和对流行观念的挑战来制定横向思维解决方案。对找到的各种想法加以适当的提炼和取舍。 举例来说，某工业缝纫线轴制造商的传统市场已经消失，公司不得不另寻出路。对此，公司经理们的本能反应是，从常规思路出发，爲産品找新的出路、新的市场或新的销售手段。不过，事态的发展很快表明，他们需要一种彻底的解决方案。 公司召开了一次集思广益会，对叁加者不加任何框框。思路应能用得上现有的技能和经验，但只能把它作爲起点。结果，横向思维把他们引向高尔夫球，成爲一家成功的高尔夫球制造商。 三、帕雷托分析法（Pareto Analysis） 该方法强调爲80%的问题找出关键的几个致因（通常爲20%）。 何时用：凡是一个问题的産生有多个变数因素并需要找出其中最关键的因素时，都可使用这一方法。在一个改进专案的开始阶段尤爲有用。 何时不用：如果设置有更完善的系统就没有必要使用此法。 培训：需具备基本的统计知识以备分析之用。 能达到何目标：非常直观地展示出如何确定问题的优先顺序，将资源集中在何处才能取得最佳效益。这种展示让企业各级一看就懂。 注意事项：仔细分析结果总是很重要；不仅靠资料还要利用常识来找出问题的原因和优先顺序。 使用程式：找出问题和可能的原因。收集有关原因的资讯。绘制帕雷托分析图，横坐标表示原因，纵坐标表示问题，以出现次数、频率或造成的成本来表示。找出最关键的几个原因。依据重要性排序，利用改进技术消除産生问题的原因。 例如，某洗衣机制造商出现质量危机。在一次广泛的可信度测试中，一家大型杂志将其産品排在末位元并建议消费者不要购买。 该公司具有完善的失误记录，列出的失误种类达22种。但运用帕雷托分析法表明，仅其中的4种失误就占了所有记录的83%。 四、质量功能分布图（QFD） 这是一种産品和流程设计工具，可以用於把顾客的呼声转化成産品或流程的特点。采用该方法能防止企业仅因爲某些观念似乎有效就予以实施。 何时使用：用以设计或重新设计産品或流程，保证提供顾客切实需要的産品特性；专爲制造业设计的，但也可用於服务业。 何时不用：如果问题的优先顺序已经分明、流程设计卓有成效或设计团队经验老到，不要采用该方法。 培训：该方法运用特定的惯例，建立相关的榘阵图和计分标准。在这方面有必要进行培训。 能达到何目标：有能力分辨基本的産品与流程特色和所期望的産品与流程特色，这样便可以看清高成本的技术或工程投资在哪方面将有回报。同时，还提供了一个评估産品或流程变化影响的框架准则。 注意事项：花时间通过市场调研来找出顾客的真正需求所在。 使用程式：研究顾客的需求。找出符合顾客需求的流程设计特色。建立一个榘阵图，将顾客的需求与设计特色进行比较（即性能／方案榘阵图）并加以计分。选取5 个左右分数最高的设计特色，然後再按3个层次建立榘阵图：设计特色和关键部件特点、关键部件特点和制造工序、制造工序和生産要求。 例如，某割草机制造商耗时费资重新设计其畅销割草机的控制性能，却发现顾客对此毫无反应。因此，公司经理人在计划改进另一较老型号时，想要确保所做的改善的确是顾客想要的。 研究结果表明，顾客感兴趣的是性能。因此改善马达、驱动链和刀的效率比改善控制性能可以産生大得多的影响。 五、关联树图 这种图示工具对关联项进行层次分类。这是一种不错的思维工具，因爲它提供了一种快捷的方法把各种想法总括出来，并在相关的枝叉出现时可随即增加细节。 何时使用：使用该图示可以爲同一目标寻求多种不同的实现途径。 何时不用：不可用於详细比较各种方案。它只用於从总体上探索新的方向。 培训：无需正式培训，但设置一个协调人员会很有帮助。 能达到何目标：该图示能很有逻辑地揭示出该采用什麽方法来实现目标，它们要求哪些行动和资源。 注意事项：如果你选用的方法经不起分析，要随时准备回到关联树图上来。 比如，一个发展中的小公司运用这种方法来考虑员工的托儿问题。许多员工大学一毕业就加入了公司，现在都供养着子女。 公司开会讨论各种选择方案。结果，大家都赞成建一个日托中心。但树形图显示，潜在的成本太高，需要满足的地方法规要求太多，很难实行。於是公司选择了托儿津贴计划，让有子女的员工有选择的馀地。 六、方案效果分析法（solution effect analysis） 这种图表用於分析手头解决方案可能産生的效果。 何时用：在提议变革时可运用这种方法。它能让你看清各解决方案的效果。 何时不用：你所提议的不是根本性变革的话，不要使用。 培训：无需正式培训，但如加以辅助很有用。 能达到何目标：一种向前看的思维方式并能预见所建议的方案会造成什麽影响，避免未能预见的效果。 注意事项：人们对你正在致力的变革前景看淡时，不要阻止他们。他们并非有意发难，也许他们是对的。接受辅导会减少自己受威胁的感觉。 使用程式：记下正在考虑实施的解决方案，放在图的左侧，箭头则指向右方。在主箭头两侧用分箭头标出各种重大效果。通过集思广益，找出所有可能的效果并添到图上。计划实施行动以确保该方案行之有效。 有人说有关项目管理（转）看到有人说有关项目管理，在软件行业拼杀了8年多了，自认为自己这方面还是有些成就的，不管三七二十一，收了再说
 －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
引言： 在论坛上经常看到很多人有关项目管理的经验，而且都是长篇大论，侃侃而谈；总是看得我晕头转向，总感觉，都是停留在人的作用上，总是强调管理中的人为因素，几乎很多条目都是带有很强的人为色彩，看完后，总是觉得这些经验很不错，但是自己往往却很难在自己的项目中具体实施。 想法： 本人是一个实践主义者  ，自己在项目管理中，总是尝试抛开人为因素的困扰，利用一些简单通用的工具来协助项目管理，通过这些工具的运用，让它们自动来推动项目管理的进程，减少人为因素的问题，形成一条无形的推动项目进程的生产链条。 核心链条： 源代码管理工具 => Bug追踪工具 => 每日编译工具 WinCVS/CVSNT => Bugzilla => BAT和Perl脚本 下面是这些核心工具的运用经验： 1. 必须建立源代码的版本控制系统，就是cvs，基本的代码提交原则： 1) 程序员尽量每天只在下班前提交一次; 2) 提交的代码必须是在自己的机器上是正常运行的； 3) 每次提交都必须用简短的话说明自己提交代码的功能描述。 2. 建立错误追踪系统，用Bugzilla就很好，配置好邮件系统，使Bugzilla成为测试人员与开发人员沟通的桥梁。 3. 用BAT和Perl脚本，以cvs中的源代码为核心实现简单的每日编译工具，将这个自己写的自动化工具放到一台专门的编译机器上，在每天的半夜开始自动下载代码，自动编译代码，自动打包安装程序，自动记录各种编译日志，自动将安装程序放置到一个固定的以日期为目录名的公共区。（用cvs2cl.pl得到程序员上传的代码更新日志，以便测试人员参考） 4. 测试人员的第二天，应该到公共区取得头天的最新版本，并根据ChangeLog进行新版本的测试。并将测试中发现的Bug，通过Bugzilla反馈给程序员。程序员可以根据自己的情况，或公司的规定来决定修改这些Bug的时间。并将这些Bug的修改情况，在代码提交时，写入代码日志。 5. 开发人员的第二天，应该到公共区查看编译日志，看看自己的模块是否正常编译，及时更正，看看自己的邮箱有没有Bug报告，及时修改。 6. 管理人员的第二天，在综合项目需求与头天版本进度的上，可以判断产品的发展方向，如果有偏航或理解错误或有新需求时，可以根据当前情况及时调整。 这样，通过 cvs => bugzilla => daily-build，就能将程序员与测试员，进行互动，各施其责。减少沟通与人为的麻烦。对于管理层，也能做到心中有数：因为每天都有新版本，随时掌握产品的走向。。。等等。 另：有关项目管理中与客户、与公司上层、成本、进度等等，这里没有具体谈，但如果切实运用以上经验，会在一定程度上简化这些关系的复杂度，使得各个环节变得相对简单。 项目管理工具在国内应用还真的很少哦！ MVM对“如何用正确的方法来写出质量好的软件的75条体会”的回答及我跟在MVM后的回答系统了就好多了！！ MVM曾经发了篇题为《如何用正确的方法来写出质量好的软件的75条体会》的blog，后来他又给出了相应的回答：《七十五条》的解释 。而我亦给出了我自己的答案，有些不错，有些差强人意，有些则非常不足了。为便于比较，我的答案附在了MVM答案的后面。 1. 你们的项目组使用源代码管理工具了么？ MVM : 应该用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的选择是VSS。 郁也风 : 公司使用的是VSS，在网上与朋友玩的就是CVS了。 2. 你们的项目组使用缺陷管理系统了么？ MVM : 应该用。ClearQuest太复杂，我的推荐是BugZilla。 郁也风 : 嫌BugZilla安装太费事，界面太简陋，我选择的是Jira。 3. 你们的测试组还在用Word写测试用例么？ MVM : 不要用Word写测试用例（Test Case）。应该用一个专门的系统，可以是Test Manager，也可以是自己开发一个ASP.NET的小网站。主要目的是Track和Browse。 郁也风 : 用Word，而且测试工作很是不上台面（中国软件的通病，所以我们公司也没少得了犯）。 4. 你们的项目组有没有建立一个门户网站？ MVM : 要有一个门户网站，用来放Contact Info、Baselined Schedule、News等等。推荐Sharepoint Portal Server 2003来实现，15分钟就搞定。买不起SPS 2003可以用WSS (Windows Sharepoint Service)。 郁也风 : 没有，不过看你这么介绍，回头试试去。 注: 可以用Confluence 搭建一个wiki平台. 5. 你们的项目组用了你能买到最好的工具么？ MVM : 应该用尽量好的工具来工作。比如，应该用VS.NET而不是Notepad来写C#。用Notepad写程序多半只是一种炫耀。但也要考虑到经费，所以说是“你能买到最好的”。 郁也风 : 我一向认为所谓的Notepad开发是自虐狂的不良嗜好。我们使用Eclipse，不要钱的，但我认为是java开发最好的工具了。 6. 你们的程序员工作在安静的环境里么？ MVM : 需要安静环境。这点极端重要，而且要保证每个人的空间大于一定面积。 郁也风 : 看来这位兄台是看过人件了，可惜我们公司的办公环境只能说是一般，极为一般。 7. 你们的员工每个人都有一部电话么？ MVM : 需要每人一部电话。而且电话最好是带留言功能的。当然，上这么一套带留言电话系统开销不小。不过至少每人一部电话要有，千万别搞得经常有人站起来喊：“某某某电话”。《人件》里面就强烈谴责这种做法。 郁也风 : 你果然看了人件了，但请认清形式吧，那是美国，这是中国，“中国国情”四个字会噎死你的，现在的实际情况是很多公司都不让用QQ，MSN（肯定包括我们公司了）。 8. 你们每个人都知道出了问题应该找谁么？ MVM : 应该知道。任何一个Feature至少都应该有一个Owner，当然，Owner可以继续Dispatch给其他人。 郁也风 : 我们知道去找谁，但这不代表就能解决问题。 9. 你遇到过有人说“我以为…”么？ MVM : 要消灭“我以为”。Never assume anything。 郁也风 : 我也经常说“我认为”，尤其在我验证之前。当然，我会考虑改正。 10. 你们的项目组中所有的人都坐在一起么？ MVM : 需要。我反对Virtual Team，也反对Dev在美国、Test在中国这种开发方式。能坐在一起就最好坐在一起，好处多得不得了。 郁也风 : 需要，很多问题不是面对面的话，还真无法解决，或是有时候面对面更能开拓思路，也能更好地交互。 11. 你们的进度表是否反映最新开发进展情况？ MVM : 应该反映。但是，应该用Baseline的方法来管理进度表：维护一份稳定的Schedule，再维护一份最新更改。Baseline的方法也应该用于其它的Spec。Baseline是变更管理里面的一个重要手段。 郁也风 : 这是我一直很头疼的问题，如何维护一个有效的进度表不亚于任何一个模块的开发啊。 12. 你们的工作量是先由每个人自己估算的么？ MVM : 应该让每个人自己估算。要从下而上估算工作量，而不是从上往下分派。除非有其他原因，比如政治任务工期固定等。 郁也风 : 可惜我们的任务多是政治任务，工期固定的就像螺丝钉。 13. 你们的开发人员从项目一开始就加班么？ MVM : 不要这样。不要一开始就搞疲劳战。从项目一开始就加班，只能说明项目进度不合理。当然，一些对日软件外包必须天天加班，那属于剥削的范畴。 郁也风 : 我们加班是很多是因为资源的到位晚导致的，无可奈何。谁都知道问题的所在，谁都找不到解决问题的方法。 14. 你们的项目计划中Buffer Time是加在每个小任务后面的么？ MVM : 不要。Buffer Time加在每个小任务后面，很容易轻易的就被消耗掉。Buffer Time要整段的加在一个Milestone或者checkpoint前面。 郁也风 : 我们尽量这么做了。 15. 值得再多花一些时间，从95%做到100%好 MVM : 值得，非常值得。尤其当项目后期人困马乏的时候，要坚持。这会给产品带来质的区别。 郁也风 : 我们多是在客户的逼迫下完成那最后的5%的。而且100%并不代表Over，而是另一个100%的开始，成就了一个完美的恶性循环。 16. 登记新缺陷时，是否写清了重现步骤？ MVM : 要。这属于Dev和Test之间的沟通手段。面对面沟通需要，详细填写Repro Steps也需要。 郁也风 : 绝对要，理由同上。 17. 写新代码前会把已知缺陷解决么？ MVM : 要。每个人的缺陷不能超过10个或15个，否则必须先解决老的bug才能继续写新代码。 郁也风 : 没别的说的，一定要。 18. 你们对缺陷的轻重缓急有事先的约定么？ MVM : 必须有定义。Severity要分1、2、3，约定好：蓝屏和Data Lost算Sev 1，Function Error算Sev 2，界面上的算Sev 3。但这种约定可以根据产品质量现状适当进行调整。 郁也风 : 知道需要，但是做的相当不够，需要努力改进。 19. 你们对意见不一的缺陷有三国会议么？ MVM : 必须要有。要有一个明确的决策过程。这类似于CCB (Change Control Board)的概念。 郁也风 : 要由最后拍板的。而且不能陷入争论的泥淖。 20. 所有的缺陷都是由登记的人最后关闭的么？ MVM : Bug应该由Opener关闭。Dev不能私自关闭Bug。 郁也风 : 同意。 21. 你们的程序员厌恶修改老的代码么？ MVM : 厌恶是正常的。解决方法是组织Code Review，单独留出时间来。XP也是一个方法。 郁也风 : Code Review？我们老板不喜欢。 22. 你们项目组有Team Morale Activity么？ MVM : 每个月都要搞一次，吃饭、唱歌、Outing、打球、开卡丁车等等，一定要有。不要剩这些钱。 郁也风 : 这点绝对不会少的，至少我带过的团队的凝聚力还是不错的。 23. 你们项目组有自己的Logo么？ MVM : 要有自己的Logo。至少应该有自己的Codename。 郁也风 : 没想过，今天头要搞个我们部门的文化衫，我强烈反对了。不过Logo可以考虑。 24. 你们的员工有印有公司Logo的T-Shirt么？ MVM : 要有。能增强归属感。当然，T-Shirt要做的好看一些，最好用80支的棉来做。别没穿几次就破破烂烂的。 郁也风 : 哦，前一个我说了，我反对了。我不喜欢千人一面的感觉。 25. 总经理至少每月参加次项目组会议 MVM : 要的。要让team member觉得高层关注这个项目。 郁也风 : 好像是个不可能完成的任务。不知别的公司如何。 26. 你们是给每个Dev开一个分支么？ MVM : 反对。Branch的管理以及Merge的工作量太大，而且容易出错。 郁也风 : 反对，管理困难，也没有必要，可以加Lable。 27. 有人长期不Check-In代码么？ MVM : 不可以。对大部分项目来说，最多两三天就应该Check-In。 郁也风 : 不可以，我每天都监控VSS的。 28. 在Check-In代码时都填写注释了么？ MVM : 要写的，至少一两句话，比如“解决了Bug No.225”。如果往高处拔，这也算做“配置审计”的一部分。 郁也风 : 要写！ 29. 有没有设定每天Check-In的最后期限？ MVM : 要的，要明确Check-In Deadline。否则会Build Break。 郁也风 : 没有，整合就是个明确的Deadline了。 30. 你们能把所有源码一下子编译成安装文件吗？ MVM : 要的。这是每日编译（Daily Build）的基础。而且必须要能够做成自动的。 郁也风 : 当然，我不喜欢出现源码和类文件不匹配。 31. 你们的项目组做每日编译么？ MVM : 当然要做。有三样东西是软件项目/产品开发必备的：1. bug management; 2. source control; 3. daily build。 郁也风 : 至少项目负责人要做。 32. 你们公司有没有积累一个项目风险列表？ MVM : 要。Risk Inventory。否则，下个项目开始的时候，又只能拍脑袋分析Risk了。 郁也风 : 没有。也是一个需要考虑的内容。 33. 设计越简单越好 MVM : 越简单越好。设计时候多一句话，将来可能就带来无穷无尽的烦恼。应该从一开始就勇敢的砍。这叫scope management。 郁也风 : 不同意，过度简单就成了简陋了。而且什么样的叫简单？没有一个量的界定。设计是需要让别人看明白的。 34. 尽量利用现有的产品、技术、代码 MVM : 千万别什么东西都自己Coding。BizTalk和Sharepoint就是最好的例子，有这两个作为基础，可以把起点提高很多。或者可以尽量多用现成的Control之类的。或者尽量用XML，而不是自己去Parse一个文本文件；尽量用RegExp，而不是自己从头操作字符串，等等等等。这就是“软件复用”的体现。 郁也风 : 同意，我的原则是：有稳定的，经过实践验证的开源组件或产品的话，绝对不再自己搭炉灶。 35. 你们会隔一段时间就停下来夯实代码么？ MVM : 要。最好一个月左右一次。传言去年年初Windows组在Stevb的命令下停过一个月增强安全。Btw，“夯”这个字念“hang”，第一声。 郁也风 : 肯定做了，不过可能并不是有意识地去做的。 36. 你们的项目组每个人都写Daily Report么？ MVM : 要写。五分钟就够了，写10句话左右，告诉自己小组的人今天我干了什么。一则为了沟通，二则鞭策自己（要是游手好闲一天，自己都会不好意思写的）。 郁也风 : 这是公司的规定。也是少有的能让我支持的规定。 37. 你们的项目经理会发出Weekly Report么？ MVM : 要。也是为了沟通。内容包括目前进度，可能的风险，质量状况，各种工作的进展等。 郁也风 : 也是公司的规定。 38. 你们项目组是否至少每周全体开会一次？ MVM : 要。一定要开会。程序员讨厌开会，但每个礼拜开会时间加起来至少应该有4小时。包括team meeting, spec review meeting, bug triage meeting。千万别大家闷头写code。 郁也风 : 要，至少这点我们实施的还可以。 39. 你们项目组的会议、讨论都有记录么？ MVM : 会前发meeting request和agenda，会中有人负责主持和记录，会后有人负责发meeting minutes，这都是effective meeting的要点。而且，每个会议都要形成agreements和action items。 郁也风 : 有记录，最后要形成会议纪要的。 40. 其他部门知道你们项目组在干什么么？ MVM : 要发一些Newsflash给整个大组织。Show your team’s value。否则，当你坐在电梯里面，其他部门的人问：“你们在干嘛”，你回答“ABC项目”的时候，别人全然不知，那种感觉不太好。 郁也风 : 我们公司的项目开始时要求所有的技术骨干坐在一起评审的，别人想不知道都难。 41. 通过Email进行所有正式沟通 MVM : Email的好处是免得抵赖。但也要避免矫枉过正，最好的方法是先用电话和当面说，然后Email来确认。 郁也风 : 很少使用Email，更多是当面解决问题，毕竟都在一个办公室。 42. 为项目组建立多个Mailing Group MVM : 如果在AD+Exchange里面，就建Distribution List。比如，我会建ABC Project Core Team，ABC Project Dev Team，ABC Project All Testers，ABC Project Extended Team等等。这样发起Email来方便，而且能让该收到email的人都收到、不该收到不被骚扰。 郁也风 : 没有这个条件，这个更应该根据项目组的规模来进行吧。 43. 每个人都知道哪里可以找到全部的文档么？ MVM : 应该每个人都知道。这叫做知识管理（Knowledge Management）。最方便的就是把文档放在一个集中的File Share，更好的方法是用Sharepoint。 郁也风 : 所有需要的开发文档都放在一个统一的地方，这是规定。 44. 你做决定、做变化时，告诉大家原因了么？ MVM : 要告诉大家原因。Empower team member的手段之一是提供足够的information，这是MSF一开篇的几个原则之一。的确如此，tell me why是人之常情，tell me why了才能有understanding。中国人做事喜欢搞限制，限制信息，似乎能够看到某一份文件的人就是有身份的人。大错特错。权威、权力，不在于是不是能access information/data，而在于是不是掌握资源。 郁也风 : 对我们来说，需做变化时，也就是临时会议的需要进行的时候。 45. Stay agile and expect change MVM : 要这样。需求一定会变的，已经写好的代码一定会被要求修改的。做好心理准备，对change不要抗拒，而是expect change。 郁也风 : 这点只能说谈何容易。希望能做到吧。 46. 你们有没有专职的软件测试人员？ MVM : 要有专职测试。如果人手不够，可以peer test，交换了测试。千万别自己测试自己的。 郁也风 : 我们都知道需要，可是往往实际情况差强人意。 47. 你们的测试有一份总的计划来规定做什么和怎么做么？ MVM : 这就是Test Plan。要不要做性能测试？要不要做Usability测试？什么时候开始测试性能？测试通过的标准是什么？用什么手段，自动的还是手动的？这些问题需要用Test Plan来回答。 郁也风 : 知道需要，可实际情况同46。 48. 你是先写Test Case然后再测试的么？ MVM : 应该如此。应该先设计再编程、先test case再测试。当然，事情是灵活的。我有时候在做第一遍测试的同时补上test case。至于先test case再开发，我不喜欢，因为不习惯，太麻烦，至于别人推荐，那试试看也无妨。 郁也风 : 至少目前的习惯和你类似，将来打算试试TDD。 49. 你是否会为各种输入组合创建测试用例？ MVM : 不要，不要搞边界条件组合。当心组合爆炸。有很多test case工具能够自动生成各种边界条件的组合——但要想清楚，你是否有时间去运行那么多test case。 郁也风 : 不会，没那个精力先。 50. 你们的程序员能看到测试用例么？ MVM : 要。让Dev看到Test Case吧。我们都是为了同一个目的走到一起来的：提高质量。 郁也风 : 当然能够，项目中所有的东西都是对大家透明的。 51. 你们是否随便抓一些人来做易用性测试？ MVM : 要这么做。自己看自己写的程序界面，怎么看都是顺眼的。这叫做审美疲劳——臭的看久了也就不臭了，不方便的永久了也就习惯了。 郁也风 : 我是非常推荐这样的测试的，很多时候，客户也会参与进来。 52. 你对自动测试的期望正确么？ MVM : 别期望太高。依我看，除了性能测试以外，还是暂时先忘掉“自动测试”吧，忘掉WinRunner和LoadRunner吧。对于国内的软件测试的现状来说，只能“矫枉必须过正”了。 郁也风 : 从不期望。 53. 你们的性能测试是等所有功能都开发完才做的么？ MVM : 不能这样。性能测试不能被归到所谓的“系统测试”阶段。早测早改正，早死早升天。 郁也风 : 同意，非常同意。 54. 你注意到测试中的杀虫剂效应了么？ MVM : 虫子有抗药性，Bug也有。发现的新Bug越来越少是正常的。这时候，最好大家交换一下测试的area，或者用用看其他工具和手法，就又会发现一些新bug了。 郁也风 : 同意。 55. 你们项目组中有人能说出产品的当前整体质量情况么？ MVM : 要有。当老板问起这个产品目前质量如何，Test Lead/Manager应该负责回答。 郁也风 : 这当然是TL/PM的活了。 56. 你们有单元测试么？ MVM : 单元测试要有的。不过没有单元测试也不是不可以，我做过没有单元测试的项目，也做成功了——可能是侥幸，可能是大家都是熟手的关系。还是那句话，软件工程是非常实践、非常工程、非常灵活的一套方法，某些方法在某些情况下会比另一些方法好，反之亦然。 郁也风 : 我同意，虽然我们做的很不好。 57. 你们的程序员是写完代码就扔过墙的么？ MVM : 大忌。写好一块程序以后，即便不做单元测试，也应该自己先跑一跑。虽然有了专门的测试人员，做开发的人也不可以一点测试都不做。微软还有Test Release Document的说法，程序太烂的话，测试有权踢回去。 郁也风 : 这样的选手是要挨骂的。 58. 你们的程序中所有的函数都有输入检查么？ MVM : 不要。虽然说做输入检查是write secure code的要点，但不要做太多的输入检查，有些内部函数之间的参数传递就不必检查输入了，省点功夫。同样的道理，未必要给所有的函数都写注释。写一部分主要的就够了。 郁也风 : 更多的时候是在最外面进行检查。太多的检查没有意义。 59. 产品有统一的错误处理机制和报错界面么？ MVM : 要有。最好能有统一的error message，然后每个error message都带一个error number。这样，用户可以自己根据error number到user manual里面去看看错误的具体描述和可能原因，就像SQL Server的错误那样。同样，ASP.NET也要有统一的Exception处理。可以参考有关的Application Block。 郁也风 : 有，这也是j2ee 的规范了。 60. 你们有统一的代码书写规范么？ MVM : 要有。Code Convention很多，搞一份来发给大家就可以了。当然，要是有FxCop这种工具来检查代码就更好了。 郁也风 : 有，首先是IDE的format工具，然后是Checkstyle之类的检查工具在每天的day build之前使用。 61. 你们的每个人都了解项目的商业意义么？ MVM : 要。这是Vision的意思。别把项目只当成工作。有时候要想着自己是在为中国某某行业的信息化作先驱者，或者时不时的告诉team member，这个项目能够为某某某国家部门每年节省多少多少百万的纳税人的钱，这样就有动力了。平凡的事情也是可以有个崇高的目标的。 郁也风 : 刚才说了，我们的项目的每个部分对每个人都是透明的。 62. 产品各部分的界面和操作习惯一致么？ MVM : 要这样。要让用户觉得整个程序好像是一个人写出来的那样。 郁也风 : 需要，这也是规范的一部分。 63. 有可以作为宣传亮点的Cool Feature么？ MVM : 要。这是增强团队凝聚力、信心的。而且，“一俊遮百丑”，有亮点就可以掩盖一些问题。这样，对于客户来说，会感觉产品从质量角度来说还是acceptable的。或者说，cool feature或者说亮点可以作为质量问题的一个事后弥补措施。 郁也风 : 同意，我前一个项目的界面风格，被客户定为其它项目的参考标准了^_^。 64. 尽可能缩短产品的启动时间 MVM : 要这样。软件启动时间（Start-Up time）是客户对性能好坏的第一印象。 郁也风 : 需要，另外一方面，等待对我们开发方也是一种折磨。 65. 不要过于注重内在品质而忽视了第一眼的外在印象 MVM : 程序员容易犯这个错误：太看重性能、稳定性、存储效率，但忽视了外在感受。而高层经理、客户正相反。这两方面要兼顾，协调这些是PM的工作。 郁也风 : 这也是我在最近的项目中转变最大的方面。 66. 你们根据详细产品功能说明书做开发么？ MVM : 要这样。要有设计才能开发，这是必须的。设计文档，应该说清楚这个产品会怎么运行，应该采取一些讲故事的方法。设计的时候千万别钻细节，别钻到数据库、代码等具体实现里面去，那些是后面的事情，一步步来不能着急。 郁也风 : 我更喜欢迭代，你的设计是根据需求，而需求是来自客户，而客户。。。永远不变的是变化。 67. 开始开发和测试之前每个人都仔细审阅功能设计么？ MVM : 要做。Function Spec review是用来统一思想的。而且，review过以后形成了一致意见，将来再也没有人可以说“你看，当初我就是反对这么设计的，现在吃苦头了吧” 郁也风 : 要做，而且要求每个人都提出意见，这是开发工作开始之前，开始之后，我更倾向于“一言堂”了。 68. 所有人都始终想着The Whole Image么？ MVM : 要这样。项目里面每个人虽然都只是在制造一片叶子，但每个人都应该知道自己在制造的那片叶子所在的树是怎么样子的。我反对软件蓝领，反对过分的把软件制造看成流水线、车间。参见第61条。 郁也风 : 我也同样反对“软件蓝领”，一向唾弃这个学院派制造的名词。我们采取的方式也同样可以参加61。 69. Dev工作的划分是单纯纵向或横向的么？ MVM : 不能单纯的根据功能模块分，或者单纯根据表现层、中间层、数据库层分。我推荐这么做：首先根据功能模块分，然后每个“层”都有一个Owner来Review所有人的设计和代码，保证consistency。 郁也风 : 同意。 70. 你们的程序员写程序设计说明文档么？ MVM : 要。不过我听说微软的程序员1999年以前也不写。所以说，写不写也不是绝对的，偷懒有时候也是可以的。参见第56条。 郁也风 : 做的不够，我们从来没写过。 71. 你在招人面试时让他写一段程序么？ MVM : 要的。我最喜欢让人做字符串和链表一类的题目。这种题目有很多循环、判断、指针、递归等，既不偏向过于考算法，也不偏向过于考特定的API。 郁也风 : 我认为交流更能看出一个人的实际情况。 72. 你们有没有技术交流讲座？ MVM : 要的。每一两个礼拜搞一次内部的Tech Talk或者Chalk Talk吧。让组员之间分享技术心得，这笔花钱送到外面去培训划算。 郁也风 : 同意，也在着手准备启动。 73. 你们的程序员都能专注于一件事情么？ MVM : 要让程序员专注一件事。例如说，一个部门有两个项目和10个人，一种方法是让10个人同时参加两个项目，每个项目上每个人都花50%时间；另一种方法是5 个人去项目A，5个人去项目B，每个人都100%在某一个项目上。我一定选后面一种。这个道理很多人都懂，但很多领导实践起来就把属下当成可以任意拆分的资源了。 郁也风 : 我也懂，可实际情况是，现在有4个项目和我有关联。 74. 你们的程序员会夸大完成某项工作所需要的时间么？ MVM : 会的，这是常见的，尤其会在项目后期夸大做某个change所需要的时间，以次来抵制change。解决的方法是坐下来慢慢磨，磨掉程序员的逆反心理，一起分析，并把估算时间的颗粒度变小。 郁也风 : 会的，就算我在上报工作量的时候也会夸大的。对下，我采取的措施同你；上面对我，采取的措施是打折。 75. 尽量不要用Virtual Heads MVM : 最好不要用Virtual Heads。Virtual heads意味着resource is not secure，shared resource会降低resource的工作效率，容易增加出错的机会，会让一心二用的人没有太多时间去review spec、review design。一个dedicated的人，要强过两个只能投入50%时间和精力的人。我是吃过亏的：7个part time的tester，发现的Bug和干的活，加起来还不如两个full-time的。参见第73条。73条是针对程序员的，75条是针对 Resource Manager的。 郁也风 : 我想说的同73。 新项目又要开始了可能要开始新项目了，研究了好几年的工作流，今天终于要实际用上了！！
另外，现在这个公司的以往的项目存在如下问题：
1 技术上比较古老－－一直在沿用struts的模式，没有任何其他先进技术加入，在我来了之后，才逐渐融入ajax和xfire部分；
2 开发管理方式需要彻底整合一下－－之前没有什么东西，现在我来了之后，增加了版本控制，bugzilla控制，项目进度控制等等；
目前的方式虽然还可以，但还不够完美，主要是为了迁就之前的项目，这次有机会重构一下技术和团队管理方式，很好！
最终我们要达到的目标是：技术架构专业，管理专业，项目质量一流，项目效率一流！
初步方案：
技术上：
1 采用流行的表现层架构（市场的原因选择知道人最多的架构struts吧，不过是2）＋spring＋hibernate；
2 采用比较好的成熟的应用级别框架支持，如appfuse或者springside，但是springside没用过，并且很久没有更新了，不知道是不是半途而废了呢？appfuse等struts2呢，用过，效率不错，完整的crud不用1分钟就完成，并且涉及到应用各个部分都很全面，值得应用；
3 bug管理暂时倾向于jira，不知道试用版是否有过期问题，好好看看；再辅助上xplanner来支持敏捷开发；
4 开发工具采用eclipse＋codepro
5 测试暂时定为junit和selenium
6 持续集成？正在考虑中，如果可以也来吧－－毕竟会提高效率和质量啊
管理上：
1 版本控制依旧使用subversion吧
2 找个xwiki来把我们的知识管理起来，实现长远发展！ 3/28/2007 想用英语写日志 很早就想用英语写日志了，只是只要一写，就发现自己的知识点太匮乏了，还是每天一句吧，要想每天一段真的很难啊！
要是每天写一段，那还不知道错成什么样子呢？！关键是错了自己还不知道，就这样错下去了！
记得我弟弟刚上中学的时候，我和他说，学写俄语字母的时候，你一定要认真，你第一个字母写成什么样子，基本上，你这一辈子就写成什么样子了，差别无非在于熟练和流畅，基本模样就定型了－－我猜这可能是我这前30年说的最成功的一句话了！
呵呵，结果我的弟弟汉子写的实在很大众，可俄语却写得很漂亮，在学校的俄语书法比赛中每每获奖，有趣吧！！
所以呢，定型很重要！再学个把月再想写的问题吧，一步一步来－－想想现在的我，比上学的时候踏实实际多了，这就是成长吧！ 学外语 不用问，一定有千万人不断下决心要学外语了，终于反反复复，一事无成，总是对前几页比较熟悉，然后就扔在一边了。
这样的日子终究是要有个尽头，外语终究是要掌握的，没什么可能自己最终是可以不会外语的。所以，在2006年年初，开始学外语了，心态上比较上心了。
也许这过程中不是那么得努力，至少我没有把它扔掉，昨天的誓言变成一句空话，至少我断断续续坚持着，平均下来花的时间不多，但至少没停下来，也算是庆幸！呵呵！
结果是什么？结果就是听美语的时候感觉没有那么乱了，感觉句子单词短语什么的有个数了，在以往的日子里，听美语简直就是一点条理都听不出来，除了超级简单的几个单词。
也不是非要学美语，只是不学美语，实在是很难听懂他们说话，不错，外语如果达到一定境界了，当然可以听懂美语了。但这境界如何达到呢？最最痛恨的就是上学的时候明明开始学的都是英语发音，突然变成美语，结果，最终美语没学成，大家倒是集体变成了哑巴，偶尔有几个不是哑巴的，再不十分刻苦努力，再不自力更生，另外自己重学美语。虽然自己学不好怪不得别人，但中国大学生外语口语听力水平集体很差定是不争的事实。真奇怪，那些所谓的教育专家怎么还有脸活着－－有这么高的比例的学生不行，你们还有脸说什么吗，要你们有什么用！！！！
又扯远了，最近不断听，知道what的发音有的人会带出h来，想起了高中的时候外语科代表，是个男孩子，不知道什么时候外语就突飞猛进了，发音也是美腔美调的，只是不知道是否标准，因为自己那水平简直就是没有水平可言，经常给我们“炫耀”那发音，不是我嫉妒，他占用我们的时间再不用美语长篇累牍，再不就是美语陈述，我都不知道他在说什么，并且，如果是正确的，是否需要从基础告诉我们每个音是怎么回事啊，所以，他那样做给我们什么也带不来，所以对于这种没有良好动机的事情我投过去的不是羡慕的目光，而是生气。偶尔说一些让他不爽又没有办法的话，希望他能觉悟！嘿嘿！简单来说，你要是不教我们，就别来嘚瑟,haha
说回来，终于可以大体听懂点了，偶尔可以说上几句，怎么也是比较生硬，弄不好还听起来很做作，没关系！慢慢来！努力中－－－
今天闹了个初级笑话！因为以前看到一句Has anyone seen my watch?其实我当初也奇怪？因为这里我看就翻译成：有人看到我的表了吗？我也奇怪，怎么has可以作“有”解释了，没向下深研究，心想也许老师没教过，再不自己没好好学过这部分吧，该死，没注意那个“seen”。昨天还在msn上弄了一下，呵呵！想想，初中生都该知道的，我水平得烂成啥样，确实怪我，不过你可别笑，我是正经大学毕业的，不含糊
想想，在我初学期间，要是有人能零星指点指点那该多好啊～～
向往中。。。。。。
 主要靠自己，嗯，嗯！ 3/27/2007 codeprocodepro是个不错的工具，它能更好得规范开发提高项目质量，但它是收费的。
目前已经到4.6.0了，但是只有4.4.0的破解。很可惜。
结果选了个对付的办法，先破解4.4.0，然后再让4.6.0覆盖4.4.0，结果通过了！唉,不知道是什么原理，反正通过了。
猜想可能破解后会写个标志文件吧，结果按时间排序没找到，所以干脆算了，能用就行呗！
另外听说jtest也是个很不错的东西，没用过－－主要是没有破解。不知道好到什么程度，估计功能应该是没有codepro全面吧！
看了这篇文章哪位有更好的想法就给我留言吧，到此为止，白白！ 3/26/2007 今天天气真好 今天天气真好，下午5点左右尤其好，阳光温暖舒适，所有的光影都变得无比温和，我的心情也变得无比宁静舒适，真惬意啊！
人真是奇怪的动物，高兴和悲伤在儿童时期还都很简单明了，很多年以后就很难说清楚了，成年后甚至自己都说不清楚。心理学中说每个人都有两个我，而我们常常忽略我们的本我，所以，自己的情绪很多时候都是来自两个我的碰撞，更多的是本我的无法释放。似乎有点道理，但是听起来挺复杂的，索性干脆不去理解也罢，随他去吧！
可是突然之间又莫名奇妙的会出来一些说不清楚零星的失落和伤感，似乎是怀念留恋之类的，小的时候更多是憧憬，而今天却恰恰相反，至于具体是什么我不知道。
人的潜意识啊！就像我总是不知道为什么总容易愤怒，是无法接受如今的环境？还是不满意自己？！也许是众多的左右为难使我无法面对自己？！我不知道，索性不必知道也罢。
今天心情应该算是不错，年年如此，春夏相交和秋冬相交的时候，总能让人印象如此深刻，一面是温暖，一面是冷清，不管怎样，都是回忆！
很想出去走走——不为什么，就是走走...... 3/23/2007 新版地主长工之间的故事（灵感来源“最牛钉子户事件”）关注了很久的最牛钉子户事情，总是当作一个不太令人舒服的笑话来看的，因为结果基本上没什么悬念，但谁说能没有一丝希望呢（哈哈
  ），看到今天决定改一下下下面这个故事，因为感觉还不是很严谨，毕竟“艺术”来源于“生活”嘛！先看旧版的《地主长工之间的故事》
|
以前，有个地主有很多地，找了很多长工干活，地主给长工们盖了一批团结楼住着。一天，地主的谋士对地主说：东家，长工们这几年手上有点钱了，他们住你的 房子，每月交租子，不划算，反正他们永远住下去，你干脆把房子卖给他们起个名堂叫做-----公房出售！告诉他们房子永远归他们了，可以把他们这几年攒的钱收回来，地主说：不错，那租金怎么办？谋士说：照收不误，起个日本名儿，叫物 业费！地主很快实行了，赚了好多钱，长工们那个高兴啊！ |
过了几年，地主的村子发展成城镇了，有钱人越来越多，没地方住，谋士对地主说：东家，长工们这几年手上又有钱了，咱们给他们盖新房子，起个名堂叫做旧城改造，他们把手上的钱给我们，我们拆了房子盖新的，叫他们再买回去，可以多盖 一些卖给别人，地主又实行了，这次，有些长工们不高兴了，地主的家丁派上用途了，长工们打掉牙只好往肚子里咽，地主又赚了好多钱。 又过了几年，地主的村子发展成大城市了，有钱人更多了，地主的土地更值钱了。谋士对地主说：东家，咱们把这些长工的房子拆了，在这个地方建别墅，拆出来的地盖好房子卖给那些有钱的大款还能赚一笔，地主说：长工们不干怎么办？谋士说：咱给他们钱多点儿，起个名堂叫货币化安置，咱再到咱们的猪圈旁边建房子，起个名堂叫经济适用房，给他们修个马车道让他们到那边买房住，地主说：他们钱不够怎么办？谋士说：从咱家的钱庄借前给他们，一年6分利，咱这钱还能生钱崽，又没风险，地主又实行了，长工们拿到钱，地主的经济适用房到现在才建了一 间，长工们只好排队等房子，直到现在，还等着呢------ 于是，长工们开始闹事了，地主有点慌，忙问谋士怎么办？谋士说：赶紧通知长工们，房子要跌价了，别买了，租房住吧，正好把我们的猪圈租给他们，结果，这么多年后，长工们的钱全没了，还在租房住，直到永远！
3/7/2007 超循环背诵大表内容详解
一、关于艾宾浩斯曲线 1、人的大脑是一个记忆的宝库，人脑经历过的事物，思考过的问题，体验过的情感和情绪，练习过的动作，都可以成为人们记忆的内容。例如英文的学习中单词、短语和句子，甚至文章的内容都是通过记忆完成的。从"记"到"忆"是有个过程的，这其中包括了识记、保持、再认和回忆。有很多人在学习英语的过程中，只注重了学习当时的记忆效果，孰不知，要想做好学习的记忆工作，是要下一番工夫的，单纯的注重当时的记忆效果，而忽视了后期的保持和再认同样是达不到良好的效果的。
在信息的处理上，记忆是对输入信息的编码、贮存和提取的过程，从信息处理的角度上，英文的第一次学习和背诵只是一个输入编码的过程。人的记忆的能力从生理上讲是十分惊人的，它可以存贮1015比特(byte，字节)的信息，可是每个人的记忆宝库被挖掘的只占10%，还有更多的记忆发挥空间。这是因为，有些人只关注了记忆的当时效果，却忽视了记忆中的更大的问题--即记忆的牢固度问题，那就牵涉到心理学中常说的关于记忆遗忘的规律。
1、艾宾浩斯记忆规律曲线解释
德国有一位著名的心理学家名叫艾宾浩斯(Hermann Ebbinghaus，1850-1909)，他在1885年发表了他的实验报告后，记忆研究就成了心理学中被研究最多的领域之一，而艾宾浩斯正是发现记忆遗忘规律的第一人。
根据我们所知道的，记忆的保持在时间上是不同的，有短时的记忆和长时的记忆两种。而我们平时的记忆的过程是这样的：
输入的信息在经过人的注意过程的学习后，便成为了人的短时的记忆，但是如果不经过及时的复习，这些记住过的东西就会遗忘，而经过了及时的复习，这些短时的记忆就会成为了人的一种长时的记忆，从而在大脑中保持着很长的时间。那么，对于我们来讲，怎样才叫做遗忘呢，所谓遗忘就是我们对于曾经记忆过的东西不能再认起来，也不能回忆起来，或者是错误的再认和错误的回忆，这些都是遗忘。艾宾浩斯在做这个实验的时候是拿自己作为测试对象的，他得出了一些关于记忆的结论。他选用了一些根本没有意义的音节，也就是那些不能拼出单词来的众多字母的组合，比如asww，cfhhj，ijikmb，rfyjbc等等。他经过对自己的测试，得到了一些数据。 然后，艾宾浩斯又根据了这些点描绘出了一条曲线，这就是非常有名的揭示遗忘规律的曲线：艾宾浩斯遗忘曲线，图中竖轴表示学习中记住的知识数量，横轴表示时间(天数)，曲线表示记忆量变化的规律。
这条曲线告诉人们在学习中的遗忘是有规律的，遗忘的进程不是均时候后，几乎就不再遗忘了，这就是遗忘的发展规律，即"先快后慢"的原则。观察这条遗忘曲线，你会发现,学得的知识在一天后，如不抓紧复习,就只剩下原来的25%)。随着时间的推移,遗忘的速度减慢，遗忘的数量也就减少。有人做过一个实验，两组学生学习一段课文，甲组在学习后不久进行一次复习，乙组不予复习，一天后甲组保持98%，乙组保持56%；一周后甲组保持83%，乙组保持33%。乙组的遗忘平均值比甲组高。
2、不同性质材料有不同的遗忘曲线
而且，艾宾浩斯还在关于记忆的实验中发现，记住12个无意义音节，平均需要重复16.5次；为了记住36个无意义章节，需重复54次；而记忆六首诗中的480个音节，平均只需要重复8次！这个实验告诉我们，凡是理解了的知识，就能记得迅速、全面而牢固。不然，愣是死记硬背，那也是费力不讨好的。因此，比较容易记忆的是那些有意义的材料，而那些无意义的材料在记忆的时候比较费力气，在以后回忆起来的时候也很不轻松。因此，艾宾浩斯遗忘曲线是关于遗忘的一种曲线，而且是对无意义的音节而言，对于与其他材料的对比，艾宾浩斯又得出了不同性质材料的不同遗忘曲线，不过他们大体上都是一致的。因此，艾宾浩斯的实验向我们充分证实了一个道理，学习要勤于复习，而且记忆的理解效果越好，遗忘的也越慢。
3、不同的人有不同的艾宾浩斯记忆曲线--个性化的艾宾浩斯
上述的艾宾浩斯记忆曲线是艾宾浩斯在实验室中经过了大量测试后，产生了不同的记忆数据，从而生成的一种曲线，是一个具衡的，不是固定的一天丢掉几个，转天又丢几个的，而是在记忆的最初阶段遗忘的速度很快，后来就逐渐减慢了，到了相当长的有共性的群体规律。此记忆曲线并不考虑接受试验个人的个性特点，而是寻求一种处于平衡点的记忆规律。 但是记忆规律可以具体到我们每个人，因为我们的生理特点、生活经历不同，可能导致我们有不同的记忆习惯、记忆方式、记忆特点。规律对于自然人改造世界的行为，只能起一个催化的作用，如果与每个人的记忆特点相吻合，那么就如顺水扬帆，一日千里；如果与个人记忆特点相悖，记忆效果则会大打折扣。因此，我们要根据每个人的不同特点，寻找到属于自己的艾宾浩斯记忆曲线。 (作者系南开大学心理学教授 博士生导师)
二、关于超循环背诵大表 《超循环背诵大表》是根据德国心理学家艾宾浩斯遗忘曲线精心设计的背诵工具，它不仅可以帮助学习者轻松大量的背诵英语文章、词汇，大大提高背诵速度，降低遗忘所带来的烦恼；同时还可以对学习的目标，计划，期限作出详细的指引，对每日的新内容和复习的内容一目了然，做到一张大表，尽在掌握！
作用： 1.使您轻轻松松科学的规划每天的学习 2.让你快速达成既定的学习目标 3.适用于任何的学习科目 4.根据学习的时间期限,合理安排每日学习量 5.提高英语学习效率10倍以上的方法 6.随时提醒自己不要放弃自己的目标 7.克服惰性，培养坚韧性格 8.养成终生受益的学习习惯 9.公众承诺,始终提醒自己要坚持不懈 特点： 1.科学性:根据艾宾浩斯遗忘曲线，设计出最合理的背诵方案和策略，及时重复的强化训练，在最短时间内获得惊人的背诵效果； 2.合理性:根据人的心理特点,将大的工作量变成可以轻松完成的小训练.是学习训练成为一种兴趣； 3.集中性:由于所有训练都按计划实施,避免了做一天和尚撞一天钟,拖拖拉拉的学习造成的时间浪费。 适用人群：
1.新概念英语背诵营学员 2.想有效背诵文章的朋友 3.TOEFL\GRE等需要背诵大量词汇的考生 4.合理安排学习计划的学员 超循环背诵大表：下载
三、举例说明 分为短期记忆和长期记忆两种。
第一个记忆周期是5分钟。
第二个记忆周期是30分钟 第三个记忆周期是12个小时 这三个记忆周期属于短期记忆的范畴。下面是几个比较重要的周期。 第四个记忆周期是1 天 第五个记忆周期是2 天 第六个记忆周期是4 天 第七个记忆周期是7 天 第八个记忆周期是15天 以上的8个周期被应用于笔者的背词法，作为一个大的背词的循环的8个复习点，可以最大程度的提高 背单词的效率。
背词法
杨鹏是以老于的书为例的。以第一个LIST为例。
步骤一、LIST的第一页，共有9个单词，用不到5分钟的时间背一遍。
步骤二、此五分钟的记忆周期已到，请不要看第二页，立即迅速的复习一遍第一页的单词。复习的标准是“试图回忆该单词的意思”
步骤三、2、3页和4、5页的内容每一页都要重复刚才的步骤二。即每背完一页的单词，都要再复习一遍。
步骤四、等背到7、8时仍然重复步骤二的方法，所不同的是在背完该页的单词之后，请不要背9页的单词，而是重复步骤五的内容。
步骤五、由于距离背第一个单词的时间已经有了30分钟，所以立即回到第一页，迅速的把1-8的内容复习一遍。
步骤六、对于剩下的半个LIST，仍然在半个小时的时间内，重复步骤五，整个LIST共用一个小时的时间。
杨鹏建议G友选择早晨的时间来背新的单词。到了晚上也就是在背过单词的12个小时以后，到了记忆的第三个记忆周期一定要复习 今天新背过的单词。 郁闷的一天 今天很郁闷，早上起来，准备临时赶火车，结果没赶上，花了270的卧铺车票，最后只拿回来30元。还没走成。
反思一下吧，防止以后再犯这么愚蠢的错误，想想，大概是如下原因：
1 早上做公交的时候该耐心的时候没耐心，不该耐心的时候太耐心了；为了快一点，先坐了一趟中转车，结果刚下车，就看到后面一辆直达车呼啸而过；而后，来了好几辆“临客”－－就是那种车很多，但是很慢的那种啦，结果我都没有上，耽误了很多时间，哪怕是但是坐地铁也不至于啊，唉。。。
2 太能稳得住了，在离火车要离开只有40分钟的时候，我居然还洗了个脸，刷了个牙，去了一趟洗手间；
3 如果没有意外还是来得及的，结果打车要路过长安街，长安街早上红绿灯由人来定的，结果长安街上车都断流了，我们这边都塞满了，那个傻乎乎的警察还没给放绿灯，硬是给红了小10分钟。这个世界就是有的人的路宽得可以打滚儿，有的人连路都几乎没得走，nnd；
4 谁要是天天走长安街，你一定会得出北京的交通爽歪歪了，根本不堵车；
总结一下吧，其实是自己的错，我完全可以再提前40分钟，唉，大部分IT人士的严重缺点，我这个毛病得改，必须改！！
人总会犯一些错误，有些代价是金钱，有些代价是时间，有些代价是名声，有些代价是生命。对于这次我这次来讲，也就是金钱和时间。还有就是不知道本来属于我的那个卧铺被哪个兄弟姐妹用了－－或者一路空着，真希望我的那个卧铺被哪个兄弟免费使用－－但是估计不可能，铁路会再卖一次给他，所以他怎么也不会默默感激我的，唉，学雷锋日刚过，雷锋没学成，－－尽管是不小心不得已学一次雷锋，呵呵！ 3/6/2007 一些很彪悍的句子 (转)一些很彪悍的句子 (zz)发表时间: 2007-3-03 20:12 作者: mecerdes 来源: 红枫英语网 爱她，就请为她做无痛人流手术！ －－起码有三个台，不分昼夜地播这些，细想一下，不由感慨：这年月，电视台越来越流氓了 爷爷都是从孙子走过来的…… －－所有的大白话中都蕴涵着真理 其实我是一个天才，只可惜天妒英才！ －－可以看成借口，不过也还有用，心理暗示加乐天知命 都是水何必装醇，都是色狼又何必装羊！ －－至少你不伪善，伪善比无耻强得多了 你看得见我打在屏幕上的字，却看不到我掉在键盘上的泪…… －－－可以和某位IT精英的与狗聊天论相呼应 师太，你就从了老衲吧…… 师太，你就饶了老衲吧…… －－某ID被人篡改得可以为一字之师，真是终生难忘 客官请自重，本姑娘是卖身不卖艺的！ －－－NND，面对很多明星，也许，这才是人格。 长个包子样就别怨狗跟着！ －－－白话有白话的痛快。 学海无涯，回头是岸！ －－－考研，混硕，读博，出国……以佛眼相看 猪有猪的思想，人有人的思想。如果猪有人的思想，那它就不是猪了——是八戒！ －－－可以用来对付某些伪精英的言论，诸如房子太便宜，穷人都去死…… 我死了，在烈火中我又站起来了，你猜是涅盘，还是尸变？ －－－面对很多废而又立的事物，不要忘记，此类事情，终究是涅盘的少，尸变的多 老天，你让夏天和冬天同房了吧？生出这鬼天气！ －－－面对气温变化莫测的陡变，真正的诗人如是说 不要在一棵树上吊死，在附近几棵树上多试试死几次~ －－－这世界本没有彻底完蛋，失败多了，才成了破产清盘 当头晕的时候我终于明白了什么叫爱情。 －－－相对于你恋爱时的献媚，这是至理名言 偶尔幽生活一默你会觉得很爽，但生活幽你一默就惨了~ －－－生活真的很幽默 心终于可以放下了，原来那100多个是人头不是猴头！不然死了那么多猴猴多可惜啊…… －－－个人认为，这是对前阵子，某条新闻最彪悍的评论 马化腾私下说：“学十年语文没有聊半年QQ效果好！” －－－如果这真是马化腾说的，至少可以说是他这辈子最真实的言论 早餐里吃到刷锅的金属丝很正常，这正说明我们后勤是严格按照先刷锅后做饭的顺序操作的…… －－－塞翁失马论是一种普适的真理。还有苦中作乐的好处 大便的时候要留一半，免得饿得快~ －－－这人一定发财了 女人拥有无数个QQ号只为了调戏一个男人，男人常用一个QQ号上面加满各种各样的女人…… －－－你有几个QQ号？ 钓鱼岛是中国的，你是我的！ －－－这才是爱国主义浪漫爱情诗人的作品 菜刀在手，问天下谁是英雄！！！ －－－有苏公豪放派词风 |
|
|
