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

支持，工具过程只是辅助作用不能取代沟通交流

Agile强调交流的重要性，Scrum就整出个站立会议来。
当然，如果它是一个团队唯一可行的交流方式，它也无可厚非，毕竟它只用５到１５分钟。但在每天固定的某一个时间打断每一个成员的工作，毕竟不是一个好的方法。
而且，　因为它只用５到１５分钟，所以交流的信息量是很有限的。还有它是在每天固定一个时间进行，所以有些时候，对于某些问题也是不够及时的。
其实，站立会议违背了交流的最基本的特征的。交流的需要往往是非常随机的，你往往不知道什么时间需要交流，有时候你只需要一分钟来交流，有时候你需要几个小时。
所以对于交流来说氛围的创造比某种固定的实践更重要。如果，小组中每一个成员都愿意分享他们工作中的成功和挫折，都愿意帮助别人和愿意被别人帮助，那么交流自然就有了。如果小组中每一个成员基本上都知道别人昨天干了什么，今天在干了什么，项目中有什么棘手的困难，那么，站立会议自然是完全没有必要了。

偶只是略微实践过传说中的scrum。完完全全的伪敏捷啊。。。
交流不是时时刻刻的，而且交流同样是成本很高的（占用时间，打断别人的思路）。同样，团队成员不可能交流到“基本上都知道别人昨天干了什么，今天干了什么，遇到什么困难”这种程度，我开发自己的，管别人干嘛，只有老大关注这些。但老大又不可能一天老是问团队成员这些东西。所以每日早的站立会议偶实践感觉非常棒。同时，我也认为每天都要有几个小时的时间是完全无交流的时间，禁止一切打扰开发思路的事情。

大多数人都只需管好自己，少数人需要了解别人在做什么，遇到什么困难，怎么解决
同样只有少数人去才有机会管大多数人

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

团队成员交流到“基本上都知道别人昨天干了什么，今天干了什么，遇到什么困难”这种程度,　是可以做到的。尤其是真正敏捷开发的团队，更不是什么难事。
首先，敏捷开发一般尽量保持团队规模小。敏捷开发中有“ｔｗｏ ｐｉｚｚａ ｔｅａｍ”　的说法。意思是，如果两张比萨饼喂不饱你的团队的话，证明你的团队太大了。换句话说，一个团队不应该超过３个人。
３个人的团队，做到大伙都基本上都知道别人都在干什么，有很难吗？更不要说团队成员经常的做一些pair programming.

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



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



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



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

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

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

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

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



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


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


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

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


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

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

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

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