软件需求阅读笔记二

今天我学习了第二章《敏捷需求全景图》，全景图共分为四个层面：团队层面，项目集层面和项目组合层面。在敏捷团队中最多只有七到九名成员，他们身兼定义定义/构建/测试软件特性或组件所需要的所有角色，这些角色包括Scrum Master、产品负责人、几名专属的开发/测试人员以及自动化测试专家，可能还会有一名技术领导。如果这其中有人隶属于其他部门，并且他被指派给敏捷团队，但是敏捷团队自己负责其工件，这一职责不能被委派（或取消)给内部或外部的其他部门。组建团队的目的是交付软件的特性或组件。大多数企业都有两种团队：组件团队和特性团队。组件团队关注于共享基础设施、子系统、持久化、面向服务架构的组件；特性团队则关注垂直的、面向用户的一些价值交流主题。在一些企业中有一定的数量级的敏捷团队，这些团队在一起协作构建某个更大的特性、系统或子系统，被称为“项目集”。

   在敏捷团队中各个角色各司其职。产品负责人负责确定用户需求，排列需求优先级并负责维护产品待办事项。Scrum Master代表的是团队的管理或领导人，其作用是帮助团队转型到新的方式，持续提高团队的活力，从而充分发挥团队的效能。开发和测试人员完成代码的编写和测试。在敏捷开发中每个迭代都代表一个有价值的新功能，对增量的实现采取的是一种连续、重复的标准模式，即：计划迭代、构建和测试故事，向干系人展示新功能、检查与调整。

   “用户故事”是价值流中承载客户需求的基本工件-从需求分析到编程实现。用户故事一般写成--作为一名<角色>，我可以<活动>，使得<业务价值>。团队代办事项包括团队针对项目实现所识别出来的所有用户故事。

      在原来的团队编程中我们团队是一起商量出软件的需求，然后由需求得到软件的功能。然后把功能分成任务，然后每个人领到任务去完成。到最后时再由两人完成测试。并却软件的功能得到后就算确定下来不再改变。在今后的团队编程中，我们应该不断的进行软件需求分析得到新的功能，这样不断的完善我们的软件，使得我们的软件交付到用户的手中时，软件依旧“不过时”。