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

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

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

评论

54 楼 zwchen 2010-08-29  

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

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

53 楼 wwccss 2010-08-29  

说到燃尽图，我觉得还是很形象的，就像电视剧里面的点香倒计时一样。我的软件里面最开始翻译的是燃烧图，后来有朋友指出，燃尽图更为贴切。

说到这儿，甘特图，你能从字面上体会出什么意思来吗？完全的一个音译词。

工具不再多少，而在于是否能够利用好。scrum里面提供的这些实践、方法和工具，利用好，就已经很了不起了。:)

52 楼 frostred 2010-08-29  

wwccss 写道

我想可能很多的scrum团队第一个sprint的燃尽图都不会太好看。

哈哈，这话说的没错，第二个sprint，大伙就学会了怎么让燃尽图走的好看，让老板看着开心。

51 楼 wwccss 2010-08-29  

引用

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

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

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

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

50 楼 wwccss 2010-08-29  

我想可能很多的scrum团队第一个sprint的燃尽图都不会太好看。呵呵，燃尽图的走势有几种：

1. 比较理想的向下延展，和理论的上的线比较吻合。这是运行的比较正常的scrum团队的标志。
2. 燃尽图一直上扬，肯定是sprint中有新增任务。scrum不再是scrum。
3. 燃尽图局部上扬，然后向下延展。很有可能是团队对任务估计不足。
4. 燃尽图在项目没有结束的时候已经到达零点。说明团队对自己估计太过于谨慎。呵呵。
5. 燃尽图一直是平的，没有变化，说明大家没有人更新任务的预计剩余时间，要么是忘记了更新，要么是项目已经停滞了。

49 楼 frostred 2010-08-29  

wwccss 写道

引用

如果你认为和我没有讨论的基础，那我想问题在你。你就是卖Scrum产品的。我不想坏你的生意，

你在攻击别人之前，先把东西搞清楚再说。我们的软件zentao是开源软件，也就是意味着你可以不用花费任何费用来使用它。还有我们的上下文，是有个朋友在问有没有一个完整的软件研发的解决方案，所以我们提了下。如果你认为我们是在卖scrum产品，我们也无话可说。随便你怎么样吧。

scrum里面的英文单词是burn down chart，翻译过来就是燃尽图。我搞不懂这有什么神秘可言。如果你觉得这是在神秘化，我只能说你自己有毛病。我们周围那么多名词，agile, 结对编程，单元测试，mock, 代码走读，系统测试，测试用例，build，release， 哪一个不是神秘的单词？

和你没有讨论的基础，是因为你对scrum压根就没有一个正确的认识和实践，和你讨论，简直就是弹琴，一点意义没有。

引用

到达一种"知识境界"后，说服任何一方都是不大可能的。。所以就不要尝试说服了，只说实实在在的东西。

说的很有道理，你用不用scrum，认为scrum好不好，跟我没有任何关系。但是我要告诉看这个帖子的人，什么是真正的scrum。不要因为某些个人的偏激的观点，对scrum有了先入为主的判读，对自己，对团队来讲，丧失了一个公正的去对待scrum的机会。

好的东西，总会找来一些飞来的唾沫，让唾沫来的更猛些吧！

对不起，我的确没有搞清楚zentao是商业软件还是开源软件就说你是卖Scrum产品的。是我的错。我道歉。不过你们就真的不提供任何基于zentao的盈利性商业服务？如果你真是这么高尚的话，算我以小人之心度君子之腹，我就再道歉一次吧。

不过话说回来了，就算你不是卖Scrum产品，你也算是Scrum产品的Provider吧。你的目的可能高尚，但结果还是一样， 你在推广（推销）你的产品。所以，除了上面说你是卖Scrum产品那句话外，其它的，我并不想收回来。


燃尽图这个词我是不喜欢，包括burn down chart这个英文单词，我觉得也有些故弄玄虚的味道。其他的词：
Agile - 不是很好，但毕竟是个简单的词，也可接受。
结对编程，单元测试 - 很好，一目了然，知道在说什么。
mock - 不好，混淆了很多概念。不过不是纯粹的单词的问题。
代码走读 - 不明白什么意思。
系统测试 - 不是很好，不如单元测试，压力测试，功能测试这么概念清晰。
测试用例，build，release - 用的时间太长了，没有什么感觉了。


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

48 楼 seen 2010-08-29  

wwccss 写道

引用

如果你认为和我没有讨论的基础，那我想问题在你。你就是卖Scrum产品的。我不想坏你的生意，

你在攻击别人之前，先把东西搞清楚再说。我们的软件zentao是开源软件，也就是意味着你可以不用花费任何费用来使用它。还有我们的上下文，是有个朋友在问有没有一个完整的软件研发的解决方案，所以我们提了下。如果你认为我们是在卖scrum产品，我们也无话可说。随便你怎么样吧。

scrum里面的英文单词是burn down chart，翻译过来就是燃尽图。我搞不懂这有什么神秘可言。如果你觉得这是在神秘化，我只能说你自己有毛病。我们周围那么多名词，agile, 结对编程，单元测试，mock, 代码走读，系统测试，测试用例，build，release， 哪一个不是神秘的单词？

和你没有讨论的基础，是因为你对scrum压根就没有一个正确的认识和实践，和你讨论，简直就是弹琴，一点意义没有。

引用

到达一种"知识境界"后，说服任何一方都是不大可能的。。所以就不要尝试说服了，只说实实在在的东西。

说的很有道理，你用不用scrum，认为scrum好不好，跟我没有任何关系。但是我要告诉看这个帖子的人，什么是真正的scrum。不要因为某些个人的偏激的观点，对scrum有了先入为主的判读，对自己，对团队来讲，丧失了一个公正的去对待scrum的机会。

好的东西，总会找来一些飞来的唾沫，让唾沫来的更猛些吧！

问个关于燃尽图的问题：你的第一感觉，在你的scrum生涯中，在每一个sprint后，燃尽图往上走的概率有多大，有超过50%吗？或者不超过1%？

47 楼 wwccss 2010-08-29  

引用

如果你认为和我没有讨论的基础，那我想问题在你。你就是卖Scrum产品的。我不想坏你的生意，

你在攻击别人之前，先把东西搞清楚再说。我们的软件zentao是开源软件，也就是意味着你可以不用花费任何费用来使用它。还有我们的上下文，是有个朋友在问有没有一个完整的软件研发的解决方案，所以我们提了下。如果你认为我们是在卖scrum产品，我们也无话可说。随便你怎么样吧。

scrum里面的英文单词是burn down chart，翻译过来就是燃尽图。我搞不懂这有什么神秘可言。如果你觉得这是在神秘化，我只能说你自己有毛病。我们周围那么多名词，agile, 结对编程，单元测试，mock, 代码走读，系统测试，测试用例，build，release， 哪一个不是神秘的单词？

和你没有讨论的基础，是因为你对scrum压根就没有一个正确的认识和实践，和你讨论，简直就是弹琴，一点意义没有。

引用

到达一种"知识境界"后，说服任何一方都是不大可能的。。所以就不要尝试说服了，只说实实在在的东西。

说的很有道理，你用不用scrum，认为scrum好不好，跟我没有任何关系。但是我要告诉看这个帖子的人，什么是真正的scrum。不要因为某些个人的偏激的观点，对scrum有了先入为主的判读，对自己，对团队来讲，丧失了一个公正的去对待scrum的机会。

好的东西，总会找来一些飞来的唾沫，让唾沫来的更猛些吧！

46 楼 flashing 2010-08-29  

其实吧，看完上面的讨论，我觉得很像小马过河啊，一人一个说法，都觉得有道理。其实我的看法是，的确都有道理。主要是团队不同，用的方法可能不尽相同。
wwccss看起来很有经验，但是明显我感觉你和frostred经历的团队环境不同。
btw：banq还是别看了，这人水平应该是有的，但是完全剑走偏锋；不过他的网站上n多年前的那个设计模式还可以看看，我现在一直推荐新手看那个，简明扼要。

45 楼 frostred 2010-08-29  

wwccss 写道

frostred，无语。你的这些言论只能是贻笑大方了。

scrum是一个管理框架，它只规定了最基本的实践。很多东西需要团队自我补充。比如沟通和交流，是否使用im，使用email，完全视团队情况而定。scrum并不排斥其他的东西。

至于说到燃尽图，你连燃尽图都没有画出来过，你怎么知道燃尽图没有用？相比较于甘特图，燃尽图是最直观，最实效的一个图。

scrum一点都不神秘，它是实实在在的东西。如果你觉得他神秘，只能是你自己的问题。
不想再和你争论了。一点讨论的基础都没有。你还是做你传统的项目经理吧。scrum肯定不适合你，因为你肯定做不了一个合格的scrum master。

不知道我的哪些言论贻笑大方了。如果我的言论你有不同的意见，请具体的指出来。

我没有说Scrum一定不好，我只是说Scrum中一些能成为证书，产品卖点的东西，被人大说特说，而一些更重要的有关Agile理念性的东西，却被一带而过，甚至是被故意忽略（因为，Agile的核心理念是不依赖过程和工具，尤其是重量级的，号称能解决一切问题的工具。注意是“不依赖”，而不是“不使用”。 因此，有的东西是卖产品的人不愿多提的。）。所以很多人被这种Scrum误导。

至于说到燃尽图，你怎么知道我没用过燃尽图？
依赖任何图表来了解，管理项目进度的方法，都是不现实的。我想真正有经验的项目经理都是有同感的。真正想了解项目的进度，你必须进入到项目中去。不然，你看多少图表都是没用的。

我是不觉得Scrum有什么神秘的，可有些人在神秘化它。比如说燃尽图这个名字，听上去就够忽悠人的。

如果你认为和我没有讨论的基础，那我想问题在你。你就是卖Scrum产品的。我不想坏你的生意，但技术讨论归技术讨论，我必须说我想说的。抱歉。

另外，我不认为我是传统的项目经理。事实上，我的字典里没有“传统的项目经理”和“时髦的项目经理”这些词汇的。我的字典里有的是“成功的项目经理”和“失败的项目经理”，是“能解决问题的项目经理”和“不能解决问题的项目经理”。

wwccss 写道

不是打广告，建议你看下我们开发的项目管理软件-zentao，基于scrum管理方式，完整的涵盖了产品管理、项目管理、测试管理，以及事物管理，组织管理和文档管理等核心功能，为软件研发企业提供了完整的项目管理解决方案。

你这还不是打广告。你要怎样才算是打广告？
敏捷开发，最反感这种号称能解决一切问题的一揽子的解决方案或工具。敏捷开发，提倡的是针对不同的问题，找到和使用最好用的，最轻量级的工具。用过ruby on rails的朋友，一定明白我在说什么。

44 楼 lookdd1 2010-08-29  

到达一种"知识境界"后，说服任何一方都是不大可能的。。所以就不要尝试说服了，只说实实在在的东西。
我们的团队水平都很菜，甚至都有没听说过单元测试这一说的，所有成员都没听说过scrum这个单词。我也没有告诉大家。我们只是制定sprint，分配任务，每日站立会议，燃尽图，总结会议。也许是之前简直处于一种无管理的状态，所以突然改变为scrum带给大家的感受是很棒的。它讲究实效，没有形式化，小步快跑，及时反馈，及时响应，节奏感更好。我们不管是不是scrum，不管是不是敏捷，我们只是感觉灰常不错,这就OK。

43 楼 wwccss 2010-08-29  

感谢刚才的那位朋友说我是banq，我刚刚查了下，应该是http://www.jdon.com/这个网站。谢谢，我又找到了一个很好的学习的地方。

42 楼 wwccss 2010-08-29  

banq，我不知道是谁。你肯定认错人了。

引用

不要以为自己是 scrum 先驱，这个词已经被炒烂了，我们需要的是符合我们情况的实践，

我没有自诩是scrum的先驱。我在中国雅虎的时候，有幸在hero的主管下面，亲身参与了3年的scrum项目。hero以前在doubleclick工作，doubleclick也是实施的scrum。他把scrum引进了中国雅虎。作为 scrum项目的成员，我经历了大大小小的项目。也亲身经历了scrum给大家带来的变化，以及失败的地方。scrum实践起来并不那么容易，正是因为大家往往对他有改动。我从ali离开之后，和hero讨论过这些问题。我觉得scrum的总结会议，演示会议，以及产品经理没有参与到项目中，这是scrum实施不是很好的地方。

04年我也有带领6人左右团队，采取敏捷开发里面的一些基本实践，就是任务细化，然后尝试结对编程，成功的将一个网站改版，升级，并几乎以两周为一轮的速度发布新版的功能。这个网站现在已经成为滚滚的现金流。

06年也有做过echsop第一个版本的项目，很失败，完全是靠强权，保证的项目进度。我一直对这次的项目感到很愧疚。对不起参加项目的朋友们。09年我也在另外一家公司推行scrum，成功了实施了5轮的sprint，成功上线一个基础性的项目。

我只是看到大家所讨论的scrum，其实都不是scrum的本质。scrum的核心东西，就是那些个简简单单的实践，你只要去做就好了。做的不好，往往是我们没有严格去遵循它。

41 楼 haha1903 2010-08-29  

很支持楼主的看法，基本上和我们的实践差不多，只是我们是在站立会议的时候，把进度情况了解一下。

看到 wwccss 的头像，就会想起一个人 -- banq，看了帖子内容，我就更加相信我的感觉了。

不要以为自己是 scrum 先驱，这个词已经被炒烂了，我们需要的是符合我们情况的实践，而不是你在那里的理论。看你的言论，我相信，你没有建立实施你理论团队的能力。

我个人的感觉是，无论是 scrum 还是 xp 都有很多非常好的实践，但毕竟这些实践和一些人之前的行为方式不一样，会带来一定的排斥，所以我都是尽量的用简单的方式引用这些实践，同时要尽可能快的让大家看到收益，这样才能让人尽快的接受这件事情。

40 楼 wwccss 2010-08-29  

frostred，无语。你的这些言论只能是贻笑大方了。

scrum是一个管理框架，它只规定了最基本的实践。很多东西需要团队自我补充。比如沟通和交流，是否使用im，使用email，完全视团队情况而定。scrum并不排斥其他的东西。

至于说到燃尽图，你连燃尽图都没有画出来过，你怎么知道燃尽图没有用？相比较于甘特图，燃尽图是最直观，最实效的一个图。

scrum一点都不神秘，它是实实在在的东西。如果你觉得他神秘，只能是你自己的问题。
不想再和你争论了。一点讨论的基础都没有。你还是做你传统的项目经理吧。scrum肯定不适合你，因为你肯定做不了一个合格的scrum master。

39 楼 frostred 2010-08-29  

xfly_t 写道

首先scrum还是非常有用，比如任务板、迭代时间的控制。

引用

如果说站立会议是有小益而无大害的话，燃尽图就是scrum中最胡扯淡的东西。如果是一个项目经理只靠燃尽图了解项目进度的话，那这个团队的交流就是太差了。

我认为站立会议中问题主要是得到的信息不足，实践一段时间大家都累了就不搞了。只靠燃尽图的确比较扯

引用

更好的手段，如pair programming，code review

另pair programming，code review 项目压力及时间要求也没那么好解决

PS：呵，一直在提出问题，希望大家共同探讨出解决方案或是更好的实践

其实很简单，你觉得有用的你就用，没用的就别用。觉得有用，但不容易实施的可以一点一点的尝试着来。
建立一个好的团队，人是最重要的，其次是建立好的氛围，然后才是选择合适的过程（process）和工具。反过来，迷信过程和工具，一定会适得其反的。
把什么东西都搞得神秘兮兮的，一定是忽悠人的玩意。

38 楼 xfly_t 2010-08-29  

首先scrum还是非常有用，比如任务板、迭代时间的控制。

引用

如果说站立会议是有小益而无大害的话，燃尽图就是scrum中最胡扯淡的东西。如果是一个项目经理只靠燃尽图了解项目进度的话，那这个团队的交流就是太差了。

我认为站立会议中问题主要是得到的信息不足，实践一段时间大家都累了就不搞了。只靠燃尽图的确比较扯

引用

更好的手段，如pair programming，code review

另pair programming，code review 项目压力及时间要求也没那么好解决

PS：呵，一直在提出问题，希望大家共同探讨出解决方案或是更好的实践

37 楼 frostred 2010-08-29  

wwccss 写道

引用

只是近几年被卖证书和卖产品的人搞的越来越面目全非，越来越远离Agile的核心理念

你说的太偏激了。国内其实还没有多少公司在做这种方面的认证和产品。你在网上搜索scrum，有效的资源也很少。我觉得你是下意识的在排斥一种对于自己陌生的东西。通过将scrum牛魔化，来证明自己不实行scrum是对的。其实真正的改变，是要从自己开始。你自己不改变，那么实行的scrum，还是具有中国特色的伪scrum .

第一， 我没说问题只是在国内。
第二， 你怎么知道scrum对我来说是一种很陌生的东西？

wwccss 写道

引用

比如站立会议中一半的以上的人一周的反馈基本是：我昨天在做A模块(xxx部分)，今天还做A模块(xxx部分)，没什么问题（还在写代码能有什么问题）。 如果是这样的交流，感觉意义不大。或有什么更好的交流方式？

很多人说没有问题，其实可能很有问题。如果这个人在站立会议上不说的话，那么就需要观察整个团队燃尽图。什么是燃尽图呢？就是这一期srpint中，所有任务预计剩余时间的总和累加起来，然后每天画一个坐标，形成一个燃尽图。如果大家都在说没有问题，但燃尽图是平的，甚至上扬的，就有问题了。

如果说站立会议是有小益而无大害的话，燃尽图就是scrum中最胡扯淡的东西。如果是一个项目经理只靠燃尽图了解项目进度的话，那这个团队的交流就是太差了。

wwccss 写道

引用

Agile强调交流的重要性，Scrum就整出个站立会议来。
当然，如果它是一个团队唯一可行的交流方式，它也无可厚非，毕竟它只用５到１５分钟。但在每天固定的某一个时间打断每一个成员的工作，毕竟不是一个好的方法。
而且，　因为它只用５到１５分钟，所以交流的信息量是很有限的。还有它是在每天固定一个时间进行，所以有些时候，对于某些问题也是不够及时的。
其实，站立会议违背了交流的最基本的特征的。交流的需要往往是非常随机的，你往往不知道什么时间需要交流，有时候你只需要一分钟来交流，有时候你需要几个小时。

这是完全在曲解scrum的站立会议。站立会议是整个团队每天的一次沟通，这并没有说，团队就不能有其他的交流方式。相反，面对面的交流，团队成员坐在一起，客户也尽量坐在一起，有问题随时解决。极限编程里面的各种实践都可以用上。你又在妖魔化scrum .

我不认为自己在曲解scrum的站立会议。我的观点是，站立会议所交流的信息是“昨天干了什么，今天准备干什么，有什么困难”。　站立会议不是交流这些信息的最佳手段，如果用其他的交流手段，大伙已经知道了这些信息的话，站立会议就是完全没有必要的。如果没有更好的手段，站立会议也未尝不可。问题是，scrum中，从来不强调那些更好的手段，如pair programming，code review。也不强调建立交流氛围的重要性。给人的感觉是，每天开个站立会议就万事大吉了。

wwccss 写道

引用

所以说，如果它是一个团队唯一可行得交流方式，站立会议也没什么大问题。毕竟，用５到１５分钟了解一下大伙都在干什么，有什么问题，也是不错的。问题是它跟敏捷开发扯不上什么关系，更不是敏捷开发的充分必要条件。

scrum和极限编程是敏捷开发比较流行的两种方式。scrum更偏重于管理层面的东西，而极限编程(xp)更偏重于开发实践。两者并没有冲突。

我没说两者有冲突，我只是想让大伙明白什么是Agile,什么是Scrum，什么是卖证书，卖产品的人兜售的Scrum。

36 楼 daquan198163 2010-08-29  

就像IO一样，交流也分同步和异步（或者阻塞和非阻塞）两种，
面对面交流是前者，对于一些需要集中讨论的问题比较适合，效率最高，但成本也最高；
email、文档等属于后者，优点是成本低、容易归档、可以跨越时空交流、可以单向交流；
如果团队不是分布式的，而是坐在一起的，那同步交流不成问题，随时可以进行，
根据我的经验，大多数团队的异步交流做的不好或者方式不对，
有的文档太多、太重，有的email满天飞，
最严重的还有的根本就没有异步交流，所有信息都记在每个人的脑子里，想起来了就同步交流一下，想不起来话，睡一觉之后大脑内存清空了，又开始了全新的一天

最后我想说的是，工具很重要，
能够支持多人异步交流的是什么样的工具呢，office肯定不行，我觉得只有专业的协同开发平台可以做到，
成熟的也有很多了，比如JIRA、trac、Jazz、redmine

35 楼 wwccss 2010-08-29  

引用

只是近几年被卖证书和卖产品的人搞的越来越面目全非，越来越远离Agile的核心理念

你说的太偏激了。国内其实还没有多少公司在做这种方面的认证和产品。你在网上搜索scrum，有效的资源也很少。我觉得你是下意识的在排斥一种对于自己陌生的东西。通过将scrum牛魔化，来证明自己不实行scrum是对的。其实真正的改变，是要从自己开始。你自己不改变，那么实行的scrum，还是具有中国特色的伪scrum .

引用

比如站立会议中一半的以上的人一周的反馈基本是：我昨天在做A模块(xxx部分)，今天还做A模块(xxx部分)，没什么问题（还在写代码能有什么问题）。 如果是这样的交流，感觉意义不大。或有什么更好的交流方式？

很多人说没有问题，其实可能很有问题。如果这个人在站立会议上不说的话，那么就需要观察整个团队燃尽图。什么是燃尽图呢？就是这一期srpint中，所有任务预计剩余时间的总和累加起来，然后每天画一个坐标，形成一个燃尽图。如果大家都在说没有问题，但燃尽图是平的，甚至上扬的，就有问题了。

引用

Agile强调交流的重要性，Scrum就整出个站立会议来。
当然，如果它是一个团队唯一可行的交流方式，它也无可厚非，毕竟它只用５到１５分钟。但在每天固定的某一个时间打断每一个成员的工作，毕竟不是一个好的方法。
而且，　因为它只用５到１５分钟，所以交流的信息量是很有限的。还有它是在每天固定一个时间进行，所以有些时候，对于某些问题也是不够及时的。
其实，站立会议违背了交流的最基本的特征的。交流的需要往往是非常随机的，你往往不知道什么时间需要交流，有时候你只需要一分钟来交流，有时候你需要几个小时。

这是完全在曲解scrum的站立会议。站立会议是整个团队每天的一次沟通，这并没有说，团队就不能有其他的交流方式。相反，面对面的交流，团队成员坐在一起，客户也尽量坐在一起，有问题随时解决。极限编程里面的各种实践都可以用上。你又在妖魔化scrum .

引用

所以说，如果它是一个团队唯一可行得交流方式，站立会议也没什么大问题。毕竟，用５到１５分钟了解一下大伙都在干什么，有什么问题，也是不错的。问题是它跟敏捷开发扯不上什么关系，更不是敏捷开发的充分必要条件。

scrum和极限编程是敏捷开发比较流行的两种方式。scrum更偏重于管理层面的东西，而极限编程(xp)更偏重于开发实践。两者并没有冲突。

最近两个多月来关注javaeye，但说实话，让我非常失望。我已经看到很多人带着桎梏在跳舞，抱残守缺，不肯改变自己，不肯去尝试新的东西，新的理念。天花板啊！