分类：项目管理
敏捷相关
《PMBAR》创刊
热烈庆祝实践型公益项目管理社区PMBAR(http://www.pmbar.net)的项目管理专业杂志《PMBAR》创刊，首刊下载地址为：
项目管理5大过程组+42个项目管理过程
隆重推荐国内第一本项目管理的实践书籍——《IT项目管理那些事儿》
我看敏捷
我是一个写了十几年代码的老程序员了，至少在2010年5月之前，我从未间断过coding。下面谈谈我自己这十几年的程序员生涯对于敏捷的一点浅薄的理解。
1.敏捷我不认为是什么思想，CMMI叫软件成熟度模型，那敏捷也就是一种轻量级的软件开发模型或者叫开发方法，冯 诺依曼的二级制是一种思想，但是敏捷不是。
2.敏捷为什么会出现，个人认为敏捷是为了应对需求的多样性及产品的快速更新的一种手段和方法，这也是我一直认为互联网公司可能更适合借鉴和使用敏捷，但是同样就是在互联网公司内，也不是所有的产品都适用，至少像很多互联网公司都有庞大的后台服务和底层技术支持，这部分我认为并不适宜。
3.其实我们已经在敏捷了，不管知道敏捷还是不知道敏捷，我们很多时候都已经在使用敏捷里经常提到的快速迭代，我自己至少就经历过，在曾经服务过的一家互联网公司，我们每周都会有一次上线，因为互联网产品是永远Beta的，因为我们不可能花三个月甚至更长的时间就能拿出一个让用户满意的产品，因为你根本做不到，所以我们需要试错，我们需要快速的拿出我们的产品，让用户告诉你，你哪儿做对了，哪儿做错了，所以我们需要以更快的产品周期来开发（现在很多移动应用的产品周期可能就是2,3天或者更短），我们让产品人员，测试人员，开发人员形成了一个战斗队伍，我们会让测试人员第一时间介入到产品中来，我们也会让产品人员随时跟踪产品进度，我们也会采用一些自动化的方式来保障开发质量，提高测试效率，保证一次性部署成功。
4.敏捷不可能提高研发能力和研发质量，至少我看了半天，也没看到从哪儿能看出敏捷可以提供研发能力和研发质量，研发能力是取决于研发团队的个人能力的，而这种个人能力，不是简单的能够通过一种方法可以提高的，并且很多研发技能，就我自己的了解，就是需要一些高手来引导的，而且还得看每个人的悟性，有人真的能提高，有的人可能真就不行，我自己带过的人就有这样的例子，我相信那些高手很多都不知道敏捷吧，而且敏捷也不可能让你在网络编程方面有提高吧，至于说研发质量，我的理解，研发质量可能是代码质量+测试质量，这两部分有很多手段来提高，比如codereview，比如各种检查工具，单元测试工具，自动化测试工具，但是应该不是敏捷能做到的。
5.敏捷好吗，好，但是敏捷和CMMI一样都是因为某种开发场景而诞生的，他们都有自己适用的场景，就像我们做开发的经常会听到这样的论调“XXX语言就是好”，“XXX架构就是强”，其实最适合的语言和架构就是最好的开发语言和最好的架构，同样再采用一种新的语言和架构来改造你目前的系统时候，你也必须对于新语言和新架构非常的了解，否则它不断不会带来好处反而是致命的后果，敏捷也同样，如果认为敏捷适合，那也需要真正理解敏捷，能够正确使用它。那种把敏捷当红宝书，当放之四海而皆准的真理，我真的不能苟同。
不管敏捷还是非敏捷，能够满足你需要的就是好方法。
你会使用什么样的项目管理工具
前段时间自己在微博上发起了一个关于常用的项目管理工具小调查，利用的是新浪微博的投票功能，罗列了 MS Project 、JIRA、Trac、XPlanner、Redmine这5种，个人认为可能比较常用的项目管理工具，因为自己的影响力有限，整个投票一共有37人参与，但是从最终的投票结果，多少也能反应出一些东西
从上面这个图可以看出大家使用最多的依然是微软的产品，虽然现在很多人对于微软的东西都会很鄙视，但是无法否认的一个事实是，因为Windows，因为微软产品的使用配置都相对来说比较傻瓜化，所以依然是我们的首选使用产品。78%的使用比例是最好的证明。JIRA的10%使用比例，说明JIRA正逐步成为很多人的首选，我服务的两家公司都采用了JIRA作为项目管理工具，JIRA是一个商业产品，但是在天朝这都不是问题，相信很多人使用的都是破解版
，而Trac，XPlanner，Redmine感觉在一些互联网公司，特别是采用敏捷方法进行项目管理，使用的比例比较多。随着现在云概念的火热，出现了云商务、云存储、音乐云等等，相信也会有项目云，基于云概念的项目管理平台，所有的项目管理都可以构建在云上。
也谈自动化构建及部署
之所以谈到这个问题，源于跟公司QA同事谈到了项目管理中流程管理，流程管理里面很重要的一个环节就是实现测试部署的自动化，提高产品的整体研发效率。下面就简单谈谈我自己的经历过和理解的自动化构建及部署。
04年在一家台湾公司的时候，第一次接触了自动化构建，当时公司做的是客户端软件，使用的版本控制工具是VSS，开发工具是VC6，之所以会提出软件的自动化构建，是基于测试部提出，由于原来的测试包都是由开发人员在自己机器上编译后再提交给测试，但是经常会出现的问题是，测试人员发现开发人员提交的测试包根本无法测试，然后查到的原因，往往是因为开发人员自己的机器环境跟测试机环境不一样导致，比如开发人员本机安装了某个类库，他使用的某个方法恰恰又依赖这个库，但是他自己又 不知道，或者忘了把这个库也打包进去，所以才出现了测试人员无法测试的情况。为了改善这种状况，当时提出了写一个批处理，实现自动化构建，当时自己承担了这个任务，当时实现的只是一个简单的自动构建，基本原理是，在一台build机器上首先按照lable，从vss库checkout代码，然后运行nmake命令编译代码，这里面需要利用vc6生成mak文件并上传到vss，如果编译成功，则把编译生成的包拷贝到指定的测试机的目录，目录名按照产品名+日期来命名。如果编译错误，则需要上build机器查看输出的错误。这部分都写成了一个批处理，批处理接受参数，参数由要构建的产品名（vss上的名一致），要构建产品的lable，每次完成一个测试版本开发后，开发人员把该上传的都上传到vss，并打上lable，然后邮件通知测试人员，邮件内容主要是测试的产品名称和lable，测试人员根据邮件，运行build机器上的批处理程序，然后根据测试机器上是否正确生成了测试包来判断本次构建是否成功，如果没成功通知相应开发人员进行检查，下面是该批处理的部分代码
这个自动化构建还需要完善的是增加一个构建结果的邮件通知机制。
其后05年进入了一家互联网公司，在这里有幸接触了互联网应用的自动化部署，其中当时自己负责的一个会员管理后台，采用的是.net开发，vss进行版本控制，部署在IIS上，同时公司另外一个业务是java开发，cvs进行版本控制，部署到apache，这部分我虽然不负责，但是也接触到了相关脚本的构建。这里面的基本部署原来，也是跟之前的类似，稍有不同的是，这里面的自动化脚本可以分别生成内网测试包和外网测试包，分别用于进行内网测试验证和外网测试验证，同样这部分也是由测试人员控制，开发人员在完成一个测试版本开发后，邮件通知测试人员即可。
这里写这么多关于自动构建和部署，要说明的一点就是，我们要提高效率，改善流程，很大程度就是把人做的工作交给机器来做，人可能会因为各种原因犯错误，比如今天心情不好了，或者今天心情太好了，多可能会使自己在部署过程中产生错误，而如果是由脚本来完成，如果脚本本身没有问题，那这种犯错误的几率接近于零。曾经看过一篇文章，讲到了twitter全球几千台机器的部署只需要短短几分钟就能完成，都是有赖于他们的自动化部署，这里面需要我们参考的就是如何改进和提高这种自动化部署，使其也能在最短时间内完成部署并且实现零错误。自动化构建或者部署，因采用的开发语言不通，版本控制软件不同会略有区别，比如java本身就带有ant，而linux下的c或者c++服务程序则可以通过cmake，而所有的版本控制无论vss、cvs、svn、git都有命令行方式，因此自动化部署的基本原理类似，只需要我们之前多花点时间把这个部署脚本构建好，那就是一劳永逸的。
项目管理随想
几天前在微博上问了几位朋友一个问题，项目管理的正常步骤都是原生态=》标准化=》返璞归真。
其中原生态，就是公司虽然有项目概念，有项目经理的职位，可能有些人也潜意识的在按项目管理流程走，但是总体来说，还是处于一个原始状态，或者说是大部分人心中并没有项目管理的概念；
其次标准化，很好理解，就是很多公司都会采用一种流程严格，角色细分的方法来实现标准化，常用的可能就是CMMI，PSP，TSP等等，这些方面的特点就是通过流程来规范人的行为准则；
最后返璞归真，就是团队内的成员都已经形成了对项目管理的深度认识，已经经过过标准化的洗礼，团队成员的素质普遍比较均衡，这个时候，往往再使用流程来规范人，以流程为中心，往往会限制人的主观能动性的发挥，这个时候，就适合采用以人为中心的敏捷开发方法，常见的就是XP，TDD，SCrum等等。
我的问题就是，我们是否能够实现从原生态=》返璞归真的直接跳跃，或者说我们尽可能的缩短标准化的这个时间，非常感谢我的很多朋友给我的宝贵建议，总体来说，大概就是两类看法，一种认为这种可能性基本不存在，人的惰性是天性，离开了流程和标准的制约，只能成为一盘散沙；另外一种看法是书从薄到厚，再从厚到薄，无法一蹴而就的，聪明的人，能让这个时间短点，普通人就得需要较长时间。团队也如是，只不过这时的判断指标就是团队的成员素质＋学习交流能力了。我个人倾向于后一种看法，我自己也正好碰到了这样的情况，希望自己能够按照后一种说法去实现。最后再次感谢这些朋友给我的建议。
Scrum，互联网公司的最佳开发方法
Scrum，本意是英式橄榄球，Scrum里的一个重要周期叫Sprint，意为冲刺期。Scrum是敏捷体系里的一种具体实现，就如XP、TDD等一样。
接触Scrum也是10年8,9月份的时候，之前对敏捷也有所了解，对XP，TDD也做过了解，但是在接触了Scrum后，感觉Scrum就是为互联网企业而设的，虽然Scrum本身在90年代已经诞生。说Scrum是为互联网企业而设，更应该从互联网产品本身的特质说起，当今中国的互联网瞬息万变，时间决定市场，用户形成壁垒，因此互联网的产品应该说永远Beta，目前很多企业以都会以“天天Beta”来作为一种Slogan，激励产品的研发人员一定要保持一个高速的状态，一刻不能松懈。互联网产品与传统行业类软件产品已经有了很多本质区别，其一，需求更加多样化，更大的不确定性，传统行业软件，面对肯能就是这个行业的从业人员，其需求基本根据行业特点本身而来，而互联网软件产品，面对是中国几亿的用户，其需求可也说千变万化，所以说我们的产品经理永远不可能做出一个70乃至80的产品，70分80分的产品只有在你刚及格的产品面对你的用户后，再和用户的不断迭代中完成70分80分的产品，其二，互联网的产品，往往是谁更早的推出面向用户，并配以合理的运营手段，谁就可能迅速形成用户壁垒，从而成为市场的NO.1或者至少是前几名，因此单产品开发周期就要求不可能像传统软件产品一样，需要更短的开发周期，更快速的响应。其三，互联网产品的成败很到程度在于你是否拥有优秀的产品团队，并且应该是一个以产品经理为核心去构建研发团队。其上三点，应该说恰恰是Scrum的基本要素，Scrum中有PO，Scrum master和开发团队，三种角色，而PO是其中的核心，一切以PO制定的Product BackLog为基础，并由PO来决定Product BackLog的优先级进行开发。Scrum中的Sprint周期建议就为2-3周左右，目前大部分互联网公司的产品更新周期一般也是在2周左右，最后，Scrum本身就是一个不断迭代的过程，虽然在每一个Sprint内不建议做需求变更，而是建议放入到下一个Sprint周期，因为Sprint周期本身也就2-3周左右，因此基本能够满足互联网产品的迭代需求。总之在互联网企业内如果要进行过程改进，Scrum应该是最佳选择。