工作进度反馈，有一种更优雅的方式吗？
工作进度反馈，这是站在员工角度的一种描述。如果站在管理者的角度，是工作进度跟踪，它的目标是为了让项目进度可控，从而降低项目风险。
它的表现形式是日报、周报，工具可能是在线填报、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工作日志、每日邮件通知、甘特图更新，我还是回到探寻问题的本源：不就是想了解项目进度和团队状态吗？而了解项目进度和团队状态，不就是为了项目进度可控和提升团队绩效吗？如果团队齐心协力、自动自发做事情，那还需要狠抓进度跟踪吗？
所以，我采取走动式沟通。当然这只是一种辅助，因为当团队超过六人，加上自己也承担具体开发任务，很容易拖延。
最重要的方法是，培养团队凝聚力+强化目标感，而在团队凝聚力(责任感+主动性)培养中，最重要是形成一种开放、信任、分享的氛围。
这东西有点虚，但效果实实在在。因为，你会发现，员工在一个任务阶段后，会主动口头给你反馈。不过，我们目前还是没有达到理想的状态。
但我这种方式，并不适合大公司，特别是大型团队，因为它们更倾向于制度化管理。它们的日常管理工作，不应该依赖于管理者的个人英雄主义。
如果有一个项目立项，临时组建一个团队，要培养彼此间的高度信任，何其难。因为信任的建立，是一条漫漫长路。
wwccss同学，我可没有说Scrum行不通，如果说行不通，也是在我这儿不太可行。
我也来传一个，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条线，不知道谁会关心，如果需要这张图来了解项目进度，通过看这张图来判断项目的异常情况，那么部门经理和项目经理就太不称职了，都应该换掉，而且最关键的一点是，开发工作只是整个项目的一个环节，靠这张图是无法了解整个项目的进度的。
目前这些敏捷方法都有其商业目的，理念很好，但怎么落地就要掏银子请顾问咨询。说是人人都有佛性，只要顿悟就可以立地成佛，不过怎么顿悟，需要高僧来渡你，不给香火钱怎行，再说这些真是高僧？
第十五期的燃尽图，走得不是很好看，因为我们团队的小姑娘任务估计太客观，有的任务一直没有解决，所以曲线图是平的。还有就是周末休息。这个项目还在继续。
所以，要相信自己选择的东西。后来呢，看国家队换来换去，始终没有自己的风格。而日本和韩国，几十年发展自己的方向，现在已然是世界强队。
其实成佛的路很多，选那条路都没有根本的区别。关键在于选择了路之后，就不要犹豫，勇往直前！ 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真就是个花花架子了。
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有很多的偏见了。因为大家都是开发人员，更多的是站在开发的角度来谈论这个问题。 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就是作为一种“容易掌握的敏捷方法”粉墨登台的。如果这个都不相信，那只能说您是生活在象牙塔里面了。
92 楼 wwccss 2010-09-01 到这个帖子讨论，这其实敏捷开发的内容。：） http://www.iteye.com/topic/752330 93 楼 dreamkyh 2011-06-08 一周写一次周报就可以了，天天日报很烦的，弄的跟监督一样，还要整理给老板看，妈妈的，现在没事情做的时候，我都不知道写点什么了啊，都要找点事情随便写上去，经理真恶心 94 楼 JohnsonTech2011 2011-06-18 信任的建立，是一条漫漫长路。
