CYNDI

先零散记一些,以后有机会再整理吧.

—————————————-

IBM的管理方法(WWPMM)核心为产品分解结构、工作分解结构、组织分解结构.

让我想到做项目总结时,我们在划分管理方法时是分为项目管理、组织管理、基本元素.

—————————————-

对于mFone的团队来讲,应该说已经向一个大型团队运作一个大型项目进化了,项目管理涉及的方面也比较全了,团队的发展空间比较自由,所以很多项目管理方法是由需求自然而然触发的,然后在管理团队的努力下结合了理论知识和实践经验一点点形成的,但对于有些团队而言,有很多东西是无法搬项目管理的方法,比如mFone的项目很完整,而很多小项目缺头少尾,往往特殊性非常强.比如SDK这样的项目,它属于技术支持的项目,在运作的时候就会有很多不同的地方,有些管理方法是不适合在这种团队上使用的,以后再详细写.

有人提到: 华为在项目管理方面的先固化僵化的做法还是值得很多企业借鉴. 事实上这种做法在很多企业也会不适用,什么样的企业不适用呢,比如mFone的这种团队,大部分成员对凭空来的管理方法接受度非常低,很容易水土不服.

—————————————-

如果有空,想要把以前mFone项目中涉及到的方方面面寻个机会记录下来,这是一笔宝贵的经验.择日不如撞日,逛mypm论坛时突然就有写的冲动,那么今天就开个头吧~

IBM的项目管理方法有13种,它本身是对PMBOK的补充了,下面提到的在mFone项目中很多都是有需求的并且在项目过程中主动或被动的被触发的.站在我的角度在mFone项目中有所涉及并且有一定应用的项目管理方法:

1. 变更管理Change Management

说明:在Dante项目中后期,客户的需求变更非常频繁,我们不得不重视变更管理,并因此产生了很多因事而宜的管理方法,比如产生了确认变更的流程,通过会议来confirm需确认的bug等等,以后再详细的写.

3. 交付管理Delivery Management

说明:做为一个产品化项目一定是有交付物的,Mars项目还停留在随意交付的情况,交付物只有binary package,并且多个研发部门分别向QA交付,导致QA还要承担集成的责任,到了Dante项目出现了多个部门要同时在一个milestone交付多样交付物(如UI文档/镜像等),QA无法也不应再承担集成的责任了,这使得当时的应用部成为所有部门对QA输出的统一路径,交付过程也增加了相对详细的交付说明,配置管理也出现了,另外交付管理由于涉及多个问题,还产生了对多个交付品之间同步问题的解决方案等等.

7. 质量管理Quality Management

说明:在所有的mFone产品中,质量管理是最早被得到重视的,因此我们的项目管理方法中最早成形的就是bug管理系统,在Dante这个项目中质量管理更细化到了每个测试阶段,不同的测试目标等等.

10. 跟踪和控制Track And Control

说明:当同一时刻N多任务在N多个人之间进行,跟踪和控制就被触发了,Leader需要知道每个任务的进展以及是否遇到困难以便及时调整资源分配并且控制预期目标实现的风险,曾经有过很多不同的excel表用于跟踪任务完成的情况,设立专人而且每天晚上还会汇总进度报告,但管理的同时为了得到准确的进度工程师的工作也不得不被打断,也曾经尝试过使用专门的系统由工程师在下班前主动填写进度,但在项目繁忙的情况下专人Push的方法显得更有效.

13. 工作计划管理Work Plan Management

说明:由于Dante项目是产品项目,客户更关心项目时间,因此以往粗略的计划无法适应客户的需求,各部门按照各项目阶段都需要有工作计划,甚至到各人,当然越细化的工作计划就越精确,但mFone的项目几乎就没有足够的时间和人力来应付做计划带来的消耗,因此工作计划虽然从个人到小团队到项目都有做,但很少能持续,有的是用Project,有的是用Excel.

——————————————–

下面还有一些管理方法在项目中有需求触发过,但不够强,即使没有也能过,因此并没有产生真正的方法.

2. 沟通管理Communication Management

说明:从Mars项目到Dante项目,一个显著的变化就是分工更细化了,项目管理部/文档/UI/UX/系统部/应用部/QA等等,一个产品的完成被N多个部门细分了,由此带来了很多沟通问题,比如前期项目管理部对项目计划的制定与RD产生了冲突,前期测试部的测试计划与RD缺乏沟通等等,我想准确的讲沟通管理的问题我们并没有真正的方案尝试着解决,更多的可能还是依靠人与人之间的把握.

4. 事件管理Event Management

说明:这里的事件管理具体指什么,我要再看下PMBOK,不知道会议算不算事件管理,会议是项目中必然的事件,它的影响是可能打断与会者的工作,项目中的各种会议在组织/准备/通知/记录方面我们开始寻求怎样才能达到良好的效果,另一方面对于手机项目的各种测试(如CTA),这种即定下来的肯定会发生的算事件不?对于项目团队共公的或个人的需要处理的事件,也曾出现过使用论坛/网站等工具管理,但由于在事件管理方面需求强度不同,在mFone的团队中个人的会弱一些,而共公的可能需求不突出,往往只是通过邮件进行管理.

5. 人力资源管理Human Resource Management

说明:在项目中始终存在这个问题,尤其是一做就一年的项目,但人力资源管理涉及资源备份等方方面面,在技术团队中相对比较难做,没有真正的方案去尝试解决.

———————————————

呵呵,分的比较乱,还有一些实际上并不是在项目中被触发的,而是在项目总结中被发现的有需求的管理方法.

6. 项目定义Project Defintion

说明:UI/UX的需求比较大,他们开始认为项目定义影响着项目的需求定义,在项目总结阶段大家认为项目定义应该在与客户的前期沟通过程中由项目承接团队产生.(PS:如果这里的项目定义是指需求定义那种…就应该放到上面了,需求定义和变更管理不是一回事,13项里好像没有…去看完了PMBOK再说吧)

9. 风险管理Risk Management（对应PMBOK的风险管理）

说明:开始做项目时是不太care风险管理的,一切先做再说,做了遇到问题再说,项目的前期评估通常只是时间上和技术难度的简单评估,但到了Dante项目中不停出现的广泛意义上的风险时,大家开始想要重视对风险的评估和控制,比如第三方合作的风险,团队中人力的风险等等,再遇到类似的事情时会多考虑一下风险的问题,但整体的项目风险管理方法是在项目总结阶段才出现的,因此也借鉴了成熟的一些方法和经验.

11. 供应商(采购)管理Supplier Management

说明:需求不明显.

12. 技术环境管理Technical Environment Management

说明:需求不明显.

8. 赞助人协议管理Sponsor Agreement Management

说明:需求不明显.

之前在ubuntu下装过几次,这下因为事先已经把svn装在了windows下,因此要在windows下再装一把.

还算比较简单,主要参考了rocksun的文章(原文出处找不到了…)以及bugx的文章(http://blog.nowans.com/content/log.2007.1.25.191.html).

我自己遇到了哪些重点问题再记录一下.

首先是下载各大安装包.

Python： http://www.python.org/ftp/python/2.4.4/python-2.4.4.msi
Clearsilver： http://www.clearsilver.net/downloads/win32/clearsilver-0.9.14.win32-py2.4.exe
Pysqlite： http://initd.org/pub/software/pysqlite/releases/2.3/2.3.2/pysqlite-2.3.2.win32-py2.4.exe
svn-python： http://subversion.tigris.org/downloads/svn-python-1.4.4.win32-py2.4.exe
Trac： http://ftp.edgewall.com/pub/trac/trac-0.10.4.win32.exe
其次先装Python,然后你可以考虑按照上步的顺序依次安装.这里有个重点就是这台机器之前已经装过python了,是在安装plone时自带的,但没有注册到系统中,所以pysqlite安装时会不认,不得不重装了个2.4版本的.这台机器之前还装过了svn,但装的是svn-win32版本的,所以trac安装时也会不认,不得不补装个svn-python.这样就应该可以顺利到安装完所有的工具了.最后提醒一下要在path里增加python安装的路径.

然后配置svn(这里不敖述,主要是svnadmin create得创建一个代码仓库).

最后配置trac.

前提: trac安装时相关命令都默认放在了python安装目录下的scripts目录中.

1) 创建项目(假设叫目录叫trac,项目名叫sdk,当然相同更好)
python.exe trac-admin d:\trac initenv
注意输入项目名和项目对应的SVN仓库地址,这一点和linux下trac配置相同.

2) 创建用户
python.exe trac-digest.py -u cyndi -p 123456 >> d:\trac\passwd.digest
注意这里的trac-digest.py哪里来呢?
这一步linux使用的是htdigest命令来创建用户,可是windows下大部分人是使用apache工具的,但我不打算再装个apache,因此借鉴了bugx的一篇文章.

把下面这段代码存为trac-digest.py(可以放在python安装目录下的scripts目录中):

3) 授权用户
trac-admin d:/trac/ permission add cyndi TRAC_ADMIN
注意这里TRAC_ADMIN是超级管理员权限,这一点和linux下trac配置相同.

4) 启动Trac
tracd -p 8000 –auth *,d:/trac/passwd.digest,njg d:/trac/
注意事实上第2)和第3)步是可以忽略的,没有用户trac也一样用,如果不使用用户管理的话,启动trac可以这样:tracd -p 8000 d:/trac/,这一点和linux下trac配置相同.

补充一点:上面这个auth前面是两个-,p前面是一个-.

1.安装svn:
$ sudo apt-get install subversion
$ sudo apt-get install libapache2-svn      //这个是安装apache部分,如果不使用http协议可以不必装这个.

2.配置svn服务器端:
首先,创建subversion用户组,并且将www-data和您自己这两个用户加入该组.(这可以通过在Ubuntu 菜单上选择“系统->系统管理->用户和组”操作).
其次,创建svn的根位置,
$ sudo mkdir /home/svn
$ cd /home/svn
然后,开始一个新的知识库,
$ sudo mkdir myproject
$ sudo chown -R root:subversion myproject
$ sudo chmod -R g+rws myproject    //这个是为了赋予组成员对所有新加入文件仓库的文件拥有相应的权限
$ sudo svnadmin create /home/svn/myproject  //开始一个新的知识库
最后,设置用户验证,
$ sudo vim /home/svn/myproject/conf/svnserve.conf  //将# [general]和# password-db = passwd的注释取消掉,这表示使用同级目录下的passwd文件做为密码数据库.
$ sudo vim /home/svn/myproject/conf/passwd   //添加man.zhong用户及密码.

3.使用svn客户端:
这里只介绍两种方式,假设工作目录位于/home/cyndi/work/下.
$ svn co file:///home/svn/myproject             //这是当客户端与服务器端在同台机器上时,这么访问.
$ svn co svn://10.28.158.133/home/svn/myproject –username man.zhong
另外,为了使客户端访问知识库时简化目录,可以在服务器端启用daemon,
$ svnserve -d –foreground -r /home/svn
这样客户端的访问可以简化为,
$ svn co svn://10.28.158.133/myproject –username man.zhong

详细的svn安装及设置可参考:http://wiki.ubuntu.org.cn/SubVersion

4.安装trac并设置,与svn相仿:
$ sudo apt-get install trac
$ sudo trac-admin /home/trac initenv    //除了项目名称(myprojectname)和svn仓库路径(/home/svn/myproject)以外，其余可使用默认.
$ sudo chown -R root:www-data trac
$ sudo chmod -R g+rsw trac

5.设置用户权限:
首先,创建用户,第二参数指定用户文件存放的位置,第三个参数指定连接的域,第四个为用户名,
$ htdigest -c /home/trac/passwd.digest trac.palmsource.com man.zhong
其次,为passwd.digest文件中创建的用户绑定trac系统的权限,
$ trac-admin /home/trac/ permission add admin TICKET_ADMIN  //为admin这个用户/组加上指定权限,关于更多权限设置可以参看:http://trac.edgewall.org/wiki/TracPermissions
$ trac-admin /home/trac/ permission add man.zhong admin   //为man.zhong这个用户绑定与admin一样的权限
其次,启动daemon监听指定端口用于处理web请求，
$ tracd -p 8000 –auth myprojectname,/home/trac/passwd.digest,trac.palmsource.com /home/trac/
另外,如果不打算启用用户权限,可以这么用,
$ tracd -p 8000 /home/trac/
到这里,我所了解到的配置就基本完了.

最近认识了一个ALP部门的同事,刚好向他了解了一些ALP的项目管理方法,虽然只是初步了解,但是感受非常深,知道了TRAC这样一个系统,而且是开源的,呵呵,用同事的话说,简直是心动啊!

先说一下SCM(软件配置管理),SCM中有一篇文章可以算是我的启蒙文章,在这里:linux版本控制.从这里我了解到变更式模型(changeset)和快照式模型(snapshot).

关于SCM的选择,ALP使用的不是CVS,而是perforce,这两者的区别从这里可以查询到:版本控制系统比较,从这里还可以看出SVN相对而言优于其它的SCM工具.

重点说说TRAC.

TRAC是最小化的WEB软件项目管理和问题追踪系统,它提供了到SVN的接口并且集成了WIKI和报表功能,报表功能可惜同事没有成功演示给我,但单纯一个timeline功能就刚好可以包含项目中的最重要几个变更记录:
1.需求的变更记录,加上任务指派(assign)和跟踪功能;
2.代码的变更记录,即使用perforce的changeset功能记录所有代码变更说明;
3.文档的变更记录.

对于项目中时间线最直接的表达就是milestone,TRAC中有专门的页面提供此项目功能,另外,还有一个就是对SVN/perforce的接口,TRAC中也提供了专门的页面显示存储库(repository)目录结构.

TRAC只是ALP团队中目前使用的管理工具之一,热心的jianjun.yang还提供了一个清单(ALP Overall Engineering Enviroment private),真是非常感谢他!

PS:对于TRAC的了解还只仅限于此,今天打算把一套系统装到我的机器上,实战感受一下,它总有适合我们和不适合我们的部分,我会把结论记录在这里.:)

由于经过数次数小时修改之后,仍然无法使得网页上的文本看起来整洁一点,呜呜…放弃!

如有需要请下载查阅. CVS简单工作手册

这里记录一件事情.

在CVS中提交文件,一般有三种文件格式说明,txt,binary,file.

如果你以txt格式提交一个a.txt文件,在windows下up该文件和在linux下up该文件结果可能会不一致.

假设a.txt原本是一个linux下的文本文件,即换行是0A组成,则提交到CVS上之后再up下来,windows下up到这个文件的换行会变成0D0A,而linux下up到这个文件则不会变仍然是0A.

如果你的程序在编写时对换行进行解析就有可能因为这个小小的原因crash.

与此相关的是:决不能将图片等二进制格式的文件以文本方式提交,这也可能带来不可预计的错误.