是从尹伟铭的blog那里看到他在实施这个方法，非常感兴趣。正好他以前在搜狗的时候就互相认识，因为好不容易在别的部门找到一个泡华蟒的，就把他约来和我们这里几个同学一起聊了聊。。。饭桌上发现他还有139工作的经历，又多了若干彼此都很熟悉的联系人，相谈甚欢。
尹老师这人又有能力，又有冲劲，将来一定有不小成就。
这个方法需要技术、产品、测试共同参与，所以还是先从邮件中心最近的两个项目开始尝试了。初期参与的开发人员数名比较少，对过程的改善作用从技术开发的角度看还不太明显，但个人觉得从测试和项目控制的角度看，比以前已经进步很多了。
本周一邀请尹老师来参观我们的晨会，他又提出好多意见。计划下旬我们派几批人去集体观摩人家的晨会
如何提高项目组织能力，一个很大的题目，希望邮件中心的尝试，能在2011开一个好头
Topic:
本站的feed
评论
以前一个PM带着用过这种方法，效果是说得过去的。 就是很多
以前一个PM带着用过这种方法，效果是说得过去的。
就是很多人痛恨那么早就开会 -_-!
这是传说中的故事卡片->任务卡片吗?
这是传说中的故事卡片->任务卡片吗?
额，我们早晨是直接对着bugzilla的单子开晨会。
额，我们早晨是直接对着bugzilla的单子开晨会。
你们这个是打印出来再开会吗？还是每个人带个屏幕
你们这个是打印出来再开会吗？还是每个人带个屏幕
Leader拿台本即可，对本周bug单子完成状态一排序，就
Leader拿台本即可，对本周bug单子完成状态一排序，就好。
个人觉得如果想做得比较好，可以在bugzilla上做点二次开发，图形化支持下burndown chart即可。
之前用过pivotaltracker，感觉不错，几个spr
之前用过pivotaltracker，感觉不错，几个sprint下来，可以比较清楚的得出team的velocity；
另外晨会不应该太长，之所以叫站立会议，就是站着太久会累不至于拖得太长，最好每人1~2句话就把各自昨天做过的和今天要做的描述清楚；
我们之前的做法是，站立会议结束后不同的pair再下来各自更新backlog。