手机浏览 RSS 2.0 订阅 膘叔的简单人生 , 腾讯云RDS购买 | 超便宜的Vultr , 注册 | 登陆
浏览模式: 标准 | 列表Tag:项目管理

项目管理流程图

这是一个流程图,来自于禅道,http://www.zentao.net/help-read-79236.html
可以在自己的项目中做借鉴啊

在禅道项目管理软件中,核心的角色有产品经理、项目经理、研发团队和测试团队四种角色。如果您现在的团队是采用敏捷开发的话,那么可以对应到 product owner, scrum master和team(dev and tester)。这几种角色之间紧紧围绕产品的需求展开协作,取得成果。禅道核心的管理流程全图如下所示:
大小: 368.29 K
尺寸: 500 x 354
浏览: 3607 次
点击打开新窗口浏览全图
其实以前公司有流程图,但这一张图相对会比较完善一点

Tags: 项目管理, 禅道

SVN提交更新的一个准则

同样,是一篇摘录,笔记。勿怪。。。
原文:http://www.cnblogs.com/chenlong828/archive/2008/09/22/1296193.html
作者:dreamland

查阅了一下网络和博客园,发现还没有一个明确地指导源码管理提交准则的相关文章,因此斗胆整理了一部分自己平时开发管理的心得,加上查阅了部分英文资料写了一个不算很完善的SVN提交准则。

 

负责而谨慎地提交自己的代码

SVN更新的原则是要随时更新,随时提交。当完成了一个小功能,能够通过编译并且并且自己测试之后,谨慎地提交。

如果提交过程中产生了冲突,则需要同之前的开发人员联系,两个人一起协商解决冲突,解决冲突之后,需要两人一起测试保证解决冲突之后,程序不会影响其他功能。

如果提交过程中产生了更新,则也是需要重新编译并且完成自己的一些必要测试,再进行提交。

 

保持原子性的提交

每次提交的间歇尽可能地短,以一个小时,两个小时的开发工作为宜。如在更改UI界面的时候,可以每完成一个UI界面的修改或者设计,就提交一次。在开发功能模块的时候,可以每完成一个小细节功能的测试,就提交一次,在修改bug的时候,每修改掉一个bug并且确认修改了这个bug,也就提交一次。我们提倡多提交,也就能多为代码添加上保险。

 

不要提交自动生成的文件

Visual Studio在生成过程中会产生很多自动文件,如.suo等配置文件,Debug,Release,Obj等编译文件,以及其他的一些自动生成,同编译代码无关的文件,这些文件在提交的时候不应该签入,如果不小心签入了,需要使用Delete命令从仓库中删除。

 

不要提交不能通过编译的代码

代码在提交之前,首先要确认自己能够在本地编译。如果在代码中使用了第三方类库,要考虑到项目组成员中有些成员可能没有安装相应的第三方类库或者没有放入GAC(针对.Net Framework)中,项目经理在准备项目工作区域的时候,需要考虑到这样的情况,确保开发小组成员在签出代码之后能够在统一的环境中进行编译。

 

不要提交自己不明白的代码

代码在提交入SVN之后,你的代码将被项目成员所分享。如果提交了你不明白的代码,你看不懂,别人也看不懂,如果在以后出现了问题将会成为项目质量的隐患。因此在引入任何第三方代码之前,确保你对这个代码有一个很清晰的了解。

 

提前宣布自己的工作计划

在自己准备开始进行某项功能的修改之前,先给工作小组的成员谈谈自己的修改计划,让大家都能了解你的思想,了解你即将对软件作出的修改,这样能尽可能的减少在开发过程中可能出现的冲突,提高开发效率。同时你也能够在和成员的交流中发现自己之前设计的不足,完善你的设计。

 

对提交的信息采用明晰的标注

+) 表示增加了功能

*) 表示对某些功能进行了更改

-) 表示删除了文件,或者对某些功能进行了裁剪,删除,屏蔽。

b) 表示修正了具体的某个bug

 

 

Tags: svn, 项目管理

同样的药,效果却截然不同

刚看到这个题目的时候,是不是觉得很奇怪?为什么这样的标题,它的TAG却是项目管理?事情要从博客园的某个博客说起,开始的时候我也以为是小孩治病方面的问题,后来才看出,确实是项目管理方面的。

仔细想想,确实和项目管理还有程序开发有关。说和做,提出方案和解决方案确实需要有一个全局把控的人。不能因为说A数据库不好,我们就换成B数据库,结果换到B数据库后还是不行;其实不是B数据库不行,而是不会配置B数据库而己。

原文地址:http://www.cnblogs.com/caidehui/archive/2008/12/18/1357692.html

内容如下:

     孩子病了,腹泻。去了儿童医院,开了药,吃了几天,没用。去了医大二院,也没用。昨天再去医大二院,换一大夫。大夫仔细的询问了病的情况,药的情况。

      开一方,无药,只有吃法。空腹、25ml水,服后半小时吃东西。其效入神,立时止泻。

      同样的药,效果确实截然不同的。这世上,庸医,良医原来只是这点不同。

    企业所面临的问题,也是如此。

      Review是经过业界多年,上千项目验证了的好东西。我们引进来也有年月了,可很多项目做的实在不到位,为什么呢?

      非项目之过也,实乃开方的人没有考虑如何有效的发挥作用也。  

      基于EV的进度管理,这个最佳实践,是进度管理中最重要的实践之一。我们引进后,还没有起到我想像中的作用。什么原因?非工具之过、使用者之过,乃我之过也。

      还有很多类似的情况,东西是好的,到了我们的手上就发挥不了作用,那是因为我们并没有真正的掌握其用法。

   对于那些怀疑药的作用的人来说,则是另外一个范畴的了。

      好多年前,中国的思想领域也是经历了一番挣扎的。现代的社会制度,多来之于国外的研究与实践。现代的经济体系,也多来之于国外。于是有守旧者埋怨有些人认为:外国的月亮比中国的圆;也有人高呼,其实外国的月亮不圆。

     这二者,我想其中应该有很大一部分不是谁比谁圆的问题,而是拿来以后如何应用的问题。既有遵循原来的精髓,又要在中国的环境中发挥作用的问题。

     OO、RUP来到中国的时候,不也是讥讽有之,尊崇有之吗?

      现在的中国社会看起来更成熟了一点,更开放了一点,更能容纳各种不同的思想了一点(这里不是指意识形态的问题)。所以类似的争论就少了,如何有效的应用的讨论就多了。

-------------------------------------------------

膘叔的话:你看完了,怎么想呢?你又会怎么做呢?从自身找原因?从别人身上找?唉。。不是你的项目,你管不了?总之,解决方案你自己心里有数吗?

Tags: 开发, 项目管理, 编程