Project Management

 

项目管理

美国Gartner Group 公司的调查显示， 为了降低失败比例， 强化项目管理以及组建项目监视小组的方法较为有效。但是， 有60%的企业没有实施项目管理， 有61%的企业没有设立监视小组。

几个误区

误区1：既然在项目人员配置中设置了专门的测试人员，那么软件所有的内部测试工作全部应该由测试人员完成。

分析：软件程序测试可以分为“白盒法”和“黑盒法”两种方式。由于使用“白盒法”对测试人员各方面素质的种种要求，在进行程序测试时 测试人员总是最优先使用“黑盒法”。他们的工作方式往往是先对程序进行“黑盒法”测试；如果测试没有通过，不得已这才考虑对程序代码 进行“白盒法”测试。显然，这种对“白盒法”有意无意的“逃避”，对软件的可靠性和稳定性构成了威胁。如何解决这个问题？一方面需要 提高对测试人员的要求，另一方面也需要程序员完成部分的“白盒法”测试（实际上，程序员往往也是进行“白盒法”测试的最佳人选）。

误区2：技术骨干应该成为项目的项目经理，项目经理一定是所有项目成员中薪水最高的。

分析：在“软件作坊”时代，这是一种普遍使用而且效果不错的方法；而在“软件工厂”时代，这种方法却带来各种问题，有时甚至直接导致 项目失败。究其原因这主要是因为随着现代软件开发分工的细化，对项目经理的要求也发生了根本的改变——最注重的不是其对某项专业技术 的掌握程度，而是其组织、领导、协调开发团队的能力（当然，可以两者均突出最好）。至于项目经理的薪水问题，这和定薪制度有很大关系 。通常，项目经理执行的是管理人员的薪酬体系，而其他人员执行的是技术人员的薪酬体系。项目经理的薪水在项目成员中是比较高的，但不 一定是最高的。有时候，为了激励技术人员，项目中的技术骨干得到的酬劳比项目经理要高。

误区3：为了保证项目继续，为了留住核心程序员，加薪吧。

分析：加薪可以说是很多企业在挽留程序员时所使用的常用方法。这一招可能暂时奏效，不过往往是人留下来了，但副作用也来了——加薪的 人未必见得多干活，没有加薪的人却开始消极怠工了。其实，项目的进行过多地依赖程序员的个人技术是“作坊”时代沿袭下来的“陋习”。 既然IT行业人员的流动是无法控制的，现在项目的执行应该更加注重团体的力量，应该更多的考虑公司整体技术水平和核心技术能力。例如形 成公司自己的专家知识库，类/函数库，第三方控件库，拥有自主版权的开发平台等。另外，实际上程序员萌生去意的原因很大程度上不是薪水 ，而是缺少激励和尊重。这需要项目经理使用“老土”一点的办法，找适当的时机对程序员做一做思想工作，向其描述项目的美好未来，让其 感受关心和尊重。总之，要从多方面着手保证项目的顺利开展，而不是简单地加薪。

误区4：项目成功的标志就是系统上线。

分析：这是对成功的传统和狭隘的定义。这就是为什么许多系统人员认为项目是成功的，而业务经理却认为项目是失败的原因。这是视角的问题。许多系统人员认为当软件可以运行时，工作就结束了。但是，业务经理却认为当业务过程由于系统运行而得到改进时，项目才算结束。尽管项目成本大部分花在了系统上，但是收益却更多地体现在业务的变革和改进上。

误区5：项目成功依赖于清晰、稳定的需求。

分析：传统的系统生命周期强调要正确地了解需求。如果这一步做到了，那么设计和开发就非常容易成功了。因为它们是可以满足需求的。这在理论上是对的，但是在实践中却很糟糕。业务经理可能直到他们看到些什么才知道需要些什么。当他们见到并使用了系统和技术时，他们的需求才会自然出现并且发生变动。这是项目周期的一部分。而且在任何长期的项目中，你确实必须为技术的改进和变化做好计划。

协作 
　　现代社会是一个讲究协作的社会，企业内部对协作的有求更加严格，一个部门和员工的任务完不成，就会影响整个目标。如同《水煮三国》一书中对木桶理论的描述，一只水桶能装多少水不但取决于最短的一块木板的长度，还取决于木板与木板之间的结合是否紧密。如果木板与木板之间存在缝隙或缝隙很大，同样无法装满水。因此一个团队的执行力不仅取决于每一名成员的能力，也取决于成员与成员之间的相互协作、相互配合，这样才能形成一个强大的整体。 

经验总结
比用户频繁更换需求更麻烦的是上司心血来潮。先讨论清楚要的是什么不要立即跟从。最好把开发放到下一个增量阶段的计划中；若说服失败，则安排少量人员简要地实现一个原型，交给上司提修改意见直到他确定了自己所想要的并改善带来的问题。切忌跟着冲动简单构思下就安排任务更改开发计划，否则就准备绕迷宫吧。

开发周期长，人员流失不可避免，要保证知识的传承。开发文档若不能保证齐全，就要保证开发时每个功能点要保持最少两个人知道。不要等到交接才匆忙安排。
重视新人的培养，否则会青黄不接，没人能保证半年后开发主力能剩几个。给新人一个月时间熟悉项目适宜，懵懂上阵很容易添乱。提供和内部教材的学习资源要保存、更新。

团队之间产生争执是正常的，说明大家乐意分享自己的观点。无论哪种观点被采用，大家都要沿此方向去努力，而不应该对这种做法有抵触心理，这会令你无法进入状态影响发挥。这对自己、团队、项目达成都没有好处。当这方向走不下去的时候，再提出之前未被采纳的意见重新考虑，这才是合适的时机。

Dev Environment

bug tracking system: 1) bugzilla(http://www.bugzilla.org, mozilla.org's bug-tracking system https://bugzilla.mozilla.org/),基于Perl:Bugzilla 2.20 有汉化版，可以用于 2.20.2，但最新版2.22还没汉化,而且汉化后还有一些问题，主要是发 Mail 不正常。  2) bugzero(一个稳定成熟的商用软件, 采用Java,J2EE技术); 3)Trac 是用Python写的一个基于Web的事件跟踪系统. 4) JIRA(商业软件,基于Java, Atlassian由开发的基于J2EE的问题跟踪管理系统), 本身已经支持多国语言(包括中文). 5)Gnats, 基于C和文件存储，只支持Unix. 6)Mantis是一个轻量级的缺陷跟踪系统, 基于PHP.

source control system: cvs, subversion etc.

 http://svnbook.red-bean.com/
http://www.chilkatsoft.com/C++-HTML-Parser.asp