剖析短迭代
敏捷教练Dave Nicolette提出:我们应该如何设定迭代长度?是要根据发布周期的时间么?使用短迭代又有哪些好处?
作者 Pete Johnson译者 郑柯 发布于 2007年12月26日 上午7时20分
当我第一次开始远程电话会议时,还是在1997年,从Dallas到Palo Alto。在参加的那些会议中,我几乎总是唯一的远程参会者。不过,在最近这几年里,一个会议中每个人都在不同的物理位置,这样的状况已经越来越普遍了。 虽然严格的敏捷过程希望所有的团队成员都可以在同一个房间中工作,因为这样可以提升协作效果,然而这并不是总可以做到的。比如,你不能说服那个Ruby编 程牛人到Cleverland(或者其他你所在的什么地方)来,要想与这位天才一起共事,你必须彼此远程工作。越来越多的项目为了解决不同方面的问题,要 充分发挥全世界不同地理位置的人们的才干,而且这种趋势看来短期之内不会结束。因此,掌握了有效举行远程会议能力的人就比其他人更有可能拿到管理层分配的 红包啦。
无论你的会议是否是远程的,将带有序号的会议提纲随着会议邀请发送总是一个不错的实践。这可以告诉大家会议上要讨论的议题,并给出可以根据实际情况 调整的会议结构,因为要明白无误地告诉大家为什么他们应该花费他们有价值的时间来参加这个会议。对于远程会议来说,提前传递这些信息,特别是说明为什么大 家要参加这个会议,相对面对面的会议来说更为重要,为什么呢?
如果你曾经在远程会议上走过神儿,去做诸如检查橄榄球出场名单和迷失在Wikipedia之中这样“重要”的事情,请你举手。当然,我就曾经这样做过,并 且产生了负罪感。你会在一个面对面的会议中做这样的事情么?当然不会,其他的与会者会很容易发现你的眼睛总是盯着你的笔记本电脑的屏幕,而不是注意会议上 说了什么。
由于更不容易被发现,相当于面对面会议,人们更容易在远程会议中将注意力放在别的地方。有鉴于此,你不止要将会议提纲公之于众以让与会者明白他们为什么要参加会议,而且要按顺序介绍这些提纲,并反复引用它们,以帮助与会者知道什么时候应该集中注意力。
当你在电话中表现得非常强势的时候,要在远程会议中以经过小心措词和组织的会议提纲为核心是很困难的。由于没有视觉线索(visual cues),作为会议的推动者,要想打断那些想要掌控会议的参会者就更加困难。除了要以会议提供为中心之外,你还要给安静的参会团队成员们同样的发言机 会。
在《蝇王》一 书中,书中的角色通过构建下面的规则克服了类似的问题:谁拿到了指定的海螺壳,谁就可以发言。你可能必须要成为一个强势的会议推动者,并使用一个虚拟的海 螺壳,将其传递给所有的与会者,并分配给每个人5分钟的发言时间,让他们畅所欲言。会议中相对寡言少语的人可能会放弃他们的发言时间,不过更喜欢发言的人 们就不会太过于脱离你的会议提纲中给出的提议了。应用这个策略时,使用即时消息工具来让人们开始或停止发言,也是个很有效的实践。
要想保住一个好的会议室是很困难的,因为管理层总是要占住不放;同样地,远程会议也有自己的后勤问题要解决。根据其本身特性,远程会议有可能会包括 涉及多个时区的人。作为会议的领导,你要保证参会的每个人都以一个合理的当地时间来参加会议。对于一些参与者会跨越12个小时并且反复进行的会议来说,要 轮换会议开始时间,以避免总是影响同一个人的个人生活来参加会议。
基于你的电话系统的工作机制,要保证会议同时具备付费和免费两条电话线路是个不错的主意。比如:如果每个人都在远程办公室中参会,一个免费的电话线路省不了什么钱。如果有人是从类似旅馆之类的地方打电话参会,那么为一个免费的电话线路多付点钱就值得了。 不管使用什么何种桌面共享解决方案,都要把连接信息发送出去(不管是URL,IP地址或是其他你的软件需要的信息),要么随着最初的会议邀请,要么是在会议开始几分钟之前发送一个更新版本。没有什么比下面这个用到NetMeeting的场景更糟糕的状况了。【你拨号进入,激活了会议线路,并试图开始后续过程,可其他人却来晚了。】
你:大家好,欢迎来参加会议。我有些幻灯片要给大家看,让我告诉你们我的IP地址,这样大家都可以通过NetMeeting看到这些幻灯。我的IP是32.42.……
你:你好,刚刚加入的是谁?
Dwight:是我,Dwight。能告诉我你的IP么?
你:是的,我正要跟大家说……
Ryan:大家好,我是Ryan。来晚了很抱歉,网站刚才挂掉了。能告诉我NetMeeting的IP么?
你:当然,是32.42.33……
就是这种状况,我曾经参加过一个持续了一小时的会议,前十五分钟一直都在处理类似的事情,这让我没能赶上参加下一个会议,而且因为迟到,我也导致了类似状况的发生。先把桌面共享相关的后勤工作做好,给别人省点麻烦和时间吧。
类似于将你的笔记本电脑连接到投影仪之上,一个远程会议通常要使用某些特定的桌面共享软件。Microsoft的NetMeeting是一个常用的 选择,因为它被绑定到了大多数版本的Windows之中,并因此而免费。使用它有一个副作用:在默认模式中,会议的主持人和第一个加入者会收到其他每个希 望加入会议的人员的接受请求。如果这两个人没有注意到这种状况,而且忘记了打开“默认接受”选项,就会导致会议的延迟。
作为最佳实践之一,会议的推动者要先将NetMeeting设置为“主持”模式,并在会议开始前几分钟打开自动接受请求选项,以避免类似的困扰。
另一个小窍门就是尽可能不要共享你的整个桌面。如果这样做不可行,那就关闭你正在运行的电子邮件和其他即时聊天工具。我曾在参与的一个会议中看到,某个没 有参会的人向共享桌面的人发送了一条即时信息,其中对某个参加会议的人有不敬之词。消息发送者认为他发送的是私人消息,但很不幸的是,被他所诽谤的人看到 了这条消息。很明显,你不希望发生这种状况,而且你也不想让别人看到你的电子邮件,比如其中提到了你为某个难堪的身体病症所做的挂号现在可以去求诊了。
最后,虽然NetMeeting是个很棒的工具,但是它会有容量上的问题,因为它使用你本地的电脑来将所有的信息发送给其他与会者。当你们彼此之间的地理 距离不同时,我发现:当参会者到达12个以上时,网络传输会有很明显的性能衰减。有很多种不同的在线工具可以完成同样的工作,不过需要强有力的服务器的支 持。不出乎大家所料,我偏爱使用HP Virtual Rooms,尽管我不是创建团队的一份子,我还是要说这是一个非常有效的解决方案。
如果你并不主持任何远程会议,而只是作为参与者呢?首先,要抵抗住走神的诱惑——要认真参加讨论。如果有其他特别重要的事情分散了你的注意力,向会议推动 者发送一条即时消息,以告诉他们你需要暂时分散下注意力,说明这样做的原因,并让他们知道什么时候你可以重新回到会议中。
即时聊天工具可以用于其他用途。正像一开始提到的,你可以使用它来请求暂时的干扰。在大家就某个问题展开争论时,你也可以用它来与其他人人沟通,产生偷偷 谈话的效果。我发现这一点特别有用,如果我知道有两、三个人的意见与我一致,我们大家可以就接下来讨论什么达成共识,而不必向会议中的其他参与者泄露任何 消息。
最后,要准备好你要展示的全部资料。没有人希望看到你为了找到要向大家解释的图,而在文件目录中苦苦搜寻。对于会议推动者分享整个桌面的规则在此处同样适用。
随着劳动力的不断全球化,远程会议变得越来越普遍。知道如何推动远程的互动过程而不是让自己看起来像个白痴,这个技能非常关键,而且当我们继续在分布性更强的集团公司中工作时,其重要性变得越来越大。
不妨回顾一下要考虑的一些问题:
你怎么看?在主持或是参与远程会议时,你的最佳实践是什么?我有落下什么内容么?我哪里说错了么?
在90年代中期,Pete Johnson曾创建了HP内部的第一个Web应用,接下来他曾与遍布全球的400多个工程师一起工 作,为出版物撰写技术文章,在贸易展交会上演讲,并积极参与HP的大学招聘活动,目前他是HP.com的首席架构师。他的blog是关于如何提升技术人员 的非技术技能以加速工程师的职业发展,地址是http://blog.nerdguru.net。
后勤方面的挑战
这个体会很深啊,上次开会就开成Skype Beta Test会了。
我们现在遇到的问题更加多一些,包括:
1. 语言障碍:讨论都是用英文进行的,中国这方面的反映和交流比较慢,通常参加的中方都不发言;
2. 信息不对称:参加会议的时候有些问题其他地区的已经讨论过了,但是我们没有得到更新信息;
3. 时区:通常需要很早或者很晚的上班来参加会议。
我只看到一个问题:你们的地位不重要:)
要是总不表达观点,别人讨论问题的时候就会绕过你啦。
我也只看到一个解决方法……学英文:P
如果每次你们都能提出很有价值的观点,那么对方就会很在意你的发言,地位也就越来越重要:)
对于Christine Hui的三个问题,第三个问题不大,第一和二需要反省一下自己,如果说语言不是障碍了,也许第二个问题就不存在了。在信息不对称方面,我个人认为,多是己方不主动更新知识所致!
3. 时区:通常需要很早或者很晚的上班来参加会议。
先前的公司就是这样,远程会议也仅限于leader级别,再由leader把信息传递给我们。
本文主要讲述了如何用JBoss Portlet Container 和JBoss Portlet Bridge创建新项目,怎样配置一个JSF应用去使用JBoss Portlet Bridge,以及JBoss Portlet Bridge所具备的功能。
在这篇文章里,Bryon Jacob和Chris Berry将和我们继续探讨AtomServer,它是基于Apache Abdera的完整Atom存储实现。作者还创建了几个Atompub规范扩展,其中包括自动标记、批处理和Feeds聚合。
InfoQ中文站的电子杂志《架构师》试刊第二期出版了!相比于上期,我们在内容的选择安排和版式上都根据读者的意见重新做了修正。“细节决定成败”,我们希望基于InfoQ中文站的专业内容,《架构师》能逐渐成为大家喜欢的电子刊物!
在本文中,Steven Haines探讨了Web应用性能调优问题。该领域过去更像是一门艺术而不是一门科学。他提出了一种称为基于等待调优的方法,使整个调优过程更加可度量,也因此更具科学性。
通常来说,改变技术路线时最艰难的部分是辨别语言语法之间的不同。这篇文章就为Java开发者提供了一份如何转向Flex基础语言ActionScript的指南。
本视频主要以财帮子为例,介绍了如何创建一个PV为百万级的Rails应用。其中包括:Rails应用的服务器架构、Rails Cache的优化、负载均衡的处理、Web服务器的调试、分布式解决方案、Open API的设计等等。
InfoQ首席架构师Alexandru Popescu在采访中谈论了InfoQ架构、Webwork与DWR、Hibernate与JCR、Hibernate可扩展性、最新的InfoQ视频流系统和InfoQ的未来规划。
5 条回复
回复