最近一段时间以来，自己阅读的是项目集层面的软件需求，这一层面与团队层面相比，有很大的区别，而且在这一较高层面，企业实施敏捷方式会面临一些其他挑战。在这一层面包括如下目标：
1、 维护愿景和路线图：持续定义和交流项目集的愿景，维护路线图，使相关团队的工作具有公共目标。
2、管理发布：协调若干团队的活动，按照企业选定的开发节拍来建立增量发布。
3、质量管理：确保对团队积累的成果（系统）定期集成，并满足性能、安全性、可靠性需求和必须遵循的外部标准。
4、部署：团队可能没有能力、视野或权限向终端用户实际部署系统，这一关键活动必须在项目集层面管理。
5、资源管理：根据需要调整资源，处理约束瓶颈，使项目集能够及时交付所需的价值功能。
6、消除阻碍：项目集的主管和经理们还负责清除从团队反映的阻碍，这些阻碍超出了团队控制。
在项目集层面首先面对的一个基本问题是：如何对敏捷团队加以组织，以便优化需求价值交付。在项目集 层面中，又分为了两个团队，特性团队与组件团队。
采用组件团队这种方式，有些有点非常的明显，因为每支团队能够在他们的组件中汇集处理多个特性的要求，而且可以把注意力放在为相应层次构建最好的、长寿命的组件或服务。他们的组件不会被各种新特性“切片或切块”，相反这些组件可以演化为一组服务，并实现当前和（理想情况下）未来的特性。采取这种方式组织的团队，在构建大型软件系统时，可能反映出以架构为中心的偏见。如果对架构的设计不合理适当，这种方式将不能实现可靠性、性能和企业长期的特性速率的交付目标。
而特性团队也有其突出的优点，团队可以形成对实际领域和系统使用方式的专业知识，而且通常可以加速特性的价值交付。这种方式的开销更少，因为在对特性的实现中，多支团队不必来回传递待办事项条目。而且在团队之间的相互依赖会少很多，计划工作与执行也更简练。
组件团队的技能是在某一技术领域中，特性团队的核心技能则对应于某个特性（或特性集）。团队的待办事项被简化了，在任何时刻只有一到两个特性，这样必然可以促进高增值特性的快速交付。
之后文章中又提到了其他的团队，有系统团队，包括系统级测试、系统质量保障、系统级的持续集成、构建开发基础设施；发布管理团队以及产品管理；最后一部分讲述了愿景（处理一些较大的问题），含有愿景文档、起草新闻稿、初步数据表和待办事项、愿景简报。除了愿景之外，还有非功能需求和敏捷发布火车、路线图，每一节都包含了相应的内容。
体会：第四章节介绍了在涉及多支团队的项目集中，采取敏捷方式所需的新的需求角色、工件和过程，介绍了如何组织团队以便优化价值交付，介绍了一系列新的需求工件——愿景、特性、非功能需求和路线图，还介绍了团队如何使用这些工件针对他们开发产品、系统或应用等较大目标进行交流。我们还介绍了团队如何积累一系列迭代，并通过敏捷发布火车构建潜在可交付增量或是发布增量，逐渐向用户和客户交付价值。