2021年下学期阅读笔记之敏捷软件需求
《敏捷软件需求:团队、项目群与企业级的精益需求实践》全面介绍了如何在敏捷环境中管理软件需求,全书共四部分24章。第I部分提出企业的敏捷需求全景图,针对项目团队、项目集和项目组合这三个级别,描述了一个整体的敏捷需求过程模型。第II部分描述一个简单的、轻量级的但同时又宽泛的模型,敏捷项目团队可以使用这个模型来管理需求。第III部分展示如何为需要多团队合作的复杂项目确定敏捷需求。第IV部分指导企业如何为大型的“专用系统”、应用套件和产品项目组合制定敏捷需求。《敏捷软件需求:团队、项目群与企业级的精益需求实践》适合软件开发人员、测试人员、执行主管,项目/项目集经理、架构师和团队领导阅读和参考,可以帮助他们在敏捷转型过程中去除障碍,打造出优秀的软件产品。
原来我以为软件需求很简单,只是我们在做软件之前搞清楚用户对于我们即将所做软件的希望,然后从中分析出我们的软件的功能等一些东西。但是打开这本书,我发现原来敏捷需求的知识点很多。这本书总共分为四个部分:概括(全景图),团队的敏捷需求,项目集的敏捷需求,项目组敏捷需求。
在“瀑布式”过程模型应用而生之后,后来发现了瀑布式模型给开发来了困难。“铁三角”陷阱是指在“已知”需求之后,便可以估算成本和进度。“瀑布式”过程模型有时带来困难是因为“完整定义需求之后经过较长时间才交付这些需求,这种方式已经不再合乎事宜。业务需求的频繁变更表明,需求一旦形成文档就不会有重大变动”,所以才产生了敏捷需求。在“瀑布式”过程开发之后又出现了迭代式过程。快速应用开发(RAD)是指在需求变更之前尽快完成构建。如果判断有误,则可以通过一些廉价的轻量级工具,以更快的速度重构。统一软件过程(RUP)认为各种活动有必要在生命周期各阶段(导入,细化,构建,移交)交叉进行。
后来产生了众多的敏捷方法,目前采用最广泛的是Scrum和XP。极限编程(XP)是指它将复杂的开发过程分解为一个个相对比较简单的小周期;通过积极的交流、反馈以及其它一系列的方法,开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等,并根据实际情况及时地调整开发过程。Scrum是指在每一次冲刺(一个15到30 天周期 ,长度由开发团队决定),开发团队创建可用的(可以随时推出)软件的一个增量。
通过前面几小节的学习,我了解了以前的几种开发模型以及他们的特点和敏捷需求。学习到不仅开发之前需要做需求调查,在开发过程中应该经常做需求变化的调查,来使我们可以交付给用户更好的产品。