2021年下学期阅读笔记之敏捷软件需求

      《敏捷软件需求：团队、项目群与企业级的精益需求实践》全面介绍了如何在敏捷环境中管理软件需求，全书共四部分24章。第I部分提出企业的敏捷需求全景图，针对项目团队、项目集和项目组合这三个级别，描述了一个整体的敏捷需求过程模型。第II部分描述一个简单的、轻量级的但同时又宽泛的模型，敏捷项目团队可以使用这个模型来管理需求。第III部分展示如何为需要多团队合作的复杂项目确定敏捷需求。第IV部分指导企业如何为大型的“专用系统”、应用套件和产品项目组合制定敏捷需求。《敏捷软件需求：团队、项目群与企业级的精益需求实践》适合软件开发人员、测试人员、执行主管，项目/项目集经理、架构师和团队领导阅读和参考，可以帮助他们在敏捷转型过程中去除障碍，打造出优秀的软件产品。
       原来我以为软件需求很简单，只是我们在做软件之前搞清楚用户对于我们即将所做软件的希望，然后从中分析出我们的软件的功能等一些东西。但是打开这本书，我发现原来敏捷需求的知识点很多。这本书总共分为四个部分：概括（全景图），团队的敏捷需求，项目集的敏捷需求，项目组敏捷需求。

     在“瀑布式”过程模型应用而生之后，后来发现了瀑布式模型给开发来了困难。“铁三角”陷阱是指在“已知”需求之后，便可以估算成本和进度。“瀑布式”过程模型有时带来困难是因为“完整定义需求之后经过较长时间才交付这些需求，这种方式已经不再合乎事宜。业务需求的频繁变更表明，需求一旦形成文档就不会有重大变动”，所以才产生了敏捷需求。在“瀑布式”过程开发之后又出现了迭代式过程。快速应用开发（RAD)是指在需求变更之前尽快完成构建。如果判断有误，则可以通过一些廉价的轻量级工具，以更快的速度重构。统一软件过程（RUP)认为各种活动有必要在生命周期各阶段（导入，细化，构建，移交）交叉进行。

    后来产生了众多的敏捷方法，目前采用最广泛的是Scrum和XP。极限编程（XP)是指它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。Scrum是指在每一次冲刺（一个15到30 天周期 ，长度由开发团队决定），开发团队创建可用的（可以随时推出）软件的一个增量。

    通过前面几小节的学习，我了解了以前的几种开发模型以及他们的特点和敏捷需求。学习到不仅开发之前需要做需求调查，在开发过程中应该经常做需求变化的调查，来使我们可以交付给用户更好的产品。