工作进度反馈，有一种更优雅的方式吗？

工作进度反馈，这是站在员工角度的一种描述。如果站在管理者的角度，是工作进度跟踪，它的目标是为了让项目进度可控，从而降低项目风险。
它的表现形式是日报、周报，工具可能是在线填报、excel表格、甘特图进度更新、每日邮件、纸质表格等等。
本来，这个目标的动机无可厚非，但进度跟踪只是让项目进度可控的一种手段，而绝非目标。但给员工的感觉是，领导在监视他，甚至是季度发奖金的依据。所以，出于一种本能的自我保护，员工会虚报或谎报。
以我几年的经历，以及对其它公司的了解，我基本上没有发现有一个团队时积极主动地配合。

对于管理者，填日报或周报的动机，一般有以下几种：
1、了解项目进度，以便及时调整
2、根据工作日志，了解员工的工作负载及效率，以便改进绩效
3、观察团队各成员，看有没有偷懒的，做绩效考核时的依据
4、根据日志记录的工时，决定本月的薪水
5、根据日志记录的工时，以便部门向总公司要人月开支

以上几种我都经历过，虽然1和2是比较积极的，但员工的配合意愿还是很弱。
我觉得，最核心的原因是，管理者和下属之间，并没有真正建立信任。
对于1，难道只有工作日志这种手段吗？软件开发，不像建筑业，每天的工作进度，是可以用眼睛来观察的，并且进度几乎是线性递增。软件开发，特别是设计和核心模块的开发，一周的工作，很可能是前四天只完成功能进度的40%，后一天完成60%。如果项目经理不懂这些规律，他看到那40%，肯定是心急如焚。
怎么解决经理的焦虑呢？也许最好的办法是，每日及时沟通和下属主动反馈。但前提是，彼此间的信任。否则，下属感觉经理在催工，或者下属也没有反馈的勇气，因为自己四天才完成40%。
对于2，即使员工每天坦诚反馈，但对于项目经理，查看这么多人的日志，工作量很大，加上自己一忙，就忘了，反正也没人监督。但几周后，员工发现他写的日志只是一个摆设，于是也没有记录的热情了，一两句话了事。
对于3、4、5，就不用说了，员工会徘徊在职业道德的边缘。

对于工作进度反馈，在敏捷过程Scrum里，有每日15分钟的站立晨会，这是不用填工作日志的，呵呵。它的目标是团队间工作进度的沟通和协调。当然，它有敏捷宣言做前提。我觉得，如果生搬硬套也不太靠谱，理由有两点：
团队中可能存在一些技术新手，他们每天完成Scrum Master的期望进度不太现实，所以压力会非常大，导致工作时焦虑，而不是Scrum Master期望的强烈目标感。
有些工作是无法每天汇报进度的，特别是偏研发、技术攻关型任务，同样也会让某些成员焦虑、浮躁。
大家知道，软件开发最好的状态是relaxed、relaxed、relaxed。

还有一种方法，就是IBM Rational里面的ClearCase和ClearQuest集成，开发人员每天的工作成果，就是commit自己的代码，也就是ClearCase的提交操作(类似于CVS/SVN)，而提交时，正好用到ClearQuest这个任务日志记录工具，也就是说，提交时，一定要选择当初项目经理给安排的一个任务。这也就避开了任务日志要在任务执行后记录的烦恼。总之，下班后最后一件事情，是commit自己的成果物(代码或文档)，而不是打开公司的任务系统记录工作日志。
但IBM这套工具，特别是ClearCase太昂贵，另外学习和部署成本太高，对于小团队太重了点。

对于我们小团队，在经历了各种进度反馈方法后，比如Jira工作日志、每日邮件通知、甘特图更新，我还是回到探寻问题的本源：不就是想了解项目进度和团队状态吗？而了解项目进度和团队状态，不就是为了项目进度可控和提升团队绩效吗？如果团队齐心协力、自动自发做事情，那还需要狠抓进度跟踪吗？
所以，我采取走动式沟通。当然这只是一种辅助，因为当团队超过六人，加上自己也承担具体开发任务，很容易拖延。
最重要的方法是，培养团队凝聚力+强化目标感，而在团队凝聚力(责任感+主动性)培养中，最重要是形成一种开放、信任、分享的氛围。
这东西有点虚，但效果实实在在。因为，你会发现，员工在一个任务阶段后，会主动口头给你反馈。不过，我们目前还是没有达到理想的状态。

但我这种方式，并不适合大公司，特别是大型团队，因为它们更倾向于制度化管理。它们的日常管理工作，不应该依赖于管理者的个人英雄主义。
如果有一个项目立项，临时组建一个团队，要培养彼此间的高度信任，何其难。因为信任的建立，是一条漫漫长路。

评论

94 楼 JohnsonTech2011 2011-06-18  

信任的建立，是一条漫漫长路。

93 楼 dreamkyh 2011-06-08  

一周写一次周报就可以了，天天日报很烦的，弄的跟监督一样，还要整理给老板看，妈妈的，现在没事情做的时候，我都不知道写点什么了啊，都要找点事情随便写上去，经理真恶心

92 楼 wwccss 2010-09-01  

到这个帖子讨论，这其实敏捷开发的内容。：） http://www.iteye.com/topic/752330

91 楼 iamlotus 2010-08-31  

wwccss 写道

引用

乐观地说，当前水平能够正常实施TDD的团队，国内不超过三分之一。

不要说三分之一，估计十分之一也不到。

引用

TDD是XP的核心。TDD要求程序员能够客户沟通，整理需求，构造用例，规划代码。这本身就不是所有程序员都能做到的。所以XP也并不适合所有水平的开发团队。乐观地说，当前水平能够正常实施TDD的团队，国内不超过三分之一。那剩下的三分之二呢？你就老老实实的搞你的瀑布吧！可是敏捷听起来多煊啊，这时候就冒出所谓“可裁剪的，灵活的敏捷开发方法”，也就是SCRUM了。

常识性错误。几篇文章，介绍scrum和xp出现的时间。
http://zh.wikipedia.org/zh-cn/Scrum
http://zh.wikipedia.org/zh-cn/极限编程#.E5.8E.86.E5.8F.B2

引用

1986年，竹内弘高和 野中郁次郎阐述了一种新的整体性的方法 ，该方法能够提高商业新产品开发的速度和灵活性：[1]
他们将这种新的'整体性方法与橄榄球相比较，前者各阶段相互重叠，并且由一个跨职能团队在不同的阶段完成整个过程，而后者整个团队"tries to go to the distance as a unit, passing the ball back and forth"。
他们对来自汽车，照片机器，计算机和打印机等产业的案例进行了研究。
1991年，DeGrace和Stahl在《Wicked Problems, Righteous Solutions》[2]一书中将这种方法称为 Scrum，在竹内弘高和 野中郁次郎的文章中提到的橄榄球术语。
1990年代初，肯·施瓦伯在其公司使用了一种方法Advanced Development Methods（先进开发方法），这种方法后来发展为Scrum。
同时，杰夫·萨瑟兰在Easel公司开发了一种类似的方法，并首次称之为Scrum。[3]
1995年，在奥斯汀举办的OOPSLA '95上，萨瑟兰和施瓦伯联合发表了论文首次提出了Scrum概念。施瓦伯和萨瑟兰在接下的几年里合作，将上述的文章，他们的经验，以及业界的最佳实践融合起来，形成我们现在所知的Scrum。
2001年，施瓦伯与 麦克·比窦（Mike Beedle）合著了《敏捷软件开发-使用Scrum过程》一书，介绍了Scrum方法。

scrum的概念早于xp提出。只不过国内的开发人员接触的xp反而比scrum要早。说是scrum是为了避免xp的问题而推出的，就大错特错了。

scrum和xp不矛盾。一个是面向宏观的管理，一个是面向具体的开发实践，两者可以很好的结合。

我想我大概能够明白je上面的朋友为什么对 scrum有很多的偏见了。因为大家都是开发人员，更多的是站在开发的角度来谈论这个问题。

我也和PM交流过对于SCRUM的看法。确实，从项目管理的角度说，SCRUM本身强调短周期的迭代，通过为期一到两周的sprint，事先的评估以及持续的追踪，使PM对于开发过程比更长周期的迭代把握的更清楚。这点也是PM认同SCRUM相对以前流程的优势。
我只是认为小步快跑原本是所有敏捷方法所提倡的。但没有TDD作为基础，即使你能小步，却无法快跑。因为新的需求总是不断出现，没有TDD，大多数developer合乎理性的选择就是通过补丁的方式加外挂。长期下来必然造成维护难度提高，也自然无法真正拥抱变化。这也是随着软件开发时间变长，系统越来越难以维护的根本原因，而SCRUM自身并没有对这个问题提出解决方法。
站在我的角度，SCRUM是一个不错的，也相对容易施行的软件开发流程。在我们这样水平的团队中，相比于瀑布或者RUP，它有着不错（至少不会更差）的效果。但这个方法本身没法解决“拥抱变化”这个敏捷的核心问题，所以我认为不应称其为“敏捷”方法。
也正如您所言，这是看问题的不同角度，不过世间争执原本也就是角度不同罢了。

另外关于

引用

常识性错误。几篇文章，介绍scrum和xp出现的时间。
http://zh.wikipedia.org/zh-cn/Scrum
http://zh.wikipedia.org/zh-cn/极限编程#.E5.8E.86.E5.8F.B2

不要说国外怎么样怎么样，在国内SCRUM就是作为一种“容易掌握的敏捷方法”粉墨登台的。如果这个都不相信，那只能说您是生活在象牙塔里面了。

90 楼 wwccss 2010-08-31  

引用

乐观地说，当前水平能够正常实施TDD的团队，国内不超过三分之一。

不要说三分之一，估计十分之一也不到。

引用

TDD是XP的核心。TDD要求程序员能够客户沟通，整理需求，构造用例，规划代码。这本身就不是所有程序员都能做到的。所以XP也并不适合所有水平的开发团队。乐观地说，当前水平能够正常实施TDD的团队，国内不超过三分之一。那剩下的三分之二呢？你就老老实实的搞你的瀑布吧！可是敏捷听起来多煊啊，这时候就冒出所谓“可裁剪的，灵活的敏捷开发方法”，也就是SCRUM了。

常识性错误。几篇文章，介绍scrum和xp出现的时间。
http://zh.wikipedia.org/zh-cn/Scrum
http://zh.wikipedia.org/zh-cn/极限编程#.E5.8E.86.E5.8F.B2

引用

1986年，竹内弘高和 野中郁次郎阐述了一种新的整体性的方法 ，该方法能够提高商业新产品开发的速度和灵活性：[1]
他们将这种新的'整体性方法与橄榄球相比较，前者各阶段相互重叠，并且由一个跨职能团队在不同的阶段完成整个过程，而后者整个团队"tries to go to the distance as a unit, passing the ball back and forth"。
他们对来自汽车，照片机器，计算机和打印机等产业的案例进行了研究。
1991年，DeGrace和Stahl在《Wicked Problems, Righteous Solutions》[2]一书中将这种方法称为 Scrum，在竹内弘高和 野中郁次郎的文章中提到的橄榄球术语。
1990年代初，肯·施瓦伯在其公司使用了一种方法Advanced Development Methods（先进开发方法），这种方法后来发展为Scrum。
同时，杰夫·萨瑟兰在Easel公司开发了一种类似的方法，并首次称之为Scrum。[3]
1995年，在奥斯汀举办的OOPSLA '95上，萨瑟兰和施瓦伯联合发表了论文首次提出了Scrum概念。施瓦伯和萨瑟兰在接下的几年里合作，将上述的文章，他们的经验，以及业界的最佳实践融合起来，形成我们现在所知的Scrum。
2001年，施瓦伯与 麦克·比窦（Mike Beedle）合著了《敏捷软件开发-使用Scrum过程》一书，介绍了Scrum方法。

scrum的概念早于xp提出。只不过国内的开发人员接触的xp反而比scrum要早。说是scrum是为了避免xp的问题而推出的，就大错特错了。

scrum和xp不矛盾。一个是面向宏观的管理，一个是面向具体的开发实践，两者可以很好的结合。

我想我大概能够明白je上面的朋友为什么对 scrum有很多的偏见了。因为大家都是开发人员，更多的是站在开发的角度来谈论这个问题。

89 楼 iamlotus 2010-08-31  

daquan198163 写道

没有极限编程的最佳实践（如tdd、重构、ci）支持，scrum就会变成“行为艺术”，呵呵

  这也是我一直的观点：没有XP，SCRUM当然可以作，当然也可以出结果，当然也可以让PM有虚假的安全感。但是这样的SCRUM相对于RUP等方法论来说得不到实质上的提高。
  我当年之所以对TDD一见之下大为赞赏，并去学习和尝试，正因为TDD是能够解决实际问题的一种方法。尽管未必同意PP等方式，但TDD,refactor,CI等确实给我带来了安全感，使得我每次check in代码时不用去想到底要花多少时间改bug，也能够自然而然的敢于并乐于做重构，并进而用于使自己的代码贴近需求。
  TDD是XP的核心。TDD要求程序员能够客户沟通，整理需求，构造用例，规划代码。这本身就不是所有程序员都能做到的。所以XP也并不适合所有水平的开发团队。乐观地说，当前水平能够正常实施TDD的团队，国内不超过三分之一。那剩下的三分之二呢？你就老老实实的搞你的瀑布吧！可是敏捷听起来多煊啊，这时候就冒出所谓“可裁剪的，灵活的敏捷开发方法”，也就是SCRUM了。
  你不是不能搞TDD嘛？SCRUM中从标配改成选配了，你不搞TDD就不敢重构？没问题，咱把重构改成“持续改进”了。分个sprint，早上开个会，这样具有“可操作性”的步骤谁学不会啊。于是乎，无论阿猫阿狗都能通过SCRUM的便车走上敏捷的康庄大道，从此过着幸福快乐的生活了。
  可是对这个“持续改进”，我始终没明白该怎么实现。我只知道我的同事们在“SCRUM without TDD”中，每次选择方案时总是选择对原系统改动最小的打补丁的作法，而不是将系统按照最新需求改造，因为risk，QA不想改，developer不愿改，连PM都倾向于不要改。每次改点东西都搞得和打仗一样紧张，这和以前的流程又有什么差别呢？
  我觉得吧，之所以这么多人反对SCRUM正是因为SCRUM trainer把它放在了一个不恰当的位置。 如果把XP当成core的话，你把SCRUM定位成一个shell那是一点问题也没有，“如果你团队中的成员能够并且乐于实施XP了，那么我有这样一些方法可以帮你的团队更方便的融入敏捷开发，这些方法的集合称为SCRUM”，这样说相信没人反对。 可现在SCRUM的定位是另外一个core,"就算你搞不了XP,咱也能把你带入敏捷的门"。这样一来，对于那些实际没有搞XP（这是大多数）的团队来说，SCRUM真就是个花花架子了。
 

88 楼 wwccss 2010-08-31  

本来无一物，何处染尘埃，我想大家都还到不了那个境界。我作事情，或者学习东西，经过研究认为这个东西是可行的，我就会一直坚持下去。不动摇，不放弃，彻底的把这件事情做透。

比如我现在创业作公司，我就是按照罗伯特.T.清崎的如何创业那本书做。肯定有朋友说了，那个哥们是骗人的。hoho。如果什么都不相信，肯定什么也做不了的嘛。从07年开始按照这本书准备，到现在成立公司，有了自己的产品，团队，商标，法律授权，现在正在实践现金流方面的东西。也许几年过去，可能会失败。不过这个过程我走过了。学到了东西。

说到中国足球，你还真别说。米卢带领国家队的时候，也没有什么特殊的管理方式，就是快乐足球，就出去了。 所以，要相信自己选择的东西。后来呢，看国家队换来换去，始终没有自己的风格。而日本和韩国，几十年发展自己的方向，现在已然是世界强队。

其实成佛的路很多，选那条路都没有根本的区别。关键在于选择了路之后，就不要犹豫，勇往直前！

87 楼 一蓑烟雨任平生 2010-08-31  

其实我那大段话的最后一段，不知道wwccss你是否仔细考虑过，本来无一物，何处染尘埃，这话说起来痛快，真做起来除了慧能谁知道？
如果真这么简单，咱们中国足球买2本书，看看录像带就可以冲出亚洲走向世界了。

86 楼 wwccss 2010-08-31  

呵呵，我刚毕业的时候，就被赶鸭子上架，作研发部的经理。那个时候压根不知道如管理。自己也看过很多的书啊，案例啊，给我的感觉，你不清楚如何管理。也就是在项目的每一个阶段，你如何作，不知道的。那个时候就心里面发虚，空荡荡的。

后台我参加过一次pmp的培训，对pmp有一个大概的了解，然后再回过头来思考scrum。突然觉得scrum就是一个拐棍，它让你清楚什么时候该作什么。那怕作的东西不好，不到位，但可以保证大的方向是没错的。

也不是和大家唱反调，刻意的来宣传scrum。呵呵，只是觉得scrum是一个好东西，大家应该公正的来看待它。:)

85 楼 一蓑烟雨任平生 2010-08-31  

wwccss以个人经历所举的例子，看来是公司内部的研发项目，并且公司不是靠拼人力成本来挣钱，可能就没有第1、2条线，第3条线也简单的多，如果是靠拼人力挣钱的公司，部门经理除了对项目进度负责外，还要考虑整体的项目生产成本，考虑人员的进出项目的时机。这点我觉得很重要，公司的盈利模式不一样，管理的方法也会有很大的差异。

我不是给wwccss唱反调泼冷水，毕竟他现在做的事情是很不错的。只是跟frostred一样，不用刻意去拔高Scrum，我们这些开发人员，本来在学校的时候就没有受过管理的培训，工作后对管理又反感，加上国内企业本身就不重视职业管理，导致一些很普通的管理技能缺失，这是根子，与其去套用各种各样的方法，还不如参加一些技能培训，学习怎么开会，怎么做任务管理，怎么做团队沟通。

在做过程改善的时候，看一些供应链和丰田的书，这些我觉得才是正路。

84 楼 wwccss 2010-08-31  

引用

Scrum所要解决的是项目组内部的任务管理，怎么做计划、怎么做跟踪，这点我跟ZWCHEN和frostred 的观点一致。Scrum只是把一些职业经理人必须掌握的技能，换种方式包装给了没有做过管理培训的“项目经理”，说的难听点就是怎么开晨会。
至于燃尽图，也就是一个任务状态看板，在Scrum之前，有很多种类似的图表，但是这些图表是给第2条线用的，第1条线用户看不懂也不关心，第3、4条线，不知道谁会关心，如果需要这张图来了解项目进度，通过看这张图来判断项目的异常情况，那么部门经理和项目经理就太不称职了，都应该换掉，而且最关键的一点是，开发工作只是整个项目的一个环节，靠这张图是无法了解整个项目的进度的。

目前这些敏捷方法有很多好的东西，但是要根据自己的场景来做取舍，这些方法的提出都有其商业目的，理念很好，但怎么落地就要掏银子请顾问咨询。说是人人都有佛性，只要顿悟就可以立地成佛，不过怎么顿悟，需要高僧来渡你，不给香火钱怎行。

不清楚大家为什么对 scrum带有这么多的成见？是因为scrum动了大家的奶酪，还是怕实行scrum失掉原来的东西?比如权力？威信？

这个组织结构图，我觉得不是敏捷开发里面的结构图。或者讲，这个组织结构图太结构化了。层次很清晰，也就是说上下级的汇报关系很明确。正因为存在汇报关系，所以才需要工作的反馈。

引用

。Scrum只是把一些职业经理人必须掌握的技能，换种方式包装给了没有做过管理培训的“项目经理”，说的难听点就是怎么开晨会。

即使按照你的这种说法，scrum给没有管理经验的项目经理提供了一个可以操作的框架，这就很了不起。不要瞧不齐scrum。你知道如何开好站立会议吗？这里面的道道也太多了。

引用

如果需要这张图来了解项目进度，通过看这张图来判断项目的异常情况，那么部门经理和项目经理就太不称职了，都应该换掉，而且最关键的一点是，开发工作只是整个项目的一个环节，靠这张图是无法了解整个项目的进度的。

如果说，项目中没有采取其他的措施，只有燃尽图。那么这个东西肯定不成。但还是和上面讲的。不要将scrum的实践割裂来看。燃尽图可以很直观的展现项目的走势，我真不清楚你为什么那么仇视燃尽图。也许大家很喜欢甘特图。甘特图才是极具迷惑性的工具。

scrum的实施，不需要你花费什么费用。只要团队肯去改变，学习，一个sprint走的不好，下个sprint纠正，自然而然的就会找到自己的节奏。

附上我们实际项目的燃尽图，供大家参考。

第十四期：第一天任务没有分解完，所以第二天曲线有一个明显的上扬。


第十五期的燃尽图，走得不是很好看，因为我们团队的小姑娘任务估计太客观，有的任务一直没有解决，所以曲线图是平的。还有就是周末休息。这个项目还在继续。

83 楼 一蓑烟雨任平生 2010-08-31  

谈到进度的反馈，先从项目管理的体制来着手。
我画了一个简图：


这个图上可以看出，项目经理需要汇报的路线有3条（1、2、3），这3条线所采用的汇报形式有差异。
第1条线以甲方的项目管理办法中的汇报体制要求来做，重点是进度和课题管理，具体的做法各异。
第2条线是向公司的项目管理部门汇报，我以前说过，公司角度的项目管理与项目组的目标是不一样的，对于项目型公司或者外包公司，项目管理的核心是对开发资源的成本管理，所以需要项目经理汇报进度和人月情况，普遍以周报形式体现。
第3条先是向所属部门汇报，这个层次与前2个又不同，我的体会是这个层次不需要固定格式的文档汇报，部门经理需要到现场随时了解项目组的进度、人力、成本、课题等情况，类似于调度员的角色。

第1、2条线的进度反馈，我觉得是刚性的要求，必须按照条例执行，第3条线则跟部门经理的人品有关。
第4条线，大家讨论的较多，我的体会是跟第3条线一样，项目经理应该不要求项目组成员填写任何的进度报告，这些进度的情况应该是他自己的工作，而不要转嫁给项目组成员。这条线跟其它的3条线，实际上没有直接的联系，怎么从第4条线转换，是项目经理的必要技能。

在基本明白这几条线的管理目标和差异后，才是具体的工作方法，怎么有效，这个还真是给不出一个特别好的方法。

通过这张图，我们也能看出，敏捷方法只是开发的一种方法论，而不是项目管理的方法论。

Scrum所要解决的是项目组内部的任务管理，怎么做计划、怎么做跟踪，这点我跟ZWCHEN和frostred 的观点一致。Scrum只是把一些职业经理人必须掌握的技能，换种方式包装给了没有做过管理培训的“项目经理”，说的难听点就是怎么开晨会。
至于燃尽图，也就是一个任务状态看板，在Scrum之前，有很多种类似的图表，但是这些图表是给第2条线用的，第1条线用户看不懂也不关心，第3、4条线，不知道谁会关心，如果需要这张图来了解项目进度，通过看这张图来判断项目的异常情况，那么部门经理和项目经理就太不称职了，都应该换掉，而且最关键的一点是，开发工作只是整个项目的一个环节，靠这张图是无法了解整个项目的进度的。

目前这些敏捷方法都有其商业目的，理念很好，但怎么落地就要掏银子请顾问咨询。说是人人都有佛性，只要顿悟就可以立地成佛，不过怎么顿悟，需要高僧来渡你，不给香火钱怎行，再说这些真是高僧？

82 楼 wwccss 2010-08-31  

hoho，此图甚好。

我也来传一个，scrum权威介绍。

81 楼 zwchen 2010-08-31  

我发两个比较优秀的的Scrum培训PPT吧。



wwccss同学，我可没有说Scrum行不通，如果说行不通，也是在我这儿不太可行。

80 楼 wwccss 2010-08-31  

还是误解。我在上一家公司里面带的5轮sprint，没有实行什么极限编程的实践，增加了qa的测试。照样可以拿到结果。

不要死扣概念。你试试在你的团队里面推行tdd？我觉得结果可能是最不敏捷的。

79 楼 daquan198163 2010-08-31  

没有极限编程的最佳实践（如tdd、重构、ci）支持，scrum就会变成“行为艺术”，呵呵

78 楼 wwccss 2010-08-31  

引用

公司最近一直在搞scrum。从一个developer的角度看来，scrum，至少我们实施的以及绝大多数我所了解的scrum，用处不大。 从一个developer的角度看，一个项目要想作的好，无非是三点： 1）程序员了解业务，了解需求 2）程序员有能力清楚，正确，高效的完成代码 3）人员交替时能顺利完成代码移交，不出现知识遗漏 对于1，scrum没有任何真正有效地手段，站立会议强调的是让大家了解别人的进度，对于如何让程序员深入业务，思考流程，scrum都没有说。XP里面还有个现场客户的概念，要developer和客户现场交流，虽然实施起来有难度，但毕竟是一个方向；而且一旦实施起来，能够接触第一手客户对于developer了解业务确实有很大帮助。而scrum呢？当然你可以说scrum也只是一个方法论，这个应该由具体项目去解决，不过这样还要你scrum有何用？ 对于2和3,这是我觉得scrum实施最让人不舒服的地方。XP里面解决这个问题的核心是TDD，有了TDD才有refactor，有了refactor才能让你在对业务有了新的了解后敢于将其反映到原有代码中，而非不敢动原来的，另搞一块。搞TDD对程序员的要求高一些（同时对程序员的提高也快一点），在我看来这是个能力问题，而scrum却没有谈程序员的能力差别，给我的感觉是“用了scrum，把能力问题通过流程的方式解决”。这不是扯淡嘛！敏捷本来就不是什么人都能用的，如果你找的都是1000块的代码工人，最好的方式就是外包公司那样反复的review再review，还搞什么敏捷？ 总体来说,scrum那些best practices，像什么sprint，stand meeting，daily build大多容易实施，这大概也是为什么有那么多scrum master能被生产出来的原因。但一把号子容易吹响也就意味着容易吹跑调，而scrum的实施者只会说“听啊，我们吹的多响！”却绝不会说“天啊，我们吹得多难听！”。 站在项目管理的角度，燃尽图让PM不再那么彷徨，能够得到一丝掌握世界的安全感。我想，这大概是为什么那么多项目组容易被scrum打动，进而实施scrum的原因，除此之外，我真的想不出为什么会有这么多人追捧scrum

scrum可以很清晰的指导一个团队什么时候该做什么事情，这已经足够了。它需要执行的地方很简单。简单的东西不好吗？有一个简单可以操作的东西，让大家去执行，可以上路，这就足够了。在前进的过程中，完善自己的装备，强大自己。

不是说一定要上了tdd，施行了重构才是敏捷。敏捷有很多种方式。拿到最终的结果才是真的敏捷。

我04年就尝试过极限编程，曾经推行过结对编程。但实施过程遭到了很多人的质疑，包括公司的领导。单元测试，国内真正搞起来的团队有几个？更不要说测试驱动开发了。国内真正能够实践极限编程的团队，凤毛麟角。

77 楼 wwccss 2010-08-31  

1. scrum和极限编程的概念你并没有搞清楚。这两者都是敏捷开发的两种常见的方法。可以互相结合。但如果一个scrum团队并没有实行xp，人家也是敏捷开发。我发过一个帖子，你仔细看下。http://www.iteye.com/topic/750483

2. scrum里面的实践都是相辅相成的，你单纯的割裂来看，没有意义的。是的，单纯的靠站立会议，或者燃尽图，肯定不行。这都是常识。可是人家scrum是一个完整的体系。你非得把人肢解了批判，态度就不对。

3. 你说的项目经理要深入到项目团队中，scrum从来也没有说，项目经理就只看燃尽图和召开站立会议。scrum照样强调团队要做在一起，要面对面的沟通和交流。

4. 其实scrum master和你所说的项目经理，有一个很重要的区别。我们大家做项目经理，恨不能什么东西都要自己做。或者别人做个东西都不放心。我想大家都有过这样的经历。其实真正的管理，是无为而治。scrum master 并一定要写代码，也不要去看代码写的怎么样。我们常说的外行领导内行，是很有道理的。这一点你体会到了，管理自然会上一个台阶。

5. 你太强调项目经理个人的作用了，真正的敏捷，是团队在作战，不是项目经理自己跳舞。所以放手，调动大家的积极性，建立真正互相信任的团队，这才是真正的敏捷。

从我的观点，xp要比scrum更难以执行。xp实施要求的条件比scrum要更高了。scrum在规定了最基本的管理框架之后，并没有限制你身体的过程如何。这是它的魅力。包容。

76 楼 iamlotus 2010-08-31  

<div class="quote_title">topgun 写道</div><div class="quote_div"><p>先不跑题，说说我们实践过的几种进度反馈方式：</p>
<ul>
<li>站立会议，不说了</li>
<li>腾讯群，不知道有多少人用过，我们是在培训一些实习生时发现的，几个实习生建了一个群，在里面交流，后来我也加入群，可以及时了解他们的情况，也可加以指导，腾讯群有记录可以查询，可以方便的截图，可以群发邮件，可以改腾讯签名来汇报工作状态。我觉得是一种不正式但非常有效的方法</li>
<li>wiki或blog，对于一些技术研究类或解决问题类的工作，我们要求写wiki，如果不是很商业的东西，也鼓励发blog<br>
</li>
<li>微博，呵呵，用javaeye 的闲聊就不错，因为有个firefox插件，可以很方便的报告自己的情况，和了解他人的情况</li>
<li>通过daily build 的报告，从邮件，rss 或是fisheye 里就可以了解</li>
<li>rss订阅，除了第一二个，都是通过rss 订阅来了解，而且一定要，这样减低了获取信息的麻烦度，让沟通可行性提高</li>
<li>jira也用过，发现还是对bug 或一些任务性很强的工作比较合适，对开发工作的情况记录和反馈不太合适。还有写每周报告excel 表，改甘特图等不太成功的方式</li>
</ul>
<p>再谈谈敏捷或是scrum吧，我们实施scrum，我觉得大部分不成功，后来自己总结的看法是：</p>
<p> </p>
<p>楼主就不说了，wwccss春哥把scrum说的很简单，我觉得是不对的。我认为成功的实施敏捷，是一件难度很大的事。</p>
<ul>
<li>首先是技术上的，敏捷不光是管理和方法，而且需要很好的技术支持，就像光有精益方法但没有很高的生产技术和技术水平很高的产业工人，还是做不到精益一样。具体到软件开发，重构和TDD 就会难倒一大批人，没有TDD就难以保证对需求的覆盖度和正确度，没有refactoring，就不能保证设计的良好。所以我认为，这两个做不到很好就不要谈敏捷</li>
<li>其他不那么技术的东西是不是就容易呢，也不一定，如果只是看了“硝烟”书，就认为自己学会了敏捷，并且想通过实施来获益，我认为很不靠谱，失败机会很大。很简单，站立会议，到底该讲些什么，这个如果不是很有经验的人来现场长期引导，很容易就讲歪了，被变味了</li>
</ul>
<p>要建立实施scrum，我认为要做到以下几点：</p>
<ul>
<li>首先要有高技术水平的团队，至少有一半是真正的程序员（真正程序员我也不好定义，反正理解为所有编代码的人里不到10%的可以是真正程序员就可以了）</li>
<li>团队中能有一个或多个通过了scrum中级以上培训认证的人担任scrum master</li>
<li>如果可能，团队实施初期，请专业的顾问公司对团队成员进行培训，甚至聘请顾问参与团队</li>
</ul>
<p>反正我认为，要敏捷，就认真去做，不要搞什么我只借鉴部分思想，我搞个中国特色的敏捷，那还不如你自己搞自己的土飞机呢（没有贬低土飞机的意思，这也是一种可以成功的方法）。</p>
<p>难是不是就做不到呢，mba难吧，雅思难吧，还是大把人去，小公司只要肯搞，先抽出三四个人的精英团队，走正确的路，也是有得搞的。</p>
<p>敏捷=高效!=简单</p>
<p> </p></div><br/>公司最近一直在搞scrum。从一个developer的角度看来，scrum，至少我们实施的以及绝大多数我所了解的scrum，用处不大。
从一个developer的角度看，一个项目要想作的好，无非是三点：
1）程序员了解业务，了解需求
2）程序员有能力清楚，正确，高效的完成代码
3）人员交替时能顺利完成代码移交，不出现知识遗漏
对于1，scrum没有任何真正有效地手段，站立会议强调的是让大家了解别人的进度，对于如何让程序员深入业务，思考流程，scrum都没有说。XP里面还有个现场客户的概念，要developer和客户现场交流，虽然实施起来有难度，但毕竟是一个方向；而且一旦实施起来，能够接触第一手客户对于developer了解业务确实有很大帮助。而scrum呢？当然你可以说scrum也只是一个方法论，这个应该由具体项目去解决，不过这样还要你scrum有何用？
对于2和3,这是我觉得scrum实施最让人不舒服的地方。XP里面解决这个问题的核心是TDD，有了TDD才有refactor，有了refactor才能让你在对业务有了新的了解后敢于将其反映到原有代码中，而非不敢动原来的，另搞一块。搞TDD对程序员的要求高一些（同时对程序员的提高也快一点），在我看来这是个能力问题，而scrum却没有谈程序员的能力差别，给我的感觉是“用了scrum，把能力问题通过流程的方式解决”。这不是扯淡嘛！敏捷本来就不是什么人都能用的，如果你找的都是1000块的代码工人，最好的方式就是外包公司那样反复的review再review，还搞什么敏捷？
总体来说,scrum那些best practices，像什么sprint，stand meeting，daily build大多容易实施，这大概也是为什么有那么多scrum master能被生产出来的原因。但一把号子容易吹响也就意味着容易吹跑调，而scrum的实施者只会说“听啊，我们吹的多响！”却绝不会说“天啊，我们吹得多难听！”。
站在项目管理的角度，燃尽图让PM不再那么彷徨，能够得到一丝掌握世界的安全感。我想，这大概是为什么那么多项目组容易被scrum打动，进而实施scrum的原因，除此之外，我真的想不出为什么会有这么多人追捧scrum。

75 楼 frostred 2010-08-31  

wwccss 写道

你就少说几句吧。说的越多，漏洞越多。

能不能请您指出来，我可是抱着交流和学习的目的来的。