最近一段时间阅读了《敏捷软件需求》这本书的第二章节，该章节讲述的是全景图：团队层面、项目集层面、项目组合层面的知识
全景图中团队层面的敏捷需求
全景图中项目集层面的敏捷需求
全景图中项目组合层面的敏捷需求
从这一章节中，了解了很多重要的知识点：
1、在敏捷方式中，团队是实体，他们负责编写和测试所有代码，这些代码会向终端用户交付价值。由于是敏捷团队，所以每个团队最多只有七到九名成员，他们身兼定义/构建/测试软件特性或组件所需要的所有角色。这些角色包括Scrum Master、产品负责人、几名专属的开发/测试人员以及（理想情况下）自动化测试专家，可能还有一名技术领导。每一个团队都有自己的必要成员，根据不同的任务，团队中所需要的人员也会有相应的不同；
2、在敏捷开发中，新功能是通过一些短期的活动构建的（称为“迭代”，在Scrum称为“Sprint”）。大型企业的敏捷团队通常采取统一的迭代长度和共同的迭代起始与结束边界，以便在每个迭代边界的系统集成点比较各个团队的代码成熟度。每一次的迭代，都代表着一个有价值的新功能的增量，对增量的实现采取的是一种连续、重复的标准模式。
3、在全景图顶部是项目组合管理职能，在这一层面包括致力于根据企业商业战略管理投资的个人、团队和组织。还有两种新的工件，即投资主题和篇章，它们结合起来形成项目组合愿景。在项目组合管理中，又额外的增加了两种的新的工作，一组投资主题可以为企业或BU建立起相关投资目标，篇章代表对客户需求的概要表达，它们是为交付投资主题价值而提出的一些开发倡议。
4、通过构建一定规模的架构跑道（借指在不需要过分重构的情况下实现新特性的能力），可以帮助企业最终在市场中胜出。所以，只要想从真正意义上讨论敏捷需求管理，必然会涉及架构的话题。
体会：在这一章节的学习中，自己了解和熟悉了全景图，将其用作基本的需求工件、过程和组织模型，已精益和敏捷的来管理软件需求。对于敏捷团队来说，这个模型使用最少的工件、角色和实践以满足团队的高速率需求。而且，这个模型可以根据需要扩展到项目集和项目组合层面，在这种情况下，即使是管理由多团队组合（teams of teams）构建的大型专用系统（systems of systems），也可以为管理软件需求提供最精益的方式。