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

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

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

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

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

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

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

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

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

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

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

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

没人兜售？
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


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



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



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

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

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

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

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


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


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

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


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

你对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之后，再来评判。