让回顾更有效的五条原则
James Carr最近发表了帮助提高回顾效率的五条原则。这些原则来源于他数百次成功或失败的回顾所积累的经验。
InfoQ
InfoQ
促进软件开发领域知识与创新的传播
编辑特辑
Chris Sims
Chris Sims helps software development teams improve their productivity and happiness. His approach combines experiential training, coaching, and even direct technical contribution. Chris is the founder of Agile Learning Labs. In addition, he is chair of the IEEE Technical Management Council of Silicon Valley, and is on the board of BayAPLN, the Bay Area chapter of the Agile Project Leadership Network. Chris is a certified scrum master and practitioner, who has been leading successful agile software projects since the turn of the century. He has made a living in roles such as: Scrum Master, Product Owner, Engineering Manager, Project Manager, C++ Developer, Musician, and Auto Mechanic.
“Chris Sims”相关的内容
Chris Sims的新闻
如何评估业务价值的高低？
用于优先排序的传统敏捷方法是这样的，业务价值高的用户故事应该在业务价值低的故事之前实现。这个概念很简单，但是想要很好地实现它，必须首先拥有访问业务价值的机制。最近Pascal Van Cauwenberghe描述了一个用来定义业务价值的方法，叫做“业务价值建模”，这可能会对我们有帮助。
可维护的自动化验收测试
Dale Emery认为，有些自动化测试因为比较脆弱而且维护成本高，导致很多公司放弃了实施测试自动化的意愿。在一篇最近发表的文章中，Dale共享了一些避免测试自动化中这些共性问题的实用方法。他以一些比较典型的自动化代码做引子，推演出一些有利于增强代码健壮性、降低维护成本的方法。
改善分布式回顾会议
许多人认为回顾是敏捷团队持续改进的最有效工具之一。回顾会议在人们印象依然深刻的时候总结教训、统一认识，而这些经验教训又会被立即应用到团队正在进行的工作之中。Yahoo Respectives小组上的讨论研究了如何帮助分布式团队在多个地点之间召开回顾会议。
Pomodoro－敏捷方式的时间管理
一项名为“Pomodoro技术”的个人时间管理方法正日益受到敏捷从业者的欢迎。Pomodoro包含了很多与敏捷团队采用的实践相近似的做法：时间盒、频繁检查和调整、预估、对低技术含量工具的偏好，以及对保持可持续节奏的强调。
PMI在敏捷2009大会上启动敏捷实践社区
项目管理学会（Project Management Institute，简写PMI）在敏捷2009大会上正式启动了敏捷实践社区。这个团体的任务是：“用敏捷技巧和知识装备PMI成员”。Mike Griffiths因为极大地推动了这件事而受到赞誉，他曾在Agile2007大会上提议PMI成立一个特定于敏捷的兴趣组。
“敏捷状态”调查开始
第四年度“敏捷状态”调查开始接受公众的参与。调查问卷一共为6页，5－10分钟内即可完成，采取匿名调查方式。经过过去3年的发展，正如调查结果所揭示的一样，由VersionOne发起的这项调查已经衡量出敏捷实践实施的广泛性。
调试失败Selenium测试的技巧
作为有效的浏览器测试自动化的工具，Selenium已经赢得了广泛的认可，但追查测试失败的原因仍要花上不菲的时间。Daniel Wellman分享了他的两个最佳技巧，可以极大降低调试失败的Selenium测试的时间。
衡量敏捷度、工艺以及成功
正当 Scott Ambler、Ross Pettit 以及其他人继续致力于创建敏捷成熟度模型，David Starr 查看了组织如何，以及为什么会希望衡量以下事项：敏捷度、工艺和组织的成功。他发现工艺相对容易衡量，而敏捷度则最难以有益的方式衡量。
出色的速度
Buddha Buck最近向Extreme Programming讨论组提出这样一个问题：对于由7个人构成、迭代持续两周的团队，速度处于什么范围才算是“出色”呢？在他看来，少于或等于8点的速度就表示团队的故事可能太大了。由此引发的讨论提供了一些答案，还揭示出问题背后的问题。