当代中式软件开发现状之我见-这就是敏捷？
历史的车轮滚滚向前，当代互联网也早已过了而立之年。
各种优秀的理念，各种优秀的实践，提出，兴起，推广，衰落。你方唱罢我登场。
而这其中，最为人津津乐道的当属–敏捷开发。
唠一唠敏捷
2001年，当时软件领域的多位大佬在一起开了个会，大家聊得很开心，各种理念碰撞交汇，意趣相投，相见恨晚。
于是这几位好朋友在一起把讨论的结果总结为一份“敏捷宣言”。寥寥数语，包含4条价值观和12条原则，奠定了敏捷开发的基调。
12条原则
|
|
是的，我承认贴上宣言的内容是为了占篇幅的，你可以直接跳过，这样我的歉意也会少一些。
但是我仍旧想让你看一下它的四条价值观的内容。
4条价值观
|
|
寥寥数语，道出了敏捷的核心价值。
- 流程和工具固然重要，但作为工具而言他们的目的在于调动个体，提升成员间的互动；
- 文档详尽对加深理解和解释清楚问题而言的确意义非凡，但是能够交付可工作的软件才是更高目的；
- 开会，沟通，交流，是弄明白需求的重要步骤，这其中不免发生博弈，大概率会出现观点的交锋，刁难，疑问，甚至情绪化。但是不同角色间的合作更为重要，围绕着解决问题本身触发的交流才是更为有价值的交流，而这种善意的交流也体现了团队价值和尊重；
- 只要有需求，先聊排期，先列计划。这是避免犯错、把控节奏的有效措施，但是变化会导致计划调整，变化会使得计划失效，拥抱变化不仅仅是裁员时候才反复强调的口号，更应当在平时的工作中体现出来，它不是一种“恐吓”，它应该是一种人文关怀。
那么中式敏捷团队的特点是什么？
中式软件开发团队，尤其是互联网开发团队，喜欢吸收年轻血液，乐于引入先进的经验和实践。这是好事。
于是我们看到，看板用起来了，泳道列出来了，迭代跑起来了，站会也开起来了。
工作开始，第一件事，每日站会，大家机械式的发言，我今天要做ABCD这几件事，如果精力足够，我将继续做EFGH这几件事；
进入工作状态，又一个需求过来了，哦，天哪，这是啥，没听过啊。看看多会儿要，wow，产品说要倒排，明天就评审，今天就得给排期。
只能硬着头皮用经验去估计了，没办法，咱也没参与需求讨论，咱也没参与预评审，但是我们是一个敏捷的团队。敏捷的团队从来都是扁平化的，每个人都是资源池中的一个可自由调度的资源，轮到你做就得你做，当仁不让。
一天时间了解下需求背景，产品说发布时间是两周后，那就是说还有10个人日的时间，开发3天，单侧1.5天，联调1天，测试3天，预发1.5天。
先这么排吧，你问为啥单测要1.5天？我只能说这叫经验。
我们采用了业界领先的TDD模式，要编写完善的测试用例，指令覆盖率要达到90%以上，分支覆盖率要达到70%以上。
这都是套话，实际上是因为你不得不写这么多用例，否则代码提交都提交不上去，流水线直接卡住你。到时候耽误了代码合并，影响提测，就等着复盘吧。
关于复盘，也是一个有意思的事情，我们下一篇文章再说。
吭哧吭哧写了一通设计文档，编码，单测写了一通，又自然地迎来了敏捷开发团队的每日必修课：晚会站会。
此时，看板出场了。
看板里，井井有条地罗列着A B C D E … 等一堆事项，每个事项下又有着1 2 3 4 5…个任务。每个开发像勤劳的蚂蚁一样，将任务从一个泳道，搬到了另一个泳道，并战战兢兢地在任务进度上了小心翼翼地增加了若干百分比。
会议上，所有参与者挨个介绍着自己所负责任务的进度，嗯，一片和谐。
看啊，多么精干的敏捷团队，多么高效的工作方式。
听啊，这件事情和我有多少关系？这个百分比有多少可信度？
哎呀，又有一个会要参加了
得嘞，饭点儿快到了。
我们不禁提问，这样的节奏是敏捷的么？这样的team是敏捷的么？
相信你自有答案在心中。
用了看板/jira/站会就是敏捷了？
这里其实是一个哲学问题，神与形的边界在哪里。
哲学里有一个“忒休斯之船”的概念，说的是有一艘叫做“忒休斯”的木船，工人们每天更换一个船上的零件，日复一日，直到有一日，船上最后一个零件被更换掉了。
那么问题是，此时这艘船，还是忒休斯吗？
我们说，在水手的心中，它还是忒休斯。
人有其魂，船有其神。
这艘的信念和意志不灭，于是在水手的心中，忒休斯永存。
将目光收回，我们问，是否用了看板/jira/站会，乃至所谓TDD，就是在实践敏捷开发了？
明确回答，不是。
敏捷宣言的价值观中，有这样一条
个体和互动高于流程和工具
如果仅仅是引入了工具链，即便再先进，投入的资源再多，也不过是流于表面。
真正的敏捷是要调用个体之间的互动，而这种互动必然是良性的，平等的，没有信息差的，友好共享的。
你知道我在说什么。
于是我们可以多聊几句，我们聊聊层级官僚制，或者说科层制。
科层制在人类发展中，被认为是最为理性的组织结构。
一个理想的科层制架构，命令从上往下，层层传达，职责层层系分，每一层的人都知道自己要干什么，井井有条。像是一个精密的仪器，永不出错。
这里我只说几句，毕竟这个话题不能聊深。
我想说的是，在传统的zz领域和传统实体行业，科层制尚存在低效、长臂管辖、信息丢失等现象，试问在讲究效率与变化的互联网/IT行业，它就能保证不出查错，高效运转吗？
我想，没有人敢站出来，拍着胸脯说，你是错的，这是对的。
人是有思想的动物，信息越透明，人的思想越广阔。反之，信息差越多，越激发误解与不满情绪，而这种不透明，绝对多数是来自自上而下的，而这种自上而下往往会在基层集中体现。
我不谈什么皈依者狂热，那太绝对化，我只想表达一个观点，基层的公平性与信息的透明性应当如何体现？
聊回资源池。
所谓资源池，是指对于一个团队的成员而言，每个个体都是可调度的资源单位。
理想情况下，若团队中每个个体的认知水平相差不多，原则上，凡是涉及到该团队的需求和问题，任意调度团队中此时有时间投入新需求/新问题的个体，都能够cover。
资源池可以说是中式软件开发，在多年迭代与探索中，为了提高人力资源利用率而总结出的一套可行手段。
那么，保证这个模式能够健康良性运行的前提，便是消除信息差。
敏捷与信息差之间的矛盾是否可调和？
自然地，我们提出这样一个问题。
两者矛盾，是否可调和？
我们说可以，解决方式在于消除信息差。
有人可能要站出来反对了，你这意思是直接取消基层的调度管理节点吗？
兄弟，坐下说话，别激动。
那我们聊聊，基层调度节点的设立吧。
设立基层调度节点，无外乎因为人多了，一级管理节点精力有限，难以顾及方方面面，因此需要设立基层的调度节点来协调工作。
这没问题，这不正是经典的分治法么。
那问题在哪里？问题在于，将原本繁琐的事情进行某个维度的划分，再分担给基层调度节点，就万事大吉了么？
对于一级管理节点，的确减轻了压力，但是对于基层的资源池角色呢？
要知道，基层调度节点可是从资源池里选出来的，也就是说，在全局上，能够切实干活儿的实际资源池角色减少了。这是一方面。
另一方面，将新增的调度节点去作为对接任务的分发器，对于真正干活儿的资源池角色而言，何时介入需求，变成了该调度角色决定的事情。
何时介入，以及介入何种需求，都是黑盒子。
我们分开说。
何时介入有影响么
当然有，一个需求，或者说一个问题，前期沟通不是你，前期讨论你没参与。直接丧失了接触第一手资料的机会；这其中有多少信息丢失？
进一步，等你介入的时候，都已经到了切实的落地环节，怎么做已经有人帮你想好了，甚至可能连设计大纲都写出来了。
你要做的就是照着这个图纸，修房子。与戴着镣铐跳舞，何其相似。
对于解决一个具有一定规模的问题而言，这种基于他人的思路解决问题的方式，从根源上就限制作为一个独立个体的思考能力。
万事俱备，就差一个程序员了。
魔幻现实主义。
写代码，或者说，软件开发，是一种创造。如果你要创造，那就从头到尾都是你作为核心在创造，你的想法，你的设计，你的代码。一气呵成。
当然，对于复杂问题，多人参与也是应该的，但是至少这其中至少存在这么一个角色，他参与了整个问题的生命周期，我想这对于少犯错，提升健壮性，意义巨大。
为何要你的想法，你的设计，再变成我的代码？这其中要损失多少个脑细胞，换来多少句亲切的问候？不敢多想。
那，如何破局？
山人有补药和苦药两剂，且听山人道来。
补药，温顺，我们的目的是为了减少信息差，提高参与度与个体互动，那不妨在问题早期讨论阶段就让可能的参与者参与到讨论中，在这其中，挑选时间、精力、能力均能胜任的一人或多人参与后期的设计和编码。
你会发现，作为调度节点，每个问题上，都不再是单打独斗，总有人会和你一起分担来自问题/需求的压力；作为资源池中的角色，有想法，有一手知识，有你的设计，最后你将自己的想法和设计付诸落地，一件美事。
补药如此精妙，那苦药又如何？
既是苦药，怕不会太好下咽。从资源池中来，回资源池中去吧。
足下可否明示？
我是说，去TMD的调度节点吧。
调度节点，本质上还是资源池中的一员，选出来作为调度节点，是为了更好的协调复杂事项，做好问题的预调研，预分配。
但是实际上呢？好像，调度成了主要职责了，dispatch各种事项给资源池中的executor，在各个上下文中灵活切换，然后不时回调一下，看看进度如何，以便灵活组织语言进行汇总上报。
精彩，精彩，精彩。
作为调度节点，你可能委屈，“我的精力都被各种事项占满，再让我去负起资源池角色的责任，臣妾做不到啊”。
可以理解，但是请让事情的透明度更高一些，让executor们的参与度更高一些，停止你的所谓好心行为，你设计，你讨论，为什么要executor来买单？
你设计，你讨论，那就你来开发。毕竟，我们是一个敏捷团队，而这，是最敏捷的，最少上下文切换的。
除此之外，作为调度节点，别忘了自己的基类还是一个executor，本质上是executor implements Dispatcher，那么，请继续保持作为executor的公平性。
该值的班，该复的盘，请不要躲避，听我说谢谢你。
不患寡而患不均，这其中的利弊，我想作为资源池中的翘楚，调度节点比我更清楚。
如何更好的发挥资源池的优势，提升敏捷度？
资源池这种实践模式，确实被实践验证为能够切实解决问题，落地想法的模式，虽然存在不合理之处，但是不掩盖它的光芒。
那么基于资源池模式不改变的前提，如何发挥它的优势，更好服务于敏捷软件开发流程呢？
这里提供一个场景，供君品鉴。
产品同学有一个好的点子，想为系统添加一个新的产品线，该产品线能够带来日PV增加百分之5的效果。于是产品同学编写prd，并向需求池中投递需求，并期望支持的人力资源。
资源池中进行调度的开发同学，根据自己在甘特图上的排期及任务分配情况，对需求池中的需求进行主动拣选，并进行预排期。
一旦锁定了该任务，该同学便会成为该需求的owner，后续的讨论、设计、开发、测试均需要参与，并负责到上线。
有会必邀，邀必参与，自己想，自己参与沟通，自己落地，自己追结果，自己负责。出问题，自己复盘，问心无愧。
康威定律的启示
康威定律告诉我们，设计系统的架构受制于产生这些设计的组织的沟通结构。也就是说，产品必然是其（人员）组织沟通结构的缩影。
你的组织架构是什么样的，如如何运作的，基本上你的业务架构也是这么运作的。
业务架构，技术架构在迭代，组织架构也需要迭代，否则滞后冗赘的组织架构必然带来畸形抵消的业务架构、技术架构。
一个敏捷的团队，是自革新的，是自迭代的。
让前线的特种部队能够呼唤集团炮火。这是日渐销声匿迹的中台遗留下的一句经典。
你可以说中台是失败的，但是你不能否认这句话的积极意义。
与业务交互的团队，尤其是自诩敏捷的团队，一定是一个精悍的特种部队，扁平化，高效化，信息透明化，专家化。
如果这个团队把整个后勤部门都携带在身边，那么行军效率一定不会很高。
让后勤待在后勤的位置，让部队前出侦查。这才是现代化战争的作战形态。这也是康威定律给我的启示。
拥抱变化，不是自上而下的指示，而是推己及人的感悟，是整个团队所乐于拥抱的态度，是历史螺旋上升的坐标。
结语：敏捷之于个人又如何？
之于个人，敏捷的背后，也许是内卷。
关于内卷，我不想多聊，我不反对内卷，这是一种选择，它也许是一种无奈，也许是一种随波逐流，也许是发自内心的自我鞭策。
都无所谓，只要是自己的想法，自己的选择，内卷或者躺平，无关风月。
纷繁的会议里，你知道哪个是重要的；琐碎的事务中，你知道优先级是如何排列的。
并行的需求中，你能够把握结果走向；复杂的问题里，你知道问题就在那里，答案就在那里。
你知道，你有一群好队友，你知道，你有一个好team。
你知道，你有一颗清醒、独立的内心；你知道，你知道。
你知道，你不知道。
心存敬畏，踏实向前，不迎合所谓的文化，不沉溺于所谓的氛围，不抱怨所谓的现状，不停止思考的大脑。
敏捷，发乎于内心，行乎于个人，成乎于群体。
中式软件开发的现状，已经是世俗化的，利益导向化的，实用主义化的。对于敏捷团队而言，始终是服务于业务增长的，要深知，当代中式互联网软件开发，几无技术驱动型，放眼望去，皆为业务驱动型。
那么想明白这个道理，再去实践，就会少一些压力，多一些豁达。
不妥协，不偏激，不随波，不逐流。
有想法，便会踏实，不轻易追逐内卷节奏；
有目标，便会沉稳，不停止自我迭代脚步。
其实，软件开发里，根本没有敏捷。
版权声明：
原创不易，洗文可耻。除非注明，本博文章均为原创，转载请以链接形式标明本文地址。
