2年前，我们面临的情况是，200多研发人员，3条产品线，7个产品：产品BUG多，稳定周期相当长，正式发布的产品的稳定周期平均需2~3个月，长的甚至有一年；需求变化快，产品发布后，马上面临修改；答应客户和市场的时间一推再推（跳票）；导致研发能力无法支撑公司去把握新的市场机会；开发过程压力大且心情悲壮，研发部和产品部互不理解，冲突多。我们打算用敏捷的思路来优化公司的研发管理，希望配合技术进步等手段扭转公司产品的产能，支持公司的高速发展；从此我们就走上了变革之路，面对整个公司的研发管理优化，我们经历了许多挫折和变化，2年下来有了一些阶段性收获，在此将如何在企业中推进和实施敏捷的一些经验和教训与大家共同分享。
固定价格合同很有害，这是敏捷实践者经常说的。从另一个角度来说，这些合同是很多敏捷团队必须面对的现实。但是，如果我们试着去驯服它而不是去反对它，那结果又会如何？一个公司如何用敏捷实践执行这种合同来达到更佳效果和更低风险？这篇文章试图回答这些问题。
在Agile中，Story point和Working hours都是用于评估完成每个Story所要付出劳动，只不过前者使用相对尺寸来估计，后者则使用绝对时间。那么，在实际工作中，Story point和Working hours是否需要联系到一起？AgileChina讨论组中的讨论结果表明，多数人倾向于由团队自己做决定。
几乎在任何新兴的敏捷项目中，“业务价值”都成为了继“敏捷”自身之后的又一个重磅词汇。但是在这些项目的参与者中，又有多少人能够很好地理解了他们挂在嘴边的“业务价值”的真正含义呢？Joe Little发表了他对这个备受关注的问题的看法。
TargetProcess 的计划和跟踪工具更新的非常快。从 2.0 版本发布后，他们增加了绑定到用户故事（User Stories）和测试计划的测试用例，方便源代码需求和缺陷可见性的 SubVersion 集成，人力配置管理和一个公共的 Web 服务 API，使得 2.3 版本成为适于规模较大的敏捷公司的一个更有吸引力的解决方案。
