移山之道

关注软件开发技术和管理的社区网站

欢迎光临 移山之道 登录 | 注册 | 帮助
in 搜索

关心

移山之道 作者

AgileChina 2009 / 敏捷中国 感想 (3)

Fred George

演讲题目:  it's a bird? it's a plane? no, it's superman

Fred 演讲完之后,我和他聊了好一会,请教了好几个问题,下面是我的笔记和感想:

1) 不必用很高深的工具和复杂的报表, 白板/Cardboard 成为了敏捷流程中简单而有效的项目管理工具.  团队成员使用简单的便签条来显示他们工作的进度。

Fred 推荐了两本书 "the soul of a new machine"  & "guns, germs, and steel"

项目管理人员如何成为项目的拖累 - 这帮人不断地问 "你做得怎么样了?"  记下别人的进度 (或者要求别人写每日每周进度) 然后向上汇总。  这些最大的汇总最后有人真正关心么? 

如果程序员不断地在多个项目中来回折腾,像CPU 不断执行各个进程一样,那这样的 context switch 会导致时间的浪费。 建议程序员最好专注于一个 故事/场景. 避免 multi-tasking.  有时候,光从 excel 表格中看不出来 multi-tasking 导致的浪费 - 可以说你被Spreadsheet 骗了。

问:  关于结对编程, 如果大部分团队中的成员都是新手,怎么办? 

答:避免让刚上路的新手之间结对,让成熟的程序员带领他们,等他们成长起来之后, 再结对。

 

问: 如果每个模块都是两人结对劳动的成果, 你如何衡量单个人的绩效呢?

答:没关系,结对的两个伙伴可以互相衡量对方.  如果项目时间足够长,每个人都会和足够多的同事合作过,会有足够多的评价信息。 

 

问:  我们每个员工都有自己的小隔间/cubicles,  而结对编程需要大家坐在一起,我们还需要另外的 "working zone" 空间让不同的人能坐在一起结对编程,这样岂不是比较浪费空间?  

答: 团队的效率比空间更重要, 我认为让合作的同事们并肩作战是提高效率的第一步。  当经过几次磨合,人们开始习惯和享受在 "working zone" 中编程时,  他们在自己的隔间中花的时间会很少, 我们可以让隔间/cubicle 变得更小,减少空间的浪费。

 

问: 在项目管理中,每个任务 (工作项/work item) 有大有小,但是在报表中他们都是一个同样的数字,这样看起来报表会欺骗读者,你怎么样避免这一问题,让报表如实反映真实情况?   

答: 把巨大的任务分成小的子任务,项目经理应该负责这样的事情,  估计子任务所需时间,通常会让人头痛,但是在我的经验中,这件事可以很快进行 - 相关人员像划拳一样,同时出手,比划任务大小,如果达到一致,则进行下一个. 

 

问:  看起来你希望大家很快估计出任务的长度,然后开始工作。 但是如果估计错了怎么办?  我们难道不要花很多时间仔细估计任务的花销么?   (还有一本书 Software Estimation 把估计工作上升到了 Black Art 的地步)

答: 我希望不要过分强调 “估计”的价值,因为它就是一个“猜”字。 “猜得准”不是我们的目标。 我们的目标是把软件写出来。  如果猜错了,没关系,微调项目进度即可, 不希望看到大家为了“猜得准” 而踌躇不前. 或者为了让当初的猜测看起来更靠谱而不如实报告进度。

 

问: 在你的演讲中我看到一个报表是显示 “waiting time/等待的时间”,怎么在项目中自动地做到这一点 (而不是人工去问) ? 

答:  在我的项目中,我有专门的流程和状态表示“等待”这一状态,  一个任务并不会自动跳过上一个状态而进入下一个人手上 - 要等到这个人有时间处理才行。  敏捷方法并不是一味地简化流程,或者消灭流程,我希望敏捷的流程能加入精确表达任务状态的各种字段和表现形式。

 

问: 在我们项目的实际中, 很多情况下,大家不敢让图表如实反映情况 - 那样会让人觉得 “你们并没有把项目管理好”。 所以很多burndown chart 看起来是一条完美的对角直线,而实际上并非如此。

答: 报表的目的是为了如实反映项目的进展,对老板,客户,利益相关者(stake holder) 都是如此。 如果你的报表能显示项目中很多 “等待” 的状态是由于测试人员不够所造成的, 那么你的老板会非常乐意替你解决这个问题。  如果你把问题都隐藏起来了, 给别人看的是完美的对角线, 那别人会认为你的项目不需要任何帮助,这对团队就更不利了.   

 

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

注:这是参加 AgileChina 2009 大会的感想,大会的情况如下:

AgileChina 2009大会报道与评论集锦:

http://www.infoq.com/cn/agile

大会现场图片集锦:

http://www.flickr.com/groups/agilechina2009

演讲资料下载:

- 敏捷大会所有演讲PPT下载:http://bit.ly/agilechina2009
- Kent Beck名师讲堂PPT下载:http://bit.ly/KBtraining

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

感想(1)  (2) (3)

已发表 2009年10月11日 23:23 作者 关心
归档在:,

评论通知

如果您想在帖子更新时接到邮件通知,请先登录。这里

订阅帖子评论使用 RSS

评论

 

匿名人士 说:

邹老师知道在ms内部有pair programming的实践么?或者有意向进行这种尝试么?

十月 13, 2009 8:49
 

关心 说:

尝试已经有很多了,  对一些人/团队来说, 这已经成为一个常态。 很多人分享了许多有意思的体验。  但是并没有一个教条或硬性规定 “某天开始所有人都要 pair programming”。

关键思想是 - 尽早review, 尽早test。

十月 13, 2009 9:49
 

匿名人士 说:

尽早review,尽早test,这个更近似于TDD了。

pair的思想,一个是driver,一个是navigator.但觉得在写代码以前,自己应该先充当navigator的角色想下一步的方向。难道真能分解成一个主要敲代码,一个思考这部分代码在整体项目中的位置和应用么?要找机会试一下。不过要pair的人都要有navigator的能力才行。

十月 13, 2009 22:57
 

匿名人士 说:

您好,敏捷大会所有演讲PPT下载,似乎无法下载,请问能否提供另外的下载地址?

十二月 22, 2009 11:18
 

关心 说:

@读者2009:

好像可以下载。 你的网络是不是有某种限制?

十二月 31, 2009 20:03

说说您的看法?

(必填) 
(可选)
(必填) validate code
(必填) 
发表

About 关心

邹欣 - 曾写: 《移山之道》,《编程之美》(合作) 。 在写: ppt, email。 想写: 《编程之美 - 实战中的设计》...

联合

Powered by Community Server (Personal Edition), by Telligent Systems
访问计数:     京ICP备06016978号
王屋村村民除了看yishan.cc, 还浏览下列网站.