
如何处理遗留代码
构建(Build),自动化(Automate),测试(Test),这个BAT可以帮助你建立一张防护网,确保代码可以如你所愿的继续工作。 Richardson向我们展示了这些步骤如何迅速发现并解决那些没有意识到的副作用。看看它与你日常工作相比的区别是什么,你是否需要用不同的手段处理工作。

构建(Build),自动化(Automate),测试(Test),这个BAT可以帮助你建立一张防护网,确保代码可以如你所愿的继续工作。 Richardson向我们展示了这些步骤如何迅速发现并解决那些没有意识到的副作用。看看它与你日常工作相比的区别是什么,你是否需要用不同的手段处理工作。
很多人同意:即使是最小化的敏捷实践集合也会包括严格的版本控制。尤其是当多个开发团队在同一个代码库中进行开发时,要想保证在每个迭代结束都能有一个干净、可发布的版本,他们需要预先进行规划。Henrik Kniberg提出的版本控制管理计划已被大家认可,对团队也很有帮助。本文包括了全部的具体实施方案,甚至还包括了一个工作清单。
Scrum将障碍定义为“任何阻碍团队提高生产效率的因素”,并明确强调团队应建立持续不断移除它们的办法。Joe Little提议:使用“障碍范围”这种定义,可以帮助组织更有效地向客户传递价值。
最近,关于下一代功能测试工具发展方向的讨论热闹地开了锅。不过,还是众多敏捷组织仍然在努力让传统的“录制-回放”测试工具跟上敏捷的脚步。被称为“测试狂人”的Elisabeth Hendrickson告诉他们为什么不要再白费功夫了。
微软最新的应用程序框架核心(Application Framework Core)团队开始在.NET核心框架中拥抱命名与激活服务(Naming and Activation Services)、依赖注入以及动态类型(Duck Typing)。
持续集成(Continuous Integration,CI)这项基本的XP实践现在已经变成了被广泛使用的开发者最佳实践之一。InfoQ为您提供了“持续集成:改善软件质量并降低风险”一书中的“第六章:持续测试”,在这一章中,作者提出了一些编写优秀测试以保证系统质量的建议和示例。

本着“信息辐射体”和“人人可见的大图表”的精神,Kenji Hiranabe提出用“看板图”来管理三个视角(时间、任务和团队),让整个团队都理解当前的项目状态,从而以自主、有动力且互相合作的态度来工作。

当敏捷团队徘徊在平庸的“照本宣科”阶段,有时候团队合作没法继续前进到令人兴奋的“大放光彩”的阶段,反而让团队表现受困于看不见的“学习瓶颈”。敏捷实践要求我们花时间去反省和学习——学得快的团队才会成为赢家。

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