既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
文章目录
12.软件需求最佳实践笔记 | 需求基线
一、需求基线的理念与策略
《软件需求》(KarlE.Wiegers) 定义：团队成员已经承诺将在某一特定产品版本中实现的功能性和非功能性需求的一组集合；
RUP定义：逐项列举的在应用程序的某个特定版本中提交的特征和需求的集合；
特定版本：在整个软件的开发过程中将出现多个不同的版本，这也意味着将采用分阶段或迭代开发模式。
一组需求集合：是需求的一个子集，可以理解为纳入基线的需求是将投入开发的需求，而其他的则是已提出但还没有接受或没有着手开发的需求。
注：在项目中引入需求基线之后，通常也就意味着抛弃了“瀑布模型”的软件开发生命周期，而采用了分阶段或迭代的开发模式。
- 基线思想的起源
迭代开发方法催生了基线的思想，基线实际上就是为每次迭代(或阶段）的开发工作定义的任务集（也就是需求集）。
下面是迭代和分阶段开发的区别：
- 基线的策略
①以业务驱动作为基线划分标准
子系统是未知的，但业务主题域却是已知的；
功能模块是难确定的，但业务流程、管理控制点却是能够标识的；
功能子模块是变化莫测的，但业务活动（用例、场景）却是可以发现的；
不管是子系统、功能模块、功能子模块都需要在需求后期（甚至开发后期）判断是否完整，而业务主题域、业务流程、业务活动却是在需求中期（框架与脉络完成时）就能判断。
②“需求分析与建一阶段”完成时，开始划定基线（SERU）
将所有的需求项以树型结构整理出来，然后针对各个需求项进行优先级评价、工作量评估，最后在此基础上完成基线的划定 。
二、基线划定的基础：优先级评价
- 组织需求项
以的“体检医院管理系统”为例，说明优先级评价、工作量估算、基线确定的方法与过程。首先当然是组织需求项。
在进行优先级评价之前，首先将所有的需求项组织成一个树型结构（WBS结构），然后按以下步骤进行优先级判断。
业务优先级判断：根据业务结构特点，对所有需求项划分等级。
技术依赖性、项目风险判断：从技术实现、项目风险两个角度调整优先级。
工作分解结构（Work Breakdown Structure，简称WBS）跟因数分解是一个原理，就是把一个项目，按一定的原则分解，项目分解成任务，任务再分解成一项项工作，再把一项项工作分配到每个人的日常活动中，直到分解不下去为止。
项目管理软件WBS分解示意图
下表为完成的需求项：
- 业务优先级评价
接下来，就可以在上表的基础上进行业务优先级的评价，通常应该对每个主题域逐一评价，跨主题域之间的比较是没有太大意义的。可以直接比较不同主题域之间的优先级，假设客户认为“客服管理子系统”可以稍后上线，那么就可以将整个主题域降1级，也就是将该主题域中所有用例的优先级下降1级(或多级，根据实际需要）。
对于每个主题域，建议将所有的需求项划分为关键、重要、有用、一般4个等级(也可以增加一个镀金等级）。
①标识关键用例
业务事件和报表类型的重要性判断依据：
根据出现的频率，以及对企业带来的价值进行评价。对于这里的6个业务事件而言，“体检者申请体检”显然是最常出现的，而“财务提交团队缴费情况”是其必备的依赖事件（所有团队体检都会触发)，同时也依赖于接口“获取公司客户收费信息”，因此它们是关键的。
另外，在所有的报表项中，“体检业务周期统计报表”（其中后两种并不常见)、“当前体检业务情况”、“团队体检过程报表”是最基本、最常用的，因此是关键的。
对于“体检者申请体检”流程，只有“返回报告”相对而言不是必要的，很多医院实际上也没有对其进行管理，因此除了它之外其他都标识为关键用例。
②标识重要用例
③标识有用和一般用例
④功能点级的优先级评价
以上是用例级的优先级评价，有时还会需要对具体的功能点进行优先级评价，这时应该找到其相应的业务场景（用例），甚至是在业务流程中考虑。
如果直接进行比较很难得到客观的结果，但如果我们将其放到具体的业务场景就容易了：需求a发生在什么场景中呢？显然是“办理入住”；需求b发生在什么场景中呢？显然是“换房”。对于酒店而言办理入住和换房相比，显然前者的频率和价值都更大，因此需求a的优先级比需求b更高。
- 根据技术依赖性和项目风险调整优先级
按上述步骤完成业务优先级评价之后，将其发给技术团队、项目管理人员对其进行调整（没有先后顺序，只升级不降级）。
技术依赖性：对于本例而言，“管理体检项”和“管理体检套餐”属于基础工作，“体检者申请体检”中的所有用例都依赖于它，因此它们应该升级为“关键”用例。
项目风险：也就是项目经理觉得在技术上、管理上存在风险的需求项要提前开发，也就是提高它的优先级，对于本例而言没有需要调整的。
此外，要划定基线，除了必须对需求项的优先级进行评价之外，对工作量进行估算也是必不可少的要素。没有这项工作作为基础，迭代计划也就无从谈起。当确定所有需求项的优先级、对其工作量做了基本的估算后，就可以开始划定基线了，采用的是“早基线，晚冻结”的策略。
- 总结
借助基线的管理能够使开发过程更加有计划、有节奏。“良好、统一”的需求项划分标准是做好这一工作的基础，实现切实可行的优先级策略和估算方法是使基线管理卓有成效的必备要素。
13.软件需求最佳实践笔记 | 需求变更
一、变更管理的理念
需求变更频繁恐怕是困扰无数软件开发团队的恶魔之首，而且在美国权威的第三方机构StandishGroup的CHAOS报告中，也将其列为困扰软件开发团队、导致项目失败的5大原因之一，其中原因实际上也充分暴露了整个产业的不成熟。需求变更在CHAOS报告中是排名第四的问题，而在中国软件开发团队中却是排名第一的问题。
需求变更两种来源：
一是我们错了，捕获的信息不全面，分析的结果不正确等；二是世界变了，现代社会充满变化，业务流程、业务规则都是日新月异。因此应该尽可能避免犯错误，同时也要加强对变化的预测，但是需求变更是无法避免的。
注：需求变更管理的目标是控制变更，而非避免变更。控制变更的目标是减少变更对开发工作的影响。
对变更进行有效控制，要抓好两个方面工作：
统一渠道：如果对变更没有集中处理，那么要想对其进行有效地控制显然是不可能的；业界针对这个问题开出的药方是“CCB(变更管理委员会）”。
统一平台：如果所有的变更没有有效地记录、分析，那么就很难对其建立科学、合理的认识；业界针对这个问题开出的药方是“变更管理系统”。
需求团队要“尽早标识变更”，设计团队要“尽可能以弹性的设计来减少变更的影响”。
二、变更管理要点一：统一渠道
之所以要统一渠道有两个两个方面原因：一是变更可能相互冲突：如果没有统一的规划与管理，程序员响应的变更可能相互冲突，导致新问题的产生。二是变更量无法引起重视：国内的许多客户通常是没有为变更付费的习惯，其实从某一个角度来看，对变更量没有直接感受是一个很重要的因素。
- CCB背后的道理
①正确认识CCB
CCB为需求变更创建统一的渠道，避免出现“多对多”的沟通。CCB核心思路将一个“多对多”的沟通路径转换成两个“一对多”的沟通路径。常设的人员就是两个，分别代表用户团队和开发团队。
②使CCB成为真正的统一渠道
- 变更处理过程
变更处理过程流程图
变更处理过程中要做影响分析，包括业务影响、技术影响、项目影响等。
①业务影响分析
首先，确定影响范围。
行为需求类变更：具体功能方面的需求，包括用户界面需求，可直接找到对应的需求项，可以归属于某个具体的业务活动中；也可以变成新增的用例，甚至是新增的业务事件。
数据、非功能、规则类变更：对于这类的变更则需要考虑它影响的范围，它可能只影响一个业务活动（用例），也可能影响一个业务事件。
确定需求变更的影响范围示例
其次，选择正确的评价者。
按上面的方法确定了变更的影响范围之后，选择正确的评价者，并将接受的需求变更通知到所有相关的人员。
选择正确的评价者示例
然后，对变更做出是否接受评价。
常见的评价角度包括：
对目标的贡献度：也就是对于系统的总体目标有没有直接贡献，如果有通常是肯定接受的。
对Stakeholder关注点的贡献度：也就是对于系统的Stakeholder的利益是否有直接的贡献。
对现有业务的影响程度：通常是对于规则类变更而言的，评估新的规则会对业务产生什么样的影响。
“变更分析：是否接受”示例
对于接受了的需求变更项，通常还需要确定优先级，通常将直接继承其影响的用例（业务活动），对于新增的用例则从业务价值和发生频率的角度综合评价。
“变更分析：优先级判断”示例
“变更分析：优先级判断”示例
②技术影响分析
对于修改型的变更：罗列出会影响哪些人工制品，包括数据库表、字段、界面窗体、控件，类、方法；在这个方面要想做得比较精确，就必须借助于“需求跟踪”，具体来说就是“需求项”与“人工制品”的跟踪。
对于新增型的变更：可以采用类比法进行，从已经实现的（也就是已有工作量记录的）功能中找一个与其相当的，以得出一个大致准确的工作量估计。
对于技术影响度的分析还有一个很重要的方面，那就是对原有架构、原有人工制品的影响，这个任务通常是由架构师完成的。通过这些评估之后，也会得出“是否接受”、“优先级如何”之类的决策。
③项目影响分析
完成业务影响分析和技术影响分析之后，通常还需要进行项目影响度的分析，具体来说，就是基于前面的工作量分析，考虑是否对整个项目的时间、进度、成本产生较大的影响，并在这个基础上做出最后的决策。
④是否打破基线
原则上不打破基线，也有几种常见的例外：
出现了影响生产的需求（通常是维护阶段），或者需求变更项的优先级比待开发的所有需求项的优先级都更高。打破基线通常采用置换法，也就是从基线中换回一个工作量相当的任务，将其放到下一次迭代中。
出现了对前面假设有巨大影响的需求：暂停迭代，重新考虑基线。
工作量比较小，重要性或与开发中的需求的关联性很强：加入基线。
三、变更管理要点二：统一平台
- 变更管理平台应用要点
对变更进行分类、再分类，是管理变更的重中之重。变更进行不断地分类，还能够帮助我们意识到“错在哪里”，“为什么错了”，以及“变化点在哪里？ “有什么规律”。
14.软件需求最佳实践笔记 | 需求跟踪
一、需求跟踪的基本概念
需求跟踪是将单个需求和其他系统元素之间的依赖关系和逻辑联系建立跟踪，这些元素包括各种类型的需求、业务规则、系统架构和其他设计组件、源代码模块、测试用例等。
需求跟踪涉及5种类型的跟踪链：从用户原始需求向前跟踪到软件需求，从软件需求向前跟踪到下游工作产品；从下游工作产品向后回溯到软件需求，从软件需求向后回溯到用户原始需求；以及软件需求到软件需求的跟踪。
需求跟踪的收益体现在以下六个方面：
审核：跟踪能力信息可帮助审核确保所有需求被应用。
变更影响分析：跟踪能力信息在增、删、改需求时可以确保不忽略每个受到影响的系统元素。
维护：可靠的跟踪能力信息使得维护时能够正确、完整地实施变更，从而提高生产率。
项目跟踪：认真记录跟踪能力数据，可以获得计划功能当前实现状态的记录。
再设计：可以列出传统系统中将要替换的功能，记录它们在新系统的需求和软件组件中的位置。
重复利用、减少风险、测试。
- 用户需求到软件需求的跟踪
这类跟踪的工作量规模中等，对于项目管理的好处很明显，建议有时间尽量实现此类跟踪。
目的：保证所有的用户原始需求都得到满足。
好处：1)开发人员在实现时能够精确地定位到相关的原始需求；2)可以为软件需求是否必要提供第一手的证据；3)容易找到需求之间的矛盾和歧义。
具体手段：将一句话表示的用户原始需求直接归并到软件需求的组织单元“用例”中。
- 软件需求到软件需求的跟踪
这类跟踪的工作量规模较小，对于需求管理的好处十分明显，此类跟踪是最应该建立的。
主要内容：包括1)项目目标、Stakeholder关注点到软件需求的跟踪；2)相关软件需求之间的跟踪。
目的：确保项目目标、Stakeholder关注点被实现。
好处：1)更好地理解软件需求的实现意义；2)更好地处理软件需求之间的逻辑相关性。
具体手段：为项目目标、Stakeholder关注点创建唯一编号，通过表格或链接法实现跟踪。
- 软件需求到下游工作产品的跟踪
软件需求到下游工作产品（系统架构和其他设计组件、源代码模块、测试用例以及帮助文件等）的跟踪，这类跟踪对于变更管理的好处十分明显，但工作量规模巨大，此类跟踪应该慎用。
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
lder关注点创建唯一编号，通过表格或链接法实现跟踪。
- 软件需求到下游工作产品的跟踪
软件需求到下游工作产品（系统架构和其他设计组件、源代码模块、测试用例以及帮助文件等）的跟踪，这类跟踪对于变更管理的好处十分明显，但工作量规模巨大，此类跟踪应该慎用。
[外链图片转存中…(img-dPCEpUfn-1715881475481)]
[外链图片转存中…(img-Dbtdxddn-1715881475482)]
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
扫一扫
6万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
