
硝烟中的Scrum和XP
在本书中,作者Henrik Kniberg讲述了他在一年的时间里,带领40人的团队实施Scrum的过程。他们试过了多种团队尺寸(3~12人)、sprint长度(2~6星期),定义“完成”的不同方式,不同的backlog格式,各种测试策略,在多个Scrum团队之间进行同步的多种方式。他们还尝试过XP实践——持续集成、结对编程、测试驱动开发等等,还试过了把XP跟Scrum组合。

在本书中,作者Henrik Kniberg讲述了他在一年的时间里,带领40人的团队实施Scrum的过程。他们试过了多种团队尺寸(3~12人)、sprint长度(2~6星期),定义“完成”的不同方式,不同的backlog格式,各种测试策略,在多个Scrum团队之间进行同步的多种方式。他们还尝试过XP实践——持续集成、结对编程、测试驱动开发等等,还试过了把XP跟Scrum组合。
Github在RubyFringe大会上演示了名为Gist的新服务。除了一般代码粘帖服务都有的功能之外,它还有自己的绝招:可以像git仓库一样访问粘帖的代码片段,还可以在Gist的Web界面上更新代码。
链接开放数据合作项目(Linking Open Data Community Project)已经完成了一个全球性的REST式SOA方案,人们可以通过它访问来自大约50个分布式提供者的超过20亿个相互链接着的断言(RDF三元组),不过有一个限制: 这个帅呆了的网络只能提供只读访问。 而即将到来的SPARQL Update语言将解决这一问题。
假想一下,如果要以最小的集成代价实现一个分布在全世界范围的信息空间,用它来共享机器可识别的数据,会怎么样?这是关于REST的吗?不是的。根据 SWEO的说法,这跟语义网有关。那些Cool URI有助于实现这种方式。所以,去看看RESTful SOA URI是不是也很“酷”可能是值得的。
庞大的团队规模妨碍了对很多语言抽象工具的运用,也限制了生产效率。Reg Braithwaite认为不应该为了团队规模去调整工具,他提倡围绕工具去建设团队,并保持团队的小型化。然而很多时候团队增大是不可避免的。在此情况下又该如何去维持质量和生产效率呢?

敏捷的“自组织团队”模式需要团队成员们具备新的技能——包括他们曾寄希望于项目经理具备的人际交往技能。此时,管理不再是多余的东西,它对帮助团队学习新的沟通和协作方式起到了非常重要的作用。本文为如何传授新的技巧给出了一些策略,并提供了一些相关资源。
如今,随着劳动力的不断全球化,面对面会议正在变得越来越稀少。在办公场所里面,我们通过由桌面共享工具支持的电话会议专线来完成业务的处理过程,这种体验与以前完全不同。本文中介绍了一种刚刚出现并且非常重要的技能:如何使用种种技巧和窍门来有效促进远程互动过程。

团队采取项目回顾措施,可以检查在项目中哪些事情做对了,哪些事情做错了。但是传统的回顾(有时被称为post-mortems,即盖棺定论)只在项目结尾时进行,由于时机过晚,很难对团队和项目起到什么帮助。敏捷团队需要迭代式和增量式的回顾,以尽快精确定位问题,设计解决方案,来使得团队可以早日改进,从而产生更好的收效。

敏捷团队中的人们发现,过去传统的工作空间也是有其可取之处的。当人们彼此坐在一起,不受外界干扰并以敏捷的方式工作,就更有必要强调人们对健康、有效的工作空间的需求。为了说明这一点,本文与各位读者分享多位敏捷教练收集和整理的智慧与经验,这些智慧来自他们以往与众多团队共同工作时的丰富经历。

在本书中,作者Henrik Kniberg讲述了他在一年的时间里,带领40人的团队实施Scrum的过程。他们试过了多种团队尺寸(3~12人)、sprint长度(2~6星期),定义“完成”的不同方式,不同的backlog格式,各种测试策略,在多个Scrum团队之间进行同步的多种方式。他们还尝试过XP实践——持续集成、结对编程、测试驱动开发等等,还试过了把XP跟Scrum组合。