在上一个月中，自己阅读了《敏捷软件需求》的前两个大的章节，从整体上了解了团队、项目集以及项目组合层面的软件需求，了解了如何来处理不同的需求层面，最近半个月的时间详细的阅读了第三章节，这一节详细的讲述了团队敏捷需求，具体的介绍了全景图的团队层面。
首先是对“为什么要讨论团队”这一问题进行了相应的解答，敏捷团队是围绕需求进行组织的，以便优化代码的定义、构建与测试以及向终端用户交付价值的效率。敏捷团队的所有团队成员都参与到以下过程：定义需求、优化需求并设计权衡、实现需求、测试需求并把需求集成到新的基线，还要重视需求向客户的交付。这些就是敏捷团队的全部目标。
虽然有了相应的团队概念，但是我们并不是以这种方式组织的，而是被组织在一些特定的职能筒仓中，例如：开发人员和其他开发人员在一起工作交流，产品管理人员、业务分析师和项目集经理们各自在一起工作，并且他们经常向完全不同的部门报告。在较大机构中，架构师们工作在一起以便产生跨BU的公共架构，但是他们与开发团队几乎不熟悉或没有联系。产品负责人角色甚至可以不存在，或者是由产品经理承担这种职能。产品经理也是多路工作，有时候无法联络，使团队陷入冻结，只能被动等待回复。测试人员也许要向单独的QA机构报告或者与QA组织一起工作，而不是与开发团队一起工作。简单来说，就是一个团队的工作人员之间基本有很少的交流，只是单独的在完成自己所需要完成的任务，使得团队之间的沟通出现了问题，这就会导致在最后完成整体项目时出现过多的错误。
接下来涉及到的为用户故事和团队待办事项，敏捷团队的效能对组织的整体绩效至关重要，所以我们必须确保敏捷团队采取最简单、最精益的需求模型。为了建立精益、可伸缩的模型，我们必须确保团队的需求工件对于支持干系人的所有需要来说是最简单的，尤其要对团队成员的需要反应灵敏。而且，我们介绍的工件子集必须遵循敏捷方式，使它们与大多数敏捷培训和常见做法一致。而团队待办事项是团队唯一的正式工作来源，它记录了需要完成的所有工作（主要是用户故事）。它存在于团队本地，并由团队负责管理，是团队所有已识别工作项的储藏室，企业其他部门通常不关心其内容。团队负责管理它，为它提供必要配备，并根据需要处理其内容，使它适于支持团队完成迭代目标。如果在其中有“某件事情要做”，那么这件事就可能发生；如果其中没有某件事，它就不会发生。
最终讲解的是验收测试和单元测试，来检验项目的相应质量和功能，是否都能够满足用户的需求，质量是内建的，故事被逐一完成，通过对积累的功能测试和单元测试用例进行连续、自动化执行，实现持续的质量保证。
体会：经过这一章节的学习，自己识别了一种组织单元，即：敏捷团队。它消除了职能筒仓，其唯一目的在于优化对新功能的定义、构建和测试。除此之外，还了解了一组需求工件和它们之间的关系，其中包括用户故事。用户故事作为一种优选方法，用于向软件基线快速交付有价值需求并准备对客户的发布。还熟悉了敏捷团队如何通过完整的功能和单元测试以及测试自动化，实现最佳质量。
敏捷团队层面的需求工件与关系。