随笔分类 -  项目管理

摘要：软件开发项目过程中的激励在软件开发项目中，尤其是工作量比较大或周期比较长的项目中，项目的阶段、里程碑的确定和控制至关重要，而在此过程中，如何激发项目成员的工作积极性、发挥各自的特长、挖掘内在的潜力，是项目管理者需要重点关注的，绩效考核无疑是项目管理的必备措施，而激励则是绩效考核的关键。绩效考核作为管理的措施，其目的在于提高工作成绩和效率，考核是一种衡量的标准，奖惩则是激励的手段。从管理者的角度出发，如果仅仅把绩效考核作为管理的手段，那么不能说他是一个好的领导，只能片面的说他是老板的一个好员工，因为管理者除了管理的职责，还应该注重被管理者能力（心态、积极性、能力、特长）的提高，因为只有被管理者的 阅读全文

摘要：CMM和PMP是两个不同的概念域，是用来解决不同问题的。我们所说的CMM，准确的说应该是叫做能力成熟度模型，北京猴子说的软件能力成熟度模型实际上应该称为SW-CMM，是CMM的一个子集。PMP可以看做是一种手段或是方法，而CMM却不是，它只是一种标准，用来判定企业或组织的能力成熟度。因此，我认为已经遵从CMM规约组织项目的企业或组织，如果有能力的话，也是应该实施PMP的。实际上企业在实施CMM的时候，CMM标准实际上已经要求按照一定的项目管理措施来实施CMM定义的生产和开发过程，只是CMM没有具体的给出用什么样的方法和手段来进行项目管理。 也就是说，CMM告诉我们该“做什么”，却没有指出“怎么 阅读全文

摘要：如何进行团队激励如何进行目标管理如何进行绩效考核如何处理团队沟通（技巧）详述几种软件过程理论需求分析和度量测试过程和工具开发管理过程 阅读全文

摘要：★墨菲定律PMP考试六大管理学定律之1-PMP专业辅导1、什么是墨菲定律？最简单的表达形式是“有可能出错的事情，就会出错（Anythingthatcangowrongwillgowrong）。” 爱德华·墨菲(EdwardA.Murphy)是一名工程师，他曾参加美国空军于1949年进行的MX981实验。这个实验的目的是为了测定人类对加速度的承受极限。其中有一个实验项目是将16个火箭加速度计悬空装置在受试者上方，当时有两种方法可以将加速度计固定在支架上，而不可思议的是，竟然有人有条不紊地将16个加速度计全部装在错误的位置。于是墨菲作出了这一著名的论断，并被那个受试者在几天后的记者招待会 阅读全文

摘要：项目经理面试指南 简介 本文的目的是为应聘项目经理提供帮助。项目管理是升迁的途径，需要运用你过去的开发经验，而且薪水通常高于程序员。应聘项目经理的准备工作包括：复习一些常用的概念、术语，问自己一些在面试中经常问到的问题。学会运用一个或多个项目管理计划编制工具。通过以上的准备，将为你应聘这个职位增加信心。 想好你要说的内容并准备回答涉及面广泛的问题是成功应聘的重要方面。与应聘技术职位不同的是，项目管理问题的答案往往是主观的。要牢记技术项目的项目经理的职责是组织项目成员通过完成技术任务而达到某种商业目标。该技术任务应该是可应用或维护的，都必须满足客户/用户的要求和期望。 本文的目标并不是教授... 阅读全文

摘要：谈需求三要素,其实就是从需求是什么开始,理清几个最基本的概念,这个时候不得不提的就是需求的三个层次:业务需求\用户需求\软件需求,因此,我们这个时候谈的需求不是管理学中的概念,不是马斯洛五层次需求模型中的需求,而是基于产品来谈的需求,更准确的说是基于软件产品来谈的需求.下面把相关概念分别描述:业务需求:从非技术\商业的角度来谈的目标,和计算机/软件没有关系,即从业务的角度,客户希望达到的目标或效果,比如客户希望HRM体系完整,HR流程运作高效畅通,人力成本控制在某个额度内等等.有效合理的目标可以用SMART原则来衡量,这里就不再累述,客户所谈的目标越符合SMART原则,代表业务需求越清晰.目标 阅读全文

摘要：前段时间把一个界面框架完成了，今天基于这个框架开发一个小模块，在这里把这个模块设计的全过程记录下来，希望大家讨论并指正。一、起因公司交给我一个任务，为测试员写一个手机模拟界面，以方便她们的手机短信测试。过去她们都是用MC4J直接调用公司服务器的MBean服务来模拟进行测试，以验证我们整个系统平台。这种测试主要是检查收发短信是否正常，而我的要做的工作就是，让她们在测试的时候更方便更直观。二、需求我和测试员陈MM（也就是软件的使用者）约定了一个时间，大家一起来讨论这个软件的需求。1、首先，我大概了解了一下她们的测试工作，知道我要做个什么东东。2、然后我回去思考了一下，再次找她详细了解其测试的具体步 阅读全文

摘要：http://wenku.baidu.com/view/7ce70573f242336c1eb95eca.html 阅读全文

摘要：Recently while cleaning up my photo albums I found some interesting old pictures which were captured while I was leading a Scrum project. These white board pictures illustrate how we incrementally deliver from scratch. Looking at these pictures I really enjoy recollecting the days when I was working 阅读全文

摘要：http://www.mianwww.com/html/2012/04/15307.htmlhttp://www.mianwww.com/html/2012/03/14716.html 阅读全文

摘要：http://www.mianwww.com/html/2009/11/6405.htmlhttp://www.mianwww.com/html/2009/11/6401.html 阅读全文

摘要：从07年中初次接触Scrum的概念到其中几年项目中逐渐实践CI、TDD，到亲自掌握项目实践Scrum近一年，最终我们放弃了Scrum这个框架和所谓的“自组织”。原因为何？1.成员放弃了Scrum所“赋予”的“权利”比如领用任务、评估工作量、自组织协作、决策等。在第一次Scrum计划会议上排出任务让大家领用时，成员的态度可以用“反感”来形容。在经历四个Sprint后成员依然坚持认为，应为PM完成这些工作，故放弃。2.团队成员能力参差不齐我很主观地认为，现在国内的开发团队都会是一部分高级工程师搭配一部分初、中级工程师，这种搭配本身就决定了领用任务时的混乱，尤其是团队中一部分成员极度渴望去做那些自己 阅读全文

摘要：什么是敏捷开发方法？什么是SCRUM？有人在这个字面上下功夫，说敏捷就是反应要灵敏，动作要快捷；有人还在字面上进行延伸，说敏捷就是又好又快，或者就是多快好省；有人说敏捷就是光写代码不写文档；有人觉得敏捷就是没有制度，管理松散的工作方式；有人觉得只要敏捷了，就代表高软件交付水平。 那么，敏捷这个词到底由何而来呢？在九十世纪中期，涌现了一批软件行业的激进人士，他们反对那些以过程为本的重型软件开发方法（例如：传统的瀑布开发方 法）。在2001年，17位软件业界的专家们齐聚一堂，讨论正在兴起的轻量级开发方法（Lightweight methods）。专家们给这类轻量级的方法学起了一个新的名字叫做敏捷， 阅读全文

摘要：场景：D原先正在进行一项工作T1，承诺今天下班前完成；中午的时候，D的领导E给他下了一个任务T2，要求在明天下班前完成，结果D放下了T1，去执行T2。由于T1工作我负责监督，所以当发现T1没有按时完成的时候，我询问了D为什么，D给我的解释是出现了突发事件，并且问了我他遇到的困扰：“领导给我安排新的任务，但是和正在进行的任务在时间上出现冲突，该怎么办？”分析：我给他的回答和分析如下：原则性如何把握，是因为领导交办下来的任务就优先保证呢？还是承诺优先？工作T1也好、T2也好，简单化的领导任务优先方式是不是就是正确，时间的估计是否有进行？！只有是根据时间以及风险来进行安排才是最好的方法，在这个例子里 阅读全文

摘要：Scrum实施过程中遇到的典型问题，答案综合了网络中的借鉴和自己实践中的体会。 Q1：技术负债在敏捷团队中会快速的膨胀。 A1：由于敏捷开发过程没有充足的事前（up-front）设计，技术负债是不可避免的，虽然可以通过TDD、连续集成、重构减轻症状。同时敏捷开发者提倡的原则(比如S.O.L.I.D原则，Clean Code,Implementation Patterns )都能帮助敏捷团队避免过多的技术负债。传统的瀑布式开发技术负债是较少的，敏捷开发不是瀑布式开发的对立面，必须在实践中结合两者的优势。根据国外专业网站的调查，在敏捷实践中超过60％的团队都会进行一些事前设计以减少技术负债。Agi 阅读全文

摘要：PROJECTMANAGEMENTKNOWLEDGEAREAS项目管理知识体系 2PROJECTLIFECYCLE/PROJECTMANAGEMENTPROCESSGROUPS项目生命周期及过程组 10SCOPE范围管理 11HUMANRESOURCE人力资源管理 12COMMUNICATIONS沟通管理 15TIME时间管理 17COST成本管理 19RISK风险管理 22QUALITY质量管理 23PROCUREMENT采购管理 23INTEGRATION整体管理 19PROFESSIONALRESPONSIBILITIES职业道德 19POSSIBLEEXAMQUESTIONS考点 20 阅读全文

摘要：BRD：Business Requirements Document，商业需求文档。这是产品声明周期中最早的问的文档，再早就应该是脑中的构思了，其内容涉及市场分析，销售策略，盈利预测等，通常是和老大们过的ppt，所以也就比较短小精炼，没有产品细节。MRD：Market Requirements Document，市场需求文档。获得老大的认同后，产品进入实施，需要先出MRD，具体来说要有更细致的市场与竞争对手分析，通过哪些功能来实现商业目的，功能/非功能需求分哪几块，功能的优先级等等。实际工作中，这个阶段PD可能的产出物有Mind Manager的思维图，Excel的Feature List等。 阅读全文

摘要：我认为一个有效评价手段应该达到以下目的：1、 对团队：让整个团队进入愉快高效工作状态2、 对“高手”：奖励干活多干活好的人3、 对“低手”：从制度上杜绝磨洋工的现象4、 对“中手”：提供工作认真但是水平有待提高的成员生存成长空间一个团队，总是有着各种各样的人，每个人在这个团队里都是主角。为了团队，他们有着相同的目标，但却担任着不同的角色，做着不同的事情。正因为每个人都做不同的事情，所以我们很难在定义一个统一的标准来评判个人在团队中的绩效。在软件开发中，每个人各司其职，有项目经理，有开发人员，有测试人员，还有设计师。如果单纯的通过代码量来评判个人绩效，那PM早就被开除了；如果只通过结果来判断，那 阅读全文

摘要：关于BUG的沟通 一个人要去做一件事情，一般来说是按照自己的意愿去做的，如果不是自己想做而是被要求这么做的话，心里一定会留下点不愉快，特别是那种有自信有自己主见的人，比如说开发人员，当测试人员发现一个BUG，然后告知开发人员后，开发人员之所以会去修改BUG，是因为他自己认为的确需要修改，而不是因为你提到要改他才改的，所以当他认为不需要修改的时候，肯定是有自己的想法和理由，不妨理解下他们，合理的就可以接受，不合理的话，也不要强制的让他去修改，试着解释给他听，让他心甘情愿的去修改，这才不会让他心里产生不愉快的情绪，开发人员和测试人员彼此间的关系才不会弄得很紧张，如果强制性的让他修改多次的发生，那. 阅读全文

摘要：Maven / Nexus 的用法和经验 阅读全文