不同技术团队的配合问题及DevOps
在IT企业里产品从创意到交付给用户，从整体上看是由技术部门负责，但如果深入到技术部门，会发现由不同的技术团队负责不同的部分或者阶段。本文讲述了不同技术团队的配合问题及DevOps。
InfoQ
InfoQ
促进软件开发领域知识与创新的传播
主题/标签专用视图
计划相关的内容
最新“计划”相关专题内容
“计划”相关新闻
敏捷团队应对打扰的七种方法
每个团队都必然会遇到工作被干扰的情况，如果不能合理应对，那么很可能会影响到团队的交付能力。最近，在Agile Advice网站上，Mishkin Berteig发表了一篇文章，讲述了当Scrum或者其他一些采用迭代方式的敏捷团队遇到工作被干扰的情况时，可能可以采用的七种应对方法。
我们需要第0个迭代吗？
在一个项目启动之前，通常需要完成一些准备工作。为了能够保证后面一系列的迭代顺利进行，团队往往会安排“第0个迭代”('Iteration Zero')，把所有需要的系统都准备好。这是一个好的方法吗？
用户故事点数的依据是复杂度还是时间？
很多敏捷团队将故事点和复杂度点作为同义词来使用，他们相信这比使用“小时”更好，因为这些点数是基于复杂度和相对大小的。Mike Cohn则表示，使用故事点来描述特性的开发复杂度是不对的，应该使用工作量。
“计划”相关文章
敏捷项目的多层面规划
“响应变化重于遵循计划”，这是敏捷的核心价值观之一，可是它有时会被人错误诠释为敏捷项目中不需要规划，然而，真实情况根本并非如此。在真正的敏捷组织和项目规划中，常常要在多个层面展开规划活动。Shane Hastie讨论了规划的不同类型和方式，以及如何协同使用这些方法。
当敏捷团队遇上固定价格合同
固定价格合同很有害，这是敏捷实践者经常说的。从另一个角度来说，这些合同是很多敏捷团队必须面对的现实。但是，如果我们试着去驯服它而不是去反对它，那结果又会如何？一个公司如何用敏捷实践执行这种合同来达到更佳效果和更低风险？这篇文章试图回答这些问题。
配置管理的五项最佳实践
最近有很多关于应用程序的配置以及如何对其进行管理的讨论。 本文探究了人们可以在代码中做些什么，使得他们以及所有需要管理和维护应用程序的人的工作变得更简单。 这些模式已经在ThoughtWorks的项目中被多次应用，从而验证了它们的价值。
“计划”相关技术访谈
Johanna Rothman : 降低传统团队在敏捷旅程中的风险
管理顾问Johanna Rothman帮助她的客户管理风险：包括项目中人员的风险，人员管理方式的风险，或是项目自身的风险。在这次采访中，她谈论了包含在她的新书《Manage It! Your Guide to Modern Pragmatic Project Management》中，对于处于不同敏捷度时期的所有团队都有效的降低风险的策略。