曾经有一个这样的项目
业务人员：提出指标需求，业务口径
开发人员：按需求与口径，编写SQL加工数据
开发人员把SQL语句或者指标间的运算表达式，以及依赖关系填入EXCEL模板，每一行作为一个作业。最后EXCEL中的数据被导入到数据库，供通用跑数脚本读取，并按照一定的逻辑，批量加工。
最近刚好有需要评估类似项目的自研可能性，便决定好好思考一下这个项目，并试着自己来实现。
以下主要是通用跑批脚本的实现
主要程序功能点列表：
1、读取开发人员配置的作业模板，按照计算类别，生成完整的可执行SQL脚本并执行。（取个名字就叫“佛怒火莲”吧）
2、读取所有需要跑批的作业，拼装成执行命令，批量执行。（也取个名字，叫“肖火火”吧）
考虑到本机没有linux环境，但装了个Python 3.x，刚好本人大概好像也会一点，于是Python版的“肖火火”与“佛怒火莲” 便被巧妙地安排上了。
客观约束条件是资源可用性差（大龄且coding稀烂）不能100%的精力投入到本项目；没有很详细的需求，需要在开发中完善功能点。于是，一个人的山寨Scrum便开始了。
Sprint1
Timebox：1周
Backlog: [完成“佛怒火莲”编码，完成“肖火火1.0”版本编码实现串行批量加工]
Daily Scrum: 将指标间的运算表达式解析成可执行的完整SQL语句，这个功能点不知道咋整 【2022-07-12】
Sprint Review:
1、指标间运算表达式解析完成
2、佛怒火莲
3、肖火火1.0
1.0版本中实现了，自动跑批的功能，但有个缺陷，当一个作业有多层依赖，例如作业A依赖B，C，作业B又依赖D，此时，如果D报错了，A会写入到重跑作业列表，但是中间的B作业还是会执行，并记录为“已完成”。显然这样是不对的，所以，在接下来的Sprint中，需要解决这个问题。
Sprint2
Timebox：1周
Backlog: [解决“肖火火1.0”版本中多重依赖下中间作业处理方式错误的缺陷，完成“肖火火2.0”版本编码实现并行批量加工]
Daily Scrum：多线程编程缺少并发量的控制，“肖火火2.0”会不断的扔“佛怒火莲”，没合适的方法解决 【2022-07-19】
为了解决Backlog[1] 中的缺陷，需要多出来一个程序，负责作业的执行（也起个名字，叫“青莲地心火”吧），这样子的话，如果一有作业报错，就直接 exit 1 ，那后续等待的作业B就不会被执行了。
那调整后的程序功能列表变成这样子：
1、“佛怒火莲” ：读取开发人员配置的作业模板，按照计算类别，生成完整的可执行SQL脚本并执行。
2、“青莲地心火” ：接收作业名，拼装成执行命令，并执行
3、肖火火：读取需执行的作业列表，批量并行执行
重新了解了一下Python多线程的一些知识，简单概括如下：
1、GIL（the Global Interpreter Lock）防止多线程并发执行
2、GIL是在实现Python解析器(CPython)时所引入的一个概念
3、CPython是大部分环境下默认的Python执行环境
所以，基本上多线程并不能实现并发（裂开。。。）
所以，要通过多进程来实现并发
调整后的Backlog: [“青莲地心火”开发，完成“肖火火3.0”版本编码实现并行批量加工]
Sprint Review:
1、“青莲地心火” 完成
2、“肖火火3.0”版本 完成
Let's run
Sprint Retrospective：
这是一个想法被实现的过程的简单记录
很多事情跟Srum很像，大都是渐进明细，越做才能越明白，这也许就是探索和尝试也值得我们花时间去做的一个原因吧
有个想法，可能是很简单的事情，但是如果能试着去实现它，好像就没有那么简单了，最后能实现并完善了它，这个事情应该就不简单了。
愿心之所想，能行之所致。
