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

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

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

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

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

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

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

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

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

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

我认同敏捷理念，但对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可以很长很长。大部分也不是直接与楼主的问题相关。但管理项目主要是与人打交道，而与人打交道，往往是这种小事，潜移默化的影响了最终的结果。

先不跑题，说说我们实践过的几种进度反馈方式：

• 站立会议，不说了
• 腾讯群，不知道有多少人用过，我们是在培训一些实习生时发现的，几个实习生建了一个群，在里面交流，后来我也加入群，可以及时了解他们的情况，也可加以指导，腾讯群有记录可以查询，可以方便的截图，可以群发邮件，可以改腾讯签名来汇报工作状态。我觉得是一种不正式但非常有效的方法
• wiki或blog，对于一些技术研究类或解决问题类的工作，我们要求写wiki，如果不是很商业的东西，也鼓励发blog
  
• 微博，呵呵，用javaeye 的闲聊就不错，因为有个firefox插件，可以很方便的报告自己的情况，和了解他人的情况
• 通过daily build 的报告，从邮件，rss 或是fisheye 里就可以了解
• rss订阅，除了第一二个，都是通过rss 订阅来了解，而且一定要，这样减低了获取信息的麻烦度，让沟通可行性提高
• jira也用过，发现还是对bug 或一些任务性很强的工作比较合适，对开发工作的情况记录和反馈不太合适。还有写每周报告excel 表，改甘特图等不太成功的方式

再谈谈敏捷或是scrum吧，我们实施scrum，我觉得大部分不成功，后来自己总结的看法是：

 

楼主就不说了，wwccss春哥把scrum说的很简单，我觉得是不对的。我认为成功的实施敏捷，是一件难度很大的事。

• 首先是技术上的，敏捷不光是管理和方法，而且需要很好的技术支持，就像光有精益方法但没有很高的生产技术和技术水平很高的产业工人，还是做不到精益一样。具体到软件开发，重构和TDD 就会难倒一大批人，没有TDD就难以保证对需求的覆盖度和正确度，没有refactoring，就不能保证设计的良好。所以我认为，这两个做不到很好就不要谈敏捷
• 其他不那么技术的东西是不是就容易呢，也不一定，如果只是看了“硝烟”书，就认为自己学会了敏捷，并且想通过实施来获益，我认为很不靠谱，失败机会很大。很简单，站立会议，到底该讲些什么，这个如果不是很有经验的人来现场长期引导，很容易就讲歪了，被变味了

要建立实施scrum，我认为要做到以下几点：

• 首先要有高技术水平的团队，至少有一半是真正的程序员（真正程序员我也不好定义，反正理解为所有编代码的人里不到10%的可以是真正程序员就可以了）
• 团队中能有一个或多个通过了scrum中级以上培训认证的人担任scrum master
• 如果可能，团队实施初期，请专业的顾问公司对团队成员进行培训，甚至聘请顾问参与团队

反正我认为，要敏捷，就认真去做，不要搞什么我只借鉴部分思想，我搞个中国特色的敏捷，那还不如你自己搞自己的土飞机呢（没有贬低土飞机的意思，这也是一种可以成功的方法）。

难是不是就做不到呢，mba难吧，雅思难吧，还是大把人去，小公司只要肯搞，先抽出三四个人的精英团队，走正确的路，也是有得搞的。

敏捷=高效!=简单

 

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

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

能不能请您指出来，我可是抱着交流和学习的目的来的。

公司最近一直在搞scrum。从一个developer的角度看来，scrum，至少我们实施的以及绝大多数我所了解的scrum，用处不大。 从一个developer的角度看，一个项目要想作的好，无非是三点： 1）程序员了解业务，了解需求 2）程序员有能力清楚，正确，高效的完成代码 3）人员交替时能顺利完成代码移交，不出现知识遗漏 对于1，scrum没有任何真正有效地手段，站立会议强调的是让大家了解别人的进度，对于如何让程序员深入业务，思考流程，scrum都没有说。XP里面还有个现场客户的概念，要developer和客户现场交流，虽然实施起来有难度，但毕竟是一个方向；而且一旦实施起来，能够接触第一手客户对于developer了解业务确实有很大帮助。而scrum呢？当然你可以说scrum也只是一个方法论，这个应该由具体项目去解决，不过这样还要你scrum有何用？ 对于2和3,这是我觉得scrum实施最让人不舒服的地方。XP里面解决这个问题的核心是TDD，有了TDD才有refactor，有了refactor才能让你在对业务有了新的了解后敢于将其反映到原有代码中，而非不敢动原来的，另搞一块。搞TDD对程序员的要求高一些（同时对程序员的提高也快一点），在我看来这是个能力问题，而scrum却没有谈程序员的能力差别，给我的感觉是“用了scrum，把能力问题通过流程的方式解决”。这不是扯淡嘛！敏捷本来就不是什么人都能用的，如果你找的都是1000块的代码工人，最好的方式就是外包公司那样反复的review再review，还搞什么敏捷？ 总体来说,scrum那些best practices，像什么sprint，stand meeting，daily build大多容易实施，这大概也是为什么有那么多scrum master能被生产出来的原因。但一把号子容易吹响也就意味着容易吹跑调，而scrum的实施者只会说“听啊，我们吹的多响！”却绝不会说“天啊，我们吹得多难听！”。 站在项目管理的角度，燃尽图让PM不再那么彷徨，能够得到一丝掌握世界的安全感。我想，这大概是为什么那么多项目组容易被scrum打动，进而实施scrum的原因，除此之外，我真的想不出为什么会有这么多人追捧scrum。

1. scrum和极限编程的概念你并没有搞清楚。这两者都是敏捷开发的两种常见的方法。可以互相结合。但如果一个scrum团队并没有实行xp，人家也是敏捷开发。我发过一个帖子，你仔细看下。http://www.iteye.com/topic/750483

2. scrum里面的实践都是相辅相成的，你单纯的割裂来看，没有意义的。是的，单纯的靠站立会议，或者燃尽图，肯定不行。这都是常识。可是人家scrum是一个完整的体系。你非得把人肢解了批判，态度就不对。

3. 你说的项目经理要深入到项目团队中，scrum从来也没有说，项目经理就只看燃尽图和召开站立会议。scrum照样强调团队要做在一起，要面对面的沟通和交流。

4. 其实scrum master和你所说的项目经理，有一个很重要的区别。我们大家做项目经理，恨不能什么东西都要自己做。或者别人做个东西都不放心。我想大家都有过这样的经历。其实真正的管理，是无为而治。scrum master 并一定要写代码，也不要去看代码写的怎么样。我们常说的外行领导内行，是很有道理的。这一点你体会到了，管理自然会上一个台阶。

5. 你太强调项目经理个人的作用了，真正的敏捷，是团队在作战，不是项目经理自己跳舞。所以放手，调动大家的积极性，建立真正互相信任的团队，这才是真正的敏捷。

从我的观点，xp要比scrum更难以执行。xp实施要求的条件比scrum要更高了。scrum在规定了最基本的管理框架之后，并没有限制你身体的过程如何。这是它的魅力。包容。

scrum可以很清晰的指导一个团队什么时候该做什么事情，这已经足够了。它需要执行的地方很简单。简单的东西不好吗？有一个简单可以操作的东西，让大家去执行，可以上路，这就足够了。在前进的过程中，完善自己的装备，强大自己。

不是说一定要上了tdd，施行了重构才是敏捷。敏捷有很多种方式。拿到最终的结果才是真的敏捷。

我04年就尝试过极限编程，曾经推行过结对编程。但实施过程遭到了很多人的质疑，包括公司的领导。单元测试，国内真正搞起来的团队有几个？更不要说测试驱动开发了。国内真正能够实践极限编程的团队，凤毛麟角。

没有极限编程的最佳实践（如tdd、重构、ci）支持，scrum就会变成“行为艺术”，呵呵