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

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

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

评论

74 楼 wwccss 2010-08-31  

引用

楼主就不说了，wwccss春哥把scrum说的很简单，我觉得是不对的。我认为成功的实施敏捷，是一件难度很大的事。
首先是技术上的，敏捷不光是管理和方法，而且需要很好的技术支持，就像光有精益方法但没有很高的生产技术和技术水平很高的产业工人，还是做不到精益一样。具体到软件开发，重构和TDD 就会难倒一大批人，没有TDD就难以保证对需求的覆盖度和正确度，没有refactoring，就不能保证设计的良好。所以我认为，这两个做不到很好就不要谈敏捷

关键性的概念错误。tdd啊，重构啊，这些是极限编程里面提出来的实践。但xp，极限编程并不是实现敏捷开发的唯一的方式。scrum并没有要求团队必须去做 tdd啊。你也不能因为这些是极限编程的实践，而否定scrum的开发就不敏捷。概念错了！

实施scrum确实不容易，需要团队观念有很大的改变，包括整个公司的产品管理方式，都要改变。但也绝不是zwchen和frostred所说的那样，scrum压根就行不通。btw, to frostred，你就少说几句吧。说的越多，漏洞越多。

73 楼 topgun 2010-08-30  

<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>

72 楼 frostred 2010-08-30  

哈哈，我想我是走题比较严重的一个吧。在此，先道个歉，然后回到主题，总结一下自己的看法。

我认同敏捷理念，但对Scrum不感冒。这点上，我非常接近zwchen。

在敏捷理念的理念中，个人和交流重于过程和工具。就是说软件的开发过程中，或项目管理过程中，人是最重要的环节。当处理和人有关的问题时，我想大多数人都同意，没用什么流程，工具，方法是万能的。你必须因人而异，因事而异，找出解决问题的方法。如果你在寻找一种神奇的工具来帮你解决所有的难题的话，我劝你还是别找了。不但如此，当有人告诉你有什么方法或工具能完美的解决所有问题时，你都要警惕他是不是在向你兜售什么更本没用的东西。

回到工作进度反馈这一主题。这一问题的本质是，作为项目经理，你要获取项目进度的信息。第一手信息当然是源代码，它也是最可信赖的信息。但你的精力是有限的，你不可能看所有的源代码。所以，你要抓大放小，有选择的运用这一手段。我的经验是，作为项目经理，你一定要最准确的，最及时的知道系统中的关键环节的进展情况，目前所遇到的问题， 潜在的问题和可能的解决方法。什么是系统中的关键环节呢？它可能是最核心的业务逻辑，也可能是影响系统性能的关键环节。它因项目而异，但作为项目经理，你应该很清楚的知道这些环节。怎么获取第一手信息呢？如果有可能的话，你可以选择自己来完成这一部分，或参与完成，或由你来做code review. 我所要强调的是，系统的关键一定要心中有数，一定要获取第一手信息。

以上是我想说的第一点：作为项目经理，你一定要参与到项目中去。想要靠10分钟的站立会议或看看图表就能掌握项目进度，无异于痴人说梦。

然后呢，你只能依赖从其他人来获取信息了。从其他人获取信息，有两个问题, 一是如何保证信息的质量，可信度。二是，如何保证信息的及时。比如说信息最好是被pushed到你，而不是你必须要不停的pull 信息。（很象是Messaging的两种工作方式。优缺点也很象。）
这两个问题不是任何工具和流程所能解决的，你必需建立良好的交流环境。这是我想说的第二点.

我所认为的建立良好的交流环境的原则：
1. 人 – 成员的选择和培养
2. 建立良好的氛围
3．简单的流程和易用的工具。

1最重要，2其次，3更其次。

下面我列举一些建立良好的交流环境的技巧。大伙肯定也有不少此类的技巧，欢迎补充。

1． 招人，我所重视的品质是，踏实，好学，对技术有兴趣。
2． 作为项目经理，要勇于承担责任。有时候，搞搞集权，并不是不可以，关键是绝不能主意全是自己拿，责任全是别人付。记住，在老板那里，你的手下永远没有责任，承担责任的只能是你。
3. 有问题，先解决问题，不要先找是谁该承担责任。
4. 不一定做大强度的Pair programming。 但偶尔花点时间做Pair programming还是只值得的。比如说每星期1-3次，每次1-2小时。
5. Code review要做。但千万不要太吹毛求疵，要容忍别人有不同的做法，即使自己不是完全满意，不是大问题，就可以了。但也别搞成走过场。这个东西说起来简单，做起来其实挺难的。大伙有什么好经验，不妨分享一下.
6. 和你的队员坐在一起，不要单独在一间办公室里。
7.即使搞集权，也要给队员发挥的空间。类似Code review，要容忍别人有不同的做法，即使自己不是完全满意，不是大问题，也就可以了。如果打击了大伙的积极性，只是为了满足你的力求完美的欲望，就得不偿失了。更何况，你也不一定都对，完美的系统也是不存在的。
8.以诚待人。不要在人背后说坏话。
9.不要说话莫测高深。把复杂的事说简单了才是水平。
10. 不要强行上TDD之类的东西，可以不忙时，用周五的下午搞搞coding dojo， TDD kata之类的，以提高大家的兴趣和水平。
11. 不要没事嘴边总挂一大堆设计模式之类的名词。不要用“你丫听说过Adapter pattern吗？”之类的口吻说话。要用“嗯，你这做的很好，不过，我觉得还可以改进一下。这样就更灵活了，你觉得呢？其实，这是一种惯用的解决方法，它还专门有个名字呢。叫Adapter pattern”。等到大伙都明白了什么是Adapter pattern，你就可以直接说了。
12.选用简单易用的交流工具。一般来讲号称功能越多越全的工具，也越难用。一个人花5分钟时间还搞不明白怎么用，一般就会失去耐心，产出抵触情绪，工具的使用也就流于形式了。
13. 让组员每天写计划和日志的事，还是不要干了吧。 我还没见过不是交差应付的。如果大老板让这么干，千万不要拿组员的日志当真。

好了，先想这么多了，这个List可以很长很长。大部分也不是直接与楼主的问题相关。但管理项目主要是与人打交道，而与人打交道，往往是这种小事，潜移默化的影响了最终的结果。

71 楼 seeckt 2010-08-30  

不跑题
我的建议是经理进行访谈，同时替员工写工作日志

解决问题：
1、技术性员工思维方式是解决问题式的，而不是一般经理用的的报告式，如果强行改造容易引起反感
2、日常沟通+写工作日志+收集工作日志的时间节省为日常沟通+写工作日志
经理的工作量没有增加，员工的减少了写工作日志的时间
3、避免官僚性、无意义的工作日志
上午解决一个BUG，下午解决一个BUG的工作日志可能变为计划完成X项任务，实际完成X项任务，差异原因XXXX
同时填错任务类别，所属项目的问题也解决了，另外可以对工作日志适度包装，领导检查看起来更加舒服，这方面经理比员工更加擅长

缺点：
限制团队成员成长，如果员工只想技术方面发展，问题不大
但是如果想向管理上发展，这条路被堵死

改进：
将工时反馈任务逐渐转移到有管理愿景的员工上

70 楼 showone 2010-08-30  

一种方式在一个项目中成功了不代表可以适用于所有项目所有团队。同一种方式一个团队成功了，另一个团队失败了，成功者就以此来攻击失败者也是不合适的。只有彼此总结成功的经验以及失败的教训才能得到提高。

我们在这里可以讨论自己团队目前或曾经常用的进度反馈方式及执行效果，再加以分析原因。

鉴于有些回复离题较远，我觉得有必要以一种格式来规范大家的回复。
下面谈谈本人曾经所在的团队的情况。

方式：工作日志+scrum站立会议+scrum燃尽图填写
效果：效果不是非常明显
原因：本团队比较和谐，沟通比较充分，彼此了解对方的进度。工作日志、站立会议及燃尽图填写有功能重复的地方，比较浪费时间。有为了文档而文档的嫌疑，不符合敏捷思想。

69 楼 wwccss 2010-08-30  

hoho，罢战。干活去了。

68 楼 jinyanhui2008 2010-08-30  

wwccss 写道

引用

雅虎中国的菜菜水平,从wwccss可见一斑

你这是人身攻击。中国雅虎在中国的失败，不是我们底层的员工所能决定的。你这样说，我只能原谅你的无知和鲁莽。

要说到技术，中国国内的公司，没有一家能够比得上雅虎的。不过像强强这种嘴皮子功夫，雅虎是差了很多。

可惜了。。。雅虎让阿里搞趴了。。。唉。。。很无语。。。

67 楼 zwchen 2010-08-30  

wwccss 写道

说跑题，其实也不是跑题。关于进度反馈，有各种各样的方式。引出来scrum中的站立会议，然后大家开始讨论。这没有跑题。

还是来回答zwchen的问题。

1. 我要表达的意思是，一个团队中的成员，应该互相了解对方在做什么，即使从技术实现上来讲，或者其他的角度上来讲，彼此之间压根就没有关系。如果没有关系，大可不必放在一个团队中，你直接一对一，领导你的下属。然后下属之间没有横向的联系就可以了。
2. scrum里面的实践是大家在分解任务的时候，估计每一个任务的预计剩余时间，然后每天大家都要更新自己所负责的任务的预计剩余时间。单位都是小时。肯定有人说，估不准的。没有关系，估比不估强。小时和天的区别，天的概念太模糊了。一个任务说做一天，我觉得不如说需要8个小时更准确。

3. scrum的团队以信任为前提，这点我完全赞同。也就是说，问题的关键，可能还在scrum master，或者叫做项目经理身上。但你现在有这个能力，也这个条件去做，可以尝试下。

4. scrum本身是很灵活的。你这么说，其实是在诡辩。你潜意识中把scrum等同于菜刀。那你错了。scrum不是菜刀，是如意软刀， 是瑞士军刀。

5. 并没有说一定要换成scrum，也没有说你的实践不对。只是你这种主观的判断，scrum的各种不好，我觉得有失偏颇。

还是回到之前说的那句话，问题的关键就在自己。你愿不愿意去打造一个充满信任，充满朝气，蓬勃发展的团队呢？scrum是一条路，而且是已经被世界上n多实践证明了能够行得通的道路。

第1点
如果说站立晨会有点意义，那就是仪式的作用：形成一种团队紧张感。
我前面对站立晨会的五点疑问(2+3)，你始终避而不谈。

第4点
如果Scrum是瑞士军刀，但很多团队需要的是菜刀或砍刀，这个行吗？
我最开始举这个例子是想表达：Scrum有适用场景，但你却没有理解这个意思，也就是工具没有强弱之分，只有适用场合。

算了，我也理解你的意思，我们不要就这个问题争论不休。对于第一次看这篇文章的用户，回帖越多，从头往下看，压力会越大。

66 楼 wwccss 2010-08-30  

引用

雅虎中国的菜菜水平,从wwccss可见一斑

你这是人身攻击。中国雅虎在中国的失败，不是我们底层的员工所能决定的。你这样说，我只能原谅你的无知和鲁莽。

要说到技术，中国国内的公司，没有一家能够比得上雅虎的。不过像强强这种嘴皮子功夫，雅虎是差了很多。

65 楼 lookdd1 2010-08-30  

强强爱妍妍 写道

雅虎中国的菜菜水平,从wwccss可见一斑

这不是讨论问题的方式,再重的言语我就不说了。

64 楼 强强爱妍妍 2010-08-30  

雅虎中国的菜菜水平,从wwccss可见一斑

63 楼 wwccss 2010-08-30  

说跑题，其实也不是跑题。关于进度反馈，有各种各样的方式。引出来scrum中的站立会议，然后大家开始讨论。这没有跑题。

还是来回答zwchen的问题。

1. 我要表达的意思是，一个团队中的成员，应该互相了解对方在做什么，即使从技术实现上来讲，或者其他的角度上来讲，彼此之间压根就没有关系。如果没有关系，大可不必放在一个团队中，你直接一对一，领导你的下属。然后下属之间没有横向的联系就可以了。
2. scrum里面的实践是大家在分解任务的时候，估计每一个任务的预计剩余时间，然后每天大家都要更新自己所负责的任务的预计剩余时间。单位都是小时。肯定有人说，估不准的。没有关系，估比不估强。小时和天的区别，天的概念太模糊了。一个任务说做一天，我觉得不如说需要8个小时更准确。

3. scrum的团队以信任为前提，这点我完全赞同。也就是说，问题的关键，可能还在scrum master，或者叫做项目经理身上。但你现在有这个能力，也这个条件去做，可以尝试下。

4. scrum本身是很灵活的。你这么说，其实是在诡辩。你潜意识中把scrum等同于菜刀。那你错了。scrum不是菜刀，是如意软刀， 是瑞士军刀。

5. 并没有说一定要换成scrum，也没有说你的实践不对。只是你这种主观的判断，scrum的各种不好，我觉得有失偏颇。

还是回到之前说的那句话，问题的关键就在自己。你愿不愿意去打造一个充满信任，充满朝气，蓬勃发展的团队呢？scrum是一条路，而且是已经被世界上n多实践证明了能够行得通的道路。

62 楼 zwchen 2010-08-30  

jnoee 写道

从第二页就开始跑题...一直跑到最后。
请问各位打这么多字的朋友，你们注意到这个帖子的主题是什么了吗？
本以为能得到一些实际的操作经验，结果又成了理论之争。
来点干货好吗？虚的东西太多了。

强烈同意！
我很想知道的：关于工作进度反馈，其他人更优雅的实践。

61 楼 zwchen 2010-08-30  

wwccss 写道

你的几个问题，我谈下我的看法。
1. 关于团队之间彼此之间没有什么关系的问题。我觉得，既然是在做一个项目，大家都是团队中的成员，必然有着千丝万缕的联系，不可能一个人做的东西，100%和另外一个人没有关系。这是其一。其二，从团队建设角度来讲，让大家多了解下其他人在做什么，有助于团队的建设，增加团队之间的互相了解。还可以增强人员的备份能力。
2. 关于任务进度的估计，scrum 的实践是估计预计剩余的小时数，不是完成度，也不是多少天。每天都估计。我想这个要比你按天的估计要合理的多。因为按天估计，水分太大了。
3. 至于说到你对scrum的成见，我想应该是07年你经历的那次scrum吧？其实scrum早就指出，晨会不要解决问题。大家只谈那三个事项。有问题会下解决。还有就是猪和鸡的角色。有些人是不能发言的。如果你仅仅是因为这个而排斥scrum的话，那我说，你错了。

scrum可以适用于各种类型软件的开发。具体的，建议你可以到infoq去看例子。从我实际过的scrum来讲，scrum并没有局限什么类型软件的开发。不过我主要是在互联网行业，我的例子说服力不强。我记得infoq讲过一个荷兰火车控制系统的项目。之前按照瀑布式开发，几年没有结果。之后改为scrum，很顺利的完成!

scrum的魅力在于，他给团队明确的指示，你在什么阶段应该做什么。每个人都很清楚的。

我后面会总结一些我对scrum的心得和想法，和大家分享。

btw， zwchen，你不能因为那次的经历就说scrum不行。如果你说他不行，你应该认真的按照scrum实行过几个sprint之后，再来评判。

问题1
你的回答很模糊，这句话相当于没说：我觉得，既然是在做一个项目，大家都是团队中的成员，必然有着千丝万缕的联系，不可能一个人做的东西，100%和另外一个人没有关系。
比如，有一件事要大家去做，我不会写一件事，而是会用准确的词语：目标或任务，也不会用“工作”等模棱两可的词，具体是目标还是任务，我会进一步斟酌。
表达就是概念的串联。
我之所以强调，是因为概念的模糊和混淆，会导致沟通障碍。

问题2
任务进度的概念你还是没有解释得让我明白

问题3
我认为Scrum一定要以团队信任、开放等氛围做前提，团队管理的基础是人的管理。而我之前的团队根本不具备这个条件。

scrum可以适用于各种类型软件的开发。
如果这样的话，我用菜刀削苹果、削铅笔也都是可以的。

Scrum实践
我们目前的实践方法比较适合于我们的项目和团队，如果要换成Scrum，都有一个做事习惯和思维习惯的改变过程。再说，我们现在的项目风险和方法改进关系很小。
我们当前的核心问题是部门间沟通和协作，以及人力资源的不足，Scrum能量有限。

60 楼 jnoee 2010-08-30  

从第二页就开始跑题...一直跑到最后。
请问各位打这么多字的朋友，你们注意到这个帖子的主题是什么了吗？
本以为能得到一些实际的操作经验，结果又成了理论之争。
来点干货好吗？虚的东西太多了。

59 楼 wwccss 2010-08-30  

zwchen 写道

wwccss同学，不好意思，现在才回复你，因为周末在成都周边旅游。

关于集权
我在文中写道“做项目，肯定是要将目标和计划明确化，然后将目标分解成任务，将任务分配给人。”，然后，你说这是集权式管理。
确实，一年前是搞集权，后来意识到这种单向沟通会导致双方信息不对称，还会让团队感觉自己只有执行的份，无形中会产生抱怨或热情不高。
半年前，我主要采取双向沟通，也就是定目标、做计划、分解任务时，先会和相关人一起讨论，大家基本达成一致后，就开始执行。执行过程中，我会辅导和协调。渐渐的，团队气氛也活跃了。
所以，你说我是集权，我是不太认同的。
不过，有时我还会集权(我说了算)，因为那时候往往大家都没主意，比如商业决策和某些太专业的业务问题，当然了，我会征询大家意见。

你说管理者应该放权，让团队自我管理，让团队做自己喜欢做的事情，我都是认同的，而且我文中以及以前的文章，都反复强调这一点。

沟通目标
我希望我们的讨论只是为了解决问题，我们是讨论而不是争论。我本文的标题是探讨，而不是结论；文章内容只是亮出我的看法，而不是证明我的观点，因为一证明肯定就会有人反驳。再说，我都不敢保证我采取的方法可以铺开，因为它和我的性格和价值观很大。

每日晨会
关于每日晨会，我上面谈到了两个问题。我还补充几个，绝不是细节、挑刺。
1、如果项目团队分工交叉度很小，也就是团队角色差异很大，比如除了开发人员，还有设计师、内容编辑，后两种角色并不需要关心开发人员进度和遇到的问题，既听不懂也没兴趣。我说的开发人员，是指开发后台，界面都是统一模式那种，比如图书超市的POS机。
2、有些功能模块，需要持续几天，相关人并不喜欢每天汇报进度和问题，也没有必要，因为实现这功能只是一个时间和代码量问题。
3、软件开发的进度和模块工作量，除了低端coding，还真是很不好量化。就说一个增删改查(技术角度)，可能改、查比增、删权重高得多，难度大得多，时间没法均衡分布。
像进度，你说完成70%，是功能完成70%，还是进度完成70%？后者可能更靠谱，因为10工作日的任务，过去了7天，相关开发人员知道后面3天可以完成100%，但功能进度可能是50%或90%。因为这个，我拿甘特图有些无奈，Scrum燃尽图只是更形象点，但都没法描述本质问题。而且，我没有发现哪一个项目是靠文档描述成功的。

我07年的一个项目，PM就是用Scrum方法，那个晨会简直开成了讨债会，大家都板着脸。
后来在我的团队，我试过各种进度沟通会议，频率是一天、两天、还是一周，时间是周一上午还是周五下午？最后我发现最好的方式是根据每人的工作模块特点、以及他本人的做事方式及能力来调整，有些人就是喜欢两三天毫无干扰地尽情发挥。

Scrum适用场景
Scrum可能更适合一些消费类互联网软件，也就是业务每个人都熟悉点；对于业务很复杂的，如社保或财务系统，或是外包公司的二包，开发人员几乎没有能力或无需过多发言。这类软件往往是业务需求确定后，开发人员一伙上，因为开发工作只是实现业务功能，开发人员之间都是垂直分工，不需要彼此间进度沟通，更没有必要一天一次沟通。

其实，我的意思是，任何软件过程，都以开发团队素质和项目特点来定，而没法用一套万能的。如果你一直研究Scrum，你应该很清楚你的管理软件具体适用场景(团队+项目)。是否你一直在做互联网开发？

基础管理
我确实不感冒Scrum，但我认同敏捷理念。
另外我再重复一点，项目管理中涉及到的很多方面，如沟通、计划、激励、授权等，都在基础管理，比如《职业经理人》里有深入研究，任何项目管理书籍在这些方面都比较粗浅，而这类书一般做开发出身的管理者接触不到或想不到。

wwccss同学，我有个建议，你把你的Scrum实践都整理出来，然后发布在这个版块，我相信很多人都像我一样，有种期待。
我也希望和你一样，让敏捷理念在国内落地。
对于敏捷过程推广，我觉得比较靠谱的过程是这样的：
第一步 宣传敏捷理念
第二步 推广一些最佳实践，然后通过最佳实践总结出一套适合国人特点的敏捷过程。
第三步 最后才是工具的推广及应用。

特别注意，一定要站在中立立场(中立=指出优点+不足)，因为信任=信任人品+信任能力，前者是前提。

zwchen，要知道你说话的影响力。你的文章的观点太过于诱惑。je那么多人在看帖子，很有很多的新手，你的文章可能会影响他们的判断和决策。当然，我不是说你不可以说话，我之所以回帖，批驳你的观点，是想让大家知道，zwchen说的只是一个方面，事情的真相有待自己去发现。

你的几个问题，我谈下我的看法。
1. 关于团队之间彼此之间没有什么关系的问题。我觉得，既然是在做一个项目，大家都是团队中的成员，必然有着千丝万缕的联系，不可能一个人做的东西，100%和另外一个人没有关系。这是其一。其二，从团队建设角度来讲，让大家多了解下其他人在做什么，有助于团队的建设，增加团队之间的互相了解。还可以增强人员的备份能力。
2. 关于任务进度的估计，scrum 的实践是估计预计剩余的小时数，不是完成度，也不是多少天。每天都估计。我想这个要比你按天的估计要合理的多。因为按天估计，水分太大了。
3. 至于说到你对scrum的成见，我想应该是07年你经历的那次scrum吧？其实scrum早就指出，晨会不要解决问题。大家只谈那三个事项。有问题会下解决。还有就是猪和鸡的角色。有些人是不能发言的。如果你仅仅是因为这个而排斥scrum的话，那我说，你错了。

scrum可以适用于各种类型软件的开发。具体的，建议你可以到infoq去看例子。从我实际过的scrum来讲，scrum并没有局限什么类型软件的开发。不过我主要是在互联网行业，我的例子说服力不强。我记得infoq讲过一个荷兰火车控制系统的项目。之前按照瀑布式开发，几年没有结果。之后改为scrum，很顺利的完成!

scrum的魅力在于，他给团队明确的指示，你在什么阶段应该做什么。每个人都很清楚的。

我后面会总结一些我对scrum的心得和想法，和大家分享。

btw， zwchen，你不能因为那次的经历就说scrum不行。如果你说他不行，你应该认真的按照scrum实行过几个sprint之后，再来评判。

58 楼 wwccss 2010-08-30  

引用

没人兜售？
ScrumAlliance，Scrum.org 都在搞certified scrum developer之类的东西。这已引起了Uncle Bob在内的很多真正Agile实践者的不满。
感兴趣的话，可以读读：http://blog.objectmentor.com/articles/2010/04/21/the-r-e-a-l-i-t-y-principles-of-agile-software-certification

有人做认证，也不是什么坏事情。说明有市场。就像现在的pmp认证一样。你不能因为认证而否定pmp，同样，你也不能因为认证而否定scrum。你这种推理是不对的，而且很不讲道理。实际的东西就在那儿，你可以选择认证，也可以不选择认证。选择权利在你自己。

引用

Scrum还有一个优点是能让不懂技术的管理层听明白。所以，有些人，很容易利用它，上忽悠管理层，下不让开发人员觉得太难。

如果你认为是在忽悠的话，你的出发点就完全错误了。管理的目的不是忽悠，管理的手段也不是忽悠。真正的东西是什么，自己体会吧。体会不到，你就永远忽悠别人，还有被人忽悠。

引用

这就是我真正怀疑Scrum的地方，没有了TDD， refactoring， pair programming， code review， 也不强调Small Design，那还是Agile吗？

你还是不懂scrum真正的魅力是什么。要知道你让一个开发人员去做结对编程，他可能会杀了你。你说的这些，其实是极限编程实践里面的东西。你要搞清楚概念。xp，极限编程，强调的事开发实践。但极限编程不等于agile。你把这两个概念完全搞错了。具体的资料我不给出，你自己去看吧。

就好象语言的框架一样，ruby on rails，是ruby很好的框架，但你不能任务railes = ruby，由此推断其他的框架就非rails。概念没搞清楚，逻辑推理错误。你在何人讨论的时候，这些是大忌。

引用

Scrum中并不强调面对面的沟通。因为面对面的沟通的技巧，很难被证书认证，也很难被写成一个产品的功能点。

主观臆测而已，有哪家的scrum讲过，scrum不强调面对面的交流？有什么这个说过？我想肯定是你受过什么刺激吧？如果真的有人这样和你说过，那我只能说，你真背。scrum就那么点东西，稍有常识都可以判断真伪。还被忽悠？

你对scrum就是抱着像对待敌人一样的成见，和你讨论，真的再没有必要了。打住。不想再和你费口舌。

57 楼 showone 2010-08-30  

flashing 写道

所谓管理，没有什么特效的办法，不然大家也不会如此头疼了。其实我的看法是得因人而异，因势而已。

确实如flashing所说，管理没有定式，因人而异。
zwchen也总结了诸多方式，工作日志、站立会议、走动沟通等等。不可否认这些方式在各种团队中都曾成功过，也曾失败过。我们不能因为成功过就认为这种方式适用于所有情况，也不能因为有过失败就否认一种方式。
种种方式只不过是手段而已，我们不能因为手段而忘了我们的目标。

56 楼 hiblue 2010-08-30  

项目管理了几年,
也试了好几种方法,
最终觉得,
那些都是浪费时间,
现在我的管理方法是: 不管理,
无为而治.

如果管理成本, 大于管理成效,
或者,
如果不管理的损失, 小于管理成本,
那么,
无为而治也算是一种管理方法吧.

55 楼 frostred 2010-08-30  

wwccss 写道

引用

我可能是对scrum压根没有一个正确的实践，而且我发现我所知的绝大多数号称用Scrum的人,也没有正确的实践。然后才意识到，大伙所用的Scrum其实只是某些人兜售的Scrum。所以说，我一直也没有说Scrum有什么不对的。我只是强调回到Agile的本质上来看问题。你一旦回到Agile的本质，你就很容易辨别什么是兜售的Scrum了。比如说燃尽图。我还是那句话：依赖任何图表来了解，管理项目进度的方法，都是不现实的。
别跟我说，Scrum也不排除其他的方法。如果有其他的方法方法，你倒是也说出来呀。干嘛只是不停的强调燃尽图的作用。能不让我怀疑你的产品只是能生成燃尽图吗？

scrum没所谓谁谁兜售。

没人兜售？
ScrumAlliance，Scrum.org 都在搞certified scrum developer之类的东西。这已引起了Uncle Bob在内的很多真正Agile实践者的不满。
感兴趣的话，可以读读：http://blog.objectmentor.com/articles/2010/04/21/the-r-e-a-l-i-t-y-principles-of-agile-software-certification

wwccss 写道

scrum的核心的东西就是那么多。跟你解释下为什们scrum可以大为流行，而极限编程推行的确不是那么广。scrum的优点在于它只规定了宏观层面的实践，而没有强调大家一定要去做结对编程，单元测试什么的。你可以自己思考下，让一个团队来分解任务，开站立会议容易，还是让团队执行结对编程，单元测试等等敏捷实践容易？我想肯定是scrum要更容易操作。

这话我完全同意。再帮你补充一点，Scrum还有一个优点是能让不懂技术的管理层听明白。所以，有些人，很容易利用它，上忽悠管理层，下不让开发人员觉得太难。

wwccss 写道

这也就是scrum的魅力。在scrum下面，你可以考虑用极限编程的方式来开发，也还可以采用自己已经习惯的方式。完全是由团队自己决定的。比如要不要做单元测试。单元测试很好。但在中国雅虎里面，都没有怎么实施起来。

这就是我真正怀疑Scrum的地方，没有了TDD， refactoring， pair programming， code review， 也不强调Small Design，那还是Agile吗？

wwccss 写道

燃尽图是非常好用的一个工具，但并不是说只有燃尽图。你不要断章取义。除了燃尽图，最开始的计划会议，每天的站立会议，任务的分解，面对面的沟通，最后的总结和演示，这都是在掌握项目。谁说过，只看燃尽图？

你上面所说的，开始的计划会议，最后的总结和演示 等，都是sprint开始和结束时做的。真正sprint进行中做的只有站立会议，面对面的沟通，和燃尽图。站立会议所交流的信息量是非常有限的。那剩下的只有面对面的沟通，和燃尽图了。我的观点是面对面的沟通远比看任何图表更有用。不过很可惜，Scrum中并不强调面对面的沟通。因为面对面的沟通的技巧，很难被证书认证，也很难被写成一个产品的功能点。我知道，Scrum并不排斥面对面的沟通，同样，你也可以说Scrum也不排斥TDD， refactoring， pair programming， code review。。。，但不要告诉我Scrum象Lean重视“go-see“一样重视它。