记录一下，终究不敢实名发布

关于《软件开发与人》的一些想法

公司风风火火的搞可信，领导心心念念想打造软件土壤。
瀑布模式走向敏捷开发，行动上更像是集团军走向了特种兵，以前看《士兵突击》都是从集团军选老A，下一句就有些伤人了。
我司理念中有一种灰度的操作手法，深入到所有人的内心，同时又有红线，同样是核心认知之一。公司软件编码有L0到L4，L0最low，我们不会挂在嘴边，我们现在要求全部满足L1，部分部门冲刺L2。我们有白盒门禁，有编码评价，有Program Smart，迄今为止，我没听到哪一个领导说过L0--功能正确。我们以为我们都能做到，其实呢，大部分做的并不好。或者退一步说，当功能问题出现的时候，多久能定位完成？多久能修复呢？好像也不乐观。
华为测试人员真的是我所认知到地位最高的测试，为什么呢？一个是容忍，拿到一个测试版本，正常流程都走不通，这得多少个WTF？一个是当责，从测试出口的软件，至少都是可用的。我要是领导，我也得提高测试地位，他们真的被折磨得不轻。
开发人员的心态，开发人员长期处于“被压迫”状态，交需求，清单，过点，缺少主观能动性。荣誉感可能会有一些缺失，现在很少看见有那种羞耻感--我代码有问题，我很丢脸。什么是工程师文化或者极客文化，这两者肯定有很多区别，但估计都绕不过这种荣誉感，软件改变世界，我们开发软件。以前军训的教官说过一句话：如果死后能给我盖上国旗，现在去死都可以。他可能连士官都不是。
关于交付，交付的时间压力永远存在，需要变更的需求永远存在，设计模式，灵活架构就是为此存在的。之前我提过一些很反动的言论：最终决定软件是开发人员，如果架构师不能满足最终的开发诉求，任何架构都是无意义的，都是可以不听架构师的。正确评估自己开发的时间是一个软件从业人员基本的能力之一，我不太喜欢项目经理拆解的开发完成和验证通过，这应该是合一，通过L0的代码才叫开发完成，自验证文档至少作为输出件。时间上另开发人员为难的地方是评估了5天，领导会算上24小时，这是领导的艺术，我不是很懂，但考虑到当前的大环境，至少我认为9:00-22:00之外的时间，任何时候都不能作为评估时间了，如果对应的时间不能完成，应该开率的是替换更高技能的开发人员，或者延长时间。
从下往上看，我们很难考虑到领导的为难之处，比如人员配置，这个是短期内不可更改的。既要达成目标，这需要压力，压力又不能太大，水至清则无鱼，个中滋味我没有体会。
见过一些乱象：按期交付，但是基础功能不过关，规则是固定的，处理可以是灰度的，否则又能如何呢？朝令夕改还是灰度处理？胡萝卜不多，大棒也不痛。实现不符合通用做法，是限期整改还是第三方简易适配，限期整改是正确而伤人，第三方简易适配是荣誉感丢失。
想法很多很乱，却也没有切实想法，成不了方法论。
拨乱反正，我司有强大的流程基因，不断磕磕碰碰，最终达成目标。这是流程的胜利，不是开发人员的胜利。
我想去看看“人月神话”了，或许可以学到些什么。