2011年5月3日

软件项目经理新手上路(3) - 这不是份简单的工作

摘要: 绝大多数开发人员的职业目标都是成为项目经理。项目经理的工作看起来美好而简单,高工资,管人,还不用加班。但是它是不是像看起来那样美好呢?1. 小故事张三昨天向公司提出了申请,他还是想回去做程序员。张三做出这个决定也是经过长期考虑的。首先,在管人的新鲜劲过去后,张三再也找不到技术工作中那种成就感;其次,张三喜欢直截了当的沟通方式,但这种方式并没有得到项目团队的认同,前后有两位同事离职;最后,张三力图一切为了公司把项目做好,但项目显得不上不下,公司领导也反映平淡。好在张三的公司很开明,允许个人相对自由的进行工作选择,否则的话,张三就只有在项目经理岗位上继续坚持,直到离开公司。2. 常规想法张三真傻, 阅读全文

posted @ 2011-05-03 15:40 大卫张 阅读(10308) 评论(10) 推荐(4) 编辑

2011年5月2日

软件项目经理新手上路(2) - 力量从哪里来?

摘要: 技术冲突是技术出身的项目经理经常碰到的事情。一开始只是技术讨论,讨论着讨论着就变成了技术冲突。1. 小故事张三最近的心情很糟,这起因于一次技术争论。在解决一个技术问题的时候,张三和李四的设计不同。从张三的角度来看,李四的设计简直糟糕透顶,但却怎么也没有办法说服李四。于是张三就小小的动用了项目经理的权力,强制使用了自己的方案。没想到遭到李四的强烈抵制,到最后李四竟然提出了辞职。张三也因此受到了领导的批评,所以他很郁闷。他怎么也想不通,他为交付更好产品的努力竟然导致这么个结果。2. 常规想法这是个令人头疼的问题。大多数新手项目经理都来自于开发,他们之所以成为项目经理就是他们的技术研发能力比较优秀。 阅读全文

posted @ 2011-05-02 18:06 大卫张 阅读(5061) 评论(9) 推荐(3) 编辑

软件项目经理新手上路(1) - 序

摘要: 软件项目经理,这是广大开发人员向往的职位。随便抓个开发人员问问他的职业规划,他会告诉你“我的计划是现在专心做开发学技术,3年到5年的时间后转向管理。”在开发人员看来,项目经理的收入更高,加班更少。然而在绝大多数公司你都可以找到足够多的技术培训,却没有针对项目经理的培训。看来要成为项目经理,一切都要靠自己摸索。有没有这样一本手册,只要读了它就能提高管理能力?我的偶像温伯格提到过一本,并且推荐《门后的秘密》,然而这本书的内容对于新手项目经理而言过于高深。于是萌发了自己写点东西的想法。这本小册子由一系列故事组成。大部分故事的主人公叫张三,是一位项目经理,刚因为优秀的开发能力而被提升。有时故事的主人公 阅读全文

posted @ 2011-05-02 18:04 大卫张 阅读(3254) 评论(4) 推荐(6) 编辑

2011年4月27日

C项目敏捷实施(3)-5个迭代了

摘要: 时间过得飞快,转眼间C项目已经来到了第五个迭代。在第五个迭代,C项目的情况如何呢?答案是还在磕磕绊绊。 对很多人来说,这种敏捷实施的成果是难于接受的,实施这么久了,还在磕磕绊绊。实施敏捷看起来就像一场运动,人们总期待实施敏捷有个结束的时间,但是这就是敏捷,实际的敏捷。(敏捷不仅是马拉松,它还永不结束。) 记得以前听Scrum的讲座,敏捷的三大支柱之一就是透明性。意思就是,敏捷本身不解决问题,它能在实施过程中让问题不断的暴露出来。敏捷社区有个形象的提法,“水落石出”。 解决问题依赖于组织自身。然而对大多数组织来讲,都没有做好不断面对问题并解决问题的准备,实施敏捷磕磕绊绊甚至失败也就是意料中事了. 阅读全文

posted @ 2011-04-27 09:24 大卫张 阅读(2542) 评论(3) 推荐(0) 编辑

2011年3月21日

C项目敏捷实施(2)-第一次迭代

摘要: 就这样,C项目组糊里糊涂的开始了敏捷之旅。在第一个迭代完成后:基本情况2011年2月21日-3月4日,项目组成员每天站在白板前进行每日站立会议。如果发现了需要讨论的话题,就在会后进行讨论。2011年3月4日,项目组进行了第一次回顾会议。没有评审会议了,因为项目组仅完成了预估工作的不到一半,仅提供了一个Demo。第一次回顾会议团队在白板前进行第一次迭代回顾,会议总耗时一个小时。会议结果如下:1. 做得好的a)成功完成Demo,所有Bug都修复了。b)每日站立会议对团队有很大帮助,可以清楚知道团队其他成员在做什么。团队协作比以前更好了。c)感谢美国团队的及时响应。d)感谢团队成员的认真负责,开发和 阅读全文

posted @ 2011-03-21 11:49 大卫张 阅读(1982) 评论(0) 推荐(0) 编辑

2011年3月12日

敏捷项目实施,你准备好了么?

摘要: 敏捷是最新的流行趋势,如果你还没有在用,那值得一试。不过在开始前,最好先确认一下你准备好了么。下面分享一点个人经验。1.为什么引入敏捷?这是一个目标设定问题。仅仅因为敏捷很流行,希望学习,还是因为敏捷是另一个“银弹”。很简单的一个标准,如果没有目标,怎么能够确认成功?所以在实施敏捷前问问为什么会对你非常有帮助。1) 你所在的项目没有任何问题什么,居然有这种项目,不太可能吧。那么不妨将敏捷实施的初始目标定为发现问题。引入迭代,定义“完成”,敏捷可以帮助你让问题浮现出来。2) 你所在的项目有一个或几个明确的问题这一个或几个明确问题往往是很难解决的、相对长期存在的问题,可以把它们作为敏捷实施的目标。 阅读全文

posted @ 2011-03-12 22:04 大卫张 阅读(629) 评论(0) 推荐(2) 编辑

2011年3月9日

C项目敏捷实施(1)-第一次计划会议

摘要: 本系列将记录项目中引入敏捷的过程和相关的一些思考,欢迎进行交流。流水帐2011年2月16日前,与项目经理和开发组长进行过两次前期交流。2011年2月16日,公司领导确认对项目进行过程改进,确定由我协助项目进行改进。2011年2月17日,与中国团队的项目经理进行面谈,确定引入迭代开发模式。2011年2月18日,与中国项目团队进行第一次迭代计划会议。会议会议总耗时两个半小时。团队坐在一个白板前,使用即时贴记录Backlog的工作项和分解后的任务。主要会议内容:简要介绍迭代开发模式,确定每2周一个迭代,每天上午10:30召开每日站立会议对需求进行优先级排列,形成最简的产品Backlog团队对产品Ba 阅读全文

posted @ 2011-03-09 14:36 大卫张 阅读(889) 评论(0) 推荐(0) 编辑

2011年2月21日

换个角度看敏捷3 - 我心中的敏捷

摘要: 心中的敏捷“敏捷是什么”,这个问题长期以来一直困扰着我。前段时间提出了敏捷问题解决方式,算是从做法(做事的方法)上对敏捷进行了一个简单的总结。最近一直在清理,这就试图描述一下我心中的敏捷。因为个人一直从事软件开发工作,所以文中的主体部分有一些与软件开发相关的经验,不能做到完全的通用化。我心中的敏捷从信仰、理论到实践与方法学,这就是我心目中完整的敏捷知识体系。敏捷信仰主要内容敏捷信仰,也可以被称为敏捷世界观,源于经验主义或逻辑实证主义。其主要内容包括:世界是复杂的和不断变化的,人是导致复杂和变化的主要原因敏捷对此使用的词汇是我们不能预测未来。这看似不可知论,但其实这句话的意思是我们无法准确预测变 阅读全文

posted @ 2011-02-21 16:51 大卫张 阅读(907) 评论(0) 推荐(1) 编辑

2011年1月30日

换个角度看敏捷2-敏捷软件开发概述

摘要: 敏捷软件开发概述如同前文所述,可以把敏捷看做一种问题解决方式。下面我们就从敏捷问题解决方式的角度解读敏捷软件开发。敏捷软件开发软件开发是问题本身和问题解决能力不确定的一种典型情况。软件项目起源于人的构想,随着时间不断变化。项目团队对项目的认识随时间不断加深,成员能力不断提升,工作方式和过程改变导致团队开发能力不断变化。敏捷软件开发分为3个层次。产品层1.问题与问题参与者问题是产品构想。问题提出者是客户(业务负责人),问题解决者是特性团队。2.问题分解与检验a)问题分解将问题从产品构想分解到业务特性。业务特性是问题提出者客户可检验的单位问题。b)问题检验在可工作的软件中检验完成的业务特性。可工作 阅读全文

posted @ 2011-01-30 14:59 大卫张 阅读(411) 评论(2) 推荐(0) 编辑

换个角度看敏捷1-敏捷问题解决方式

摘要: 敏捷问题解决方式敏捷是什么?这是我一直在思考的一个问题,同时也在敏捷之旅2010成都站提出。这似乎是一个不值得推敲的问题,敏捷就是“敏捷”。但为何某些实践可以称为敏捷实践?方法学可以称为敏捷方法学?是不是存在一根看不见的线把这一切关联起来?这让我如此着迷,没有什么能够比寻找答案更让人着迷了。下面就是我的尝试,肯定不完善,但即使是小小的帮助也是一个进步。作为问题解决方式的敏捷“敏捷”是一种问题解决方式,是在问题本身或问题解决能力不能确定的情况下取得尽可能好的结果(近优解或更优解)的问题解决方式。基本做法1.角色划分在敏捷问题解决方式中,问题提出者的作用得到强调。问题被按照问题提出者可理解、可检验 阅读全文

posted @ 2011-01-30 14:33 大卫张 阅读(907) 评论(3) 推荐(0) 编辑

导航