介绍一下我的背景，
纯建筑系学生本科+硕士（抗战）8年，两年建筑师工作经验，现居柏林。
因为疫情我不幸失业，且至今还在在求职路上。
但好在这里，如果你已工作一年且交满了一年的养老保险非主动辞职的情况下，可以领取半年的失业金，并且劳动局可以提供职业培训及就业指导。
于是在搜集各种信息，思考探索，和朋友交流讨论了一段时间后，我向劳动局申请了为期两个月的Agile Projectmanagement（敏捷项目管理）的培训课程。
课程中Scrum master 的部分引发了我的思考，甚至改变了我在建筑学习道路上建立和培养的一些思维定式。
其实敏捷项目管理，agile，scrum，kanban这些框架/方法/理论在互联网、咨询、广告、金融等行业早就渗透工作日常了，但是在传统的建筑行业还没有被广泛地传播运用。
1. 那么，什么是「敏捷」？
这要从「敏捷宣言」说起，在2001年，美国犹他州，17个软件开发工程师聚在一起讨论当时软件开发项目运作的种种不满，直到达成了敏捷开发的共识：只有当用户、提供者、开发工程师共同向目标行进，才能实现用户在高复杂度条件下的利益最大化。
这「敏捷宣言」像不像1919年格罗皮乌斯起草「包豪斯宣言」，一群建筑师（developer）决定变革行业现状，take over。
「敏捷」是一套由软件开发发展而来，应对复杂（变化多端的甲方）情况，一种持续学习，持续增量的迭代模型。
「敏捷框架」则是基于敏捷模型的项目管理范式。
Scrum是运用较为广泛的框架之一。
如同其他项目管理理论一样，Scrum框架也包含了项目团队组成、成员职责、项目运行阶段划分、项目管理文件等内容，但Scrum最核心也是最让我受启发的有两点：
1. 尊重「人」。它推崇的价值观：专注，公开，承诺，勇气，尊重。
2. 持续迭代。产品（服务）以阶段迭代，最小可运行产品的方式交付。
不同于传统的项目管理，确定目标后制定完整详细的计划，过程中遇到变化时需要层层汇报获得允许后再层层传递下去，「Scrum框架」主张团队「自治」，每个成员有自己的工作内容和职责，曾经Project manager的工作和权利消解到团队中每个人身上。
项目的目标被拆分成阶段目标，在最长不超过1个月的阶段里，交付阶段完成的可运行的成果，很好地应对了项目目标变化，敏捷应对的情况。
2. 传统方式 vs 敏捷方式
由此让我联想到个人的计划行动上：
比如写作这个计划。
我思考了很久到底写什么主题，什么样的内容才能保持持续写作的习惯呢？
是写我自己感兴趣的内容，擅长的内容，还是专业学习过的内容？
要写成什么样的风格呢，幽默还是严谨？
排版呢？好歹也是建筑师，怎么着也得好看。
就这样，我连公众号的名字都换了好几回了，直到看到提示说每个月有限定次数修改名称。
我的一篇文章，按照我“宏大的目标”希望可以唤起建筑师共鸣，在我间断了无数次后，停留在1500字，依旧没有完成。
我还有一个小红书账号，恰巧实践了另一种方式：没有“宏大的目标和计划”地开始，并且一直在改变“目标和计划”。
没想方向就开始拍摄一些生活中新的体验，不定时更新，两年左右的时间“玩”和探索，终于最近慢慢找到了方向，分享我在柏林的art & living，采访生活在我身边的艺术家，策展人。
这个方向既不是我学的建筑专业，也不是我一开始在小红书上创作时设想的方向。
教德语，食谱，荐书，都试了试，中间有几篇反响还不错，但都没觉得是可以继续的方向，
现在的follower数量1.2k，也不算什么成就，倒是对我一直探索的一点点肯定。
这些肯定又鼓励我去研究平台的运作机制，学习如何能通过平台使我的创作有更大的影响力。
3. 「敏捷」的push
生活中新的认知和行动是慢慢互相影响的。
「敏捷」不强调速度，而是鼓励小步出发，持续迭代。
这改变了我以往在设计方案或者制作模型时总是着急想要一下呈现结果的思维方式。
写作计划我也打算践行这种方式了，没有一开始就完美的计划，计划可以阶段调整，但行动的一小步在于一个简单的念头。其实我在写这篇文章时，依旧带着很多疑问，不确定，不满意，但唯一可以确定的是，我正在走这一小步。
只有走了这一步，你才有这积累的一步，才有下一步迭代的基础。
不用信誓旦旦地立下flag（来卷啊），也不是试试看的玩水心态（躺平啊），而是踏实地站在地面上，走起来。
Ciao.
图片来源：
- 封面 Richard Montgomery
- 传统方式 vs 敏捷方式
