专访Jeffery Richter：Windows 8是微软的重中之重
Jeffery Richter以其多本Windows核心技术的经典著作而闻名，同时，他深入掌握微软的.NET等一系列核心技术，2012年1月，Jeffery Richter在北京接受了InfoQ中文站的专访，谈到Windows 8和WinRT编程，并就异步编程、Windows编程中的可扩展性、性能和安全性方面给出自己的建议。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
如何更好地进行每日立会？
作者 Mark Levison 译者 郑柯 发布于 2010年2月5日
如何运作好一次每日立会？有哪些最佳的技巧和方法？ 很多敏捷团队都实行每日立会实践，但是Joakim Karlsson认为：“坦白讲，大多数每日立会都很乏味无趣。”它们变成了每个人都必须被迫参加的会议，更糟糕的是：以前每周一次类似的会议，现在却每天都有。
Paul Wynia提供了一个项目的实例，其中项目带头人没有敏捷培训以及相关经历，每日立会因此变成了每日进度报告会议：
她会让每个人详细讲述各个功能特性、bug和前一天与别人的交流，还有自己的工作，包括对于马上开展的这一天的工作的估算。然后，她会与每个人讨论几乎所有的工作条目。发展到后来，人们会带着笔记本参加会议，其中写满了所有的工作细节，还要记录她分配的新任务。这个团队只有5个人，她竟然能将每日立会延伸为每天30到45分钟的会议，人们感觉无聊至极。
Paul接下来建议：立会应该限制在10分钟之内，最多不能超过15分钟。对于他自己指导的团队召开的立会，如果时间超出了，他允许团队成员自行离开，这等于给Scrum Master一个信号，说明会议的运作方式有问题。
Joakim推荐：
- 关注目标——与资深团队成员分享信息，他们会帮助整个团队在迭代中完成工作。
- 关注团队——与所有人分享信息，而不是只告诉管理人员。
- 在其他时候讨论——不要在立会中解决问题，可以安排后续时间解决，而且允许感兴趣的人参与。
- 有准备而来——要是不想拉长立会时间，团块成员需要知道你的工作成果和待完成任务。
- 关注成果——Joakim发现：“相比告诉别人自己正在完成系统的哪个部分，讨论成果能够提供更为积极的态度。”
- 做出承诺——他让人们向其他团队成员承诺自己要完成的工作，而不仅仅是机械地说接下来的24小时要做些什么。
- 指出障碍——你是不是要接触60多份文件才能完成某些细小的变更？
Mike Cohn推荐团队在任务板前举行立会，询问发言的人他们在开发哪个故事。同时，Mike指出：团队规模如果超出9个人，成员会很容易对他人正在着手的工作失去了解。
Drew Stephens指出：他的团队使用“以用户故事为中心的每日立会”。想很多敏捷团队一样，Drew也是从相对传统的立会开始的，但是当团队规模变大时，他却陷入了困境。
已经没有哪个故事的工作量能够占用整个团队的工作能力了，因此我们开始并行开发多个故事。我们也注意到：很多故事处于活跃状态的时间更长，而且开始出现被我们称为“任务尾巴”的东西（也就是一个故事陷于停滞，有一些属于该故事的、未经验证的任务连续多日处于低优先级状态）。出现任务尾巴，我们发现两个主要原因：作为这些因素的结果，我们的立会变得令人困惑：一个人谈到的故事与上一个人提到的完全不同，要想确定一个故事的进度变得很困难。人们关注的不再是要完成什么任务才能结束当前活跃的故事，而是每个人在做什么或是要做什么。个中区别并不是很大，但是带来的问题却越来越严重。
- 代码质量低下导致QA人员发现奇特却稳定出现的bug流。
- 当一个故事看起来接近“完成”状态时，开发人员转而开发其他故事，可之前的故事并没有完全完成。
他们的解决方案是：把正在进行中的故事过一遍，每个开发该故事的人针对该故事回答Daily Scrum的三个问题。如果人们同时开发多个故事，他们就要跟大家说明多个故事的情况（这可能是个“异味”）。Scrum Master会追踪谁已经发过言，如果有人说完一个用户故事后又提到另一个故事，这可能就是个障碍了。
Artem Marchenko有如下建议：
- 不许打字——如果有人在笔记本电脑（或其他设备）上做记录，他们就获得了（本不应获得的）重新阐释团队成员发言的权力。
- 如果团队在向Scrum Master汇报，那么Scrum Master就应该移开眼光，不与团队成员对视，极端情况下甚至可以转过身去。
在与Henrik Larsson的访谈中，Jason Yip（文章《光站起来还不够——每日立会的模式》的作者）指出了立会的视角发生的变化：
我曾更多地将其视为进度报告会议。然后我发现立会更关注的是承诺，主要感谢Mike Cohn的著作。近来，我更多将其视为解决问题的过程。现在，我最钟爱的形式是“走到板前”的风格，当然要有任务板/故事板。我希望更多地强调完成工作的重要性，而不仅仅是让人们尝试着忙起来。
说过这些，立会还是有些方面是这些年没有变化的，比如保证“仪式”气氛高昂的重要性，还有要与团队共同分享，而不是向领导报告。
你的团队使用了哪些有成效的方法呢？
InfoQ之前的类似内容：好立会的标准是什么？
查看英文原文：Daily Standup Tips - a Roundup
译者 郑柯 InfoQ中文站总编。做过开发，当过PM，干过销售，搞过市场，最终还是回到媒体。实用的理想主义者，相信：每天改变一点点，这个世界会更好。
me 的实践。
发表人
Chan Jackei
发表于
Re: me 的实践。
发表人
Chan Jackei
发表于
一些体会
发表人
Wang Carl
发表于
一些体会
发表人
Wang Carl
发表于
Re: 一些体会
发表人
徐 毅
发表于
白字
发表人
Kuang Kurax
发表于
Re: 白字
发表人
Dong Nan
发表于
Re: 白字
发表人
ren jacky
发表于
个人觉得立会是一个团队共享信息的机会
发表人
Tarzan Wang Tarzan Wang
发表于
-
1.确认进度是否偏离，是否已经找到了偏离的原因和解决的方法;
2.确认质量是否超出可接受的下限，是否已经找到了原因，是否准备立即解决;
3.是否存在需要team leader来协调解决的问题;
4.明确当前工作目标。 -
1、作为leader，不能够紧紧通过例会跟踪问题。
2、例会时间与够用，例会是用来发现问题的，不是用来解决问题的（复杂问题）
3、可以用GTD的思路处理大家反馈的问题：组内协调问题，给出原则，理解解决；复杂问题，给出简要建议，会后跟踪，第二天通报进展。
4、30分钟属于极限。这点很有道理，leader经常感觉时间很快就过去了，这是平时对于团队情况疏于了解的表现，导致天天在晨会上喋喋不休，无法切入要害。 -
1、作为leader，不能仅仅通过例会跟踪、管理问题。例会上要善于发现问题，并号召大家介绍进展、共享关键信息、主动暴露问题
2、时间不宜过长，30分钟以上难以让团队成员介绍。冗余的会议表明leader对于团队的状况在平时缺乏手段掌控，是危险的信号，同时也浪费团队的时间和精力
3、例会上不要解决复杂问题，可以参考DTG推荐的方式：简单的组内协调问题，立即解决；复杂的问题，如果涉及组外协调，给出简单的原则和建议，会后解决，明天通报进展。
4、会上平等，大家是否积极参加会议代表了例会是否成功。 -
例会不是立会
-
你out了，就叫站立会议，简称立会
-
长见识了～～～～
-
在 review 进度 和 质量 时，的确应该：关注“故事”而不仅仅是完成了什么，避免开发人员只关注代码完成，而忽略了“故事”作为一个工作任务的整体性。
另外，一旦开发人员声称某个“故事”完成了，就在会后立刻安排 dev demo 来确认进度和质量，并作为预先的测试，帮助 tester 了解系统实现，提早找出bug，跟 dev 沟通测试思路，完善测试用例。 -
1、作为leader，不能仅仅通过例会跟踪、管理问题。例会上要善于发现问题，并号召大家介绍进展、共享关键信息、主动暴露问题
2、时间不宜过长，30分钟以上难以让团队成员介绍。冗余的会议表明leader对于团队的状况在平时缺乏手段掌控，是危险的信号，同时也浪费团队的时间和精力
3、例会上不要解决复杂问题，可以参考DTG推荐的方式：简单的组内协调问题，立即解决；复杂的问题，如果涉及组外协调，给出简单的原则和建议，会后解决，明天通报进展。
4、会上平等，大家是否积极参加会议代表了例会是否成功。
每日例会是属于团队的，而非某个leader。不存在“某个人”通过例会来跟踪、管理问题，这是团队的事务。
更没有什么30分钟之上之说，每日例会就是“15分钟以内”，超过这个时间，请不要叫它“每日例会”。而也没有什么leader。Scrum里面只有三个角色，scrum master、team和product owner。
是否解决问题，由团队决定，而其原则是，不能超过15分钟，不能只是一两个人或部分人的兴趣。 -
个人觉得立会是一个团队共享信息的机会
立会最多可以发现些进度，故事方面的大问题，不可能代替平时的follow，更不能靠立会来解决问题
9 条回复
关注此讨论 回复