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

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

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

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



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

hoho，此图甚好。

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

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


这个图上可以看出，项目经理需要汇报的路线有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条线，不知道谁会关心，如果需要这张图来了解项目进度，通过看这张图来判断项目的异常情况，那么部门经理和项目经理就太不称职了，都应该换掉，而且最关键的一点是，开发工作只是整个项目的一个环节，靠这张图是无法了解整个项目的进度的。

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

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

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


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


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

  这也是我一直的观点：没有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真就是个花花架子了。