这是一张残简,似乎是一位叫坎普利特的人所遗,记录着他旅行的所见所闻。

离开是否意味着失败,我最近常在思考,关于工作,我是否做的足够好,是否体现了自我的人生价值。

没有。

除了在并不充裕的休息时间里通过看书学到一些知识之外,这段时间我见证了一个网站的灭亡和另一个网站的出生。是什么导致了失败?我们为什么不能像造桥那样做软件呢?

起初老平台还没有完全坍塌,这个系统很糟糕,编码不规范、大量的代码重复和不存在的开发文档都让维护变的更加困难,然而维护还是可以通过一些途径来实现的,真正加速老平台灭亡的是软件腐烂。

有很多因素可以促生软件腐烂,其中最重要的一个似乎是开发项目时的心理。当你所在的团队的代码十分漂亮、整洁、设计良好且优雅,你很可能会格外注意不把它弄脏。相反,一段低劣的代码或是一项糟糕的管理决策,就足以使整个项目开始衰败。根据破窗效应,一旦一扇窗户开始破裂,其他的窗户就会莫名奇妙的被打破,如果不及时修补,后果将不堪设想。如果没有人有时间去清理项目中的碎玻璃,项目将演变成一个巨大的垃圾箱。

如果你发现了你的项目中存在着大量的破窗户,你会很容易产生这样的想法——这些代码的其余部分也是垃圾,我只要照做就可以。你可能会想,为什么不对破窗户进行修补?试想在你修补一扇窗户的同时,又有更多的窗户被打破,这个时候你的心理将产生微妙的变化,间接导致恶性循环。而为什么会有更多的窗户被打破?如果你的团队没有足够的时间来修理,那至少用板子把它钉起来,可惜我们并没有达成这样的共识。

《没有银弹》中说到,构建软件系统最困难的部分就是精确设定要做什么东西。需求内容不明确,将使项目充满更多的不确定性和不可知因素,这些陷阱将最终演变成巨大的代码黑洞。当新平台这个项目开始时,编码也随之开始,始料未及的因素变的越来越多,进度亦将变的越来越缓慢。用户需求是用户和开发团队之间的契约,事实上需求分析在项目开发过程中一直起指导作用,任何不周详的业务需求、用户需求、功能需求甚至质量需求,最终都将对系统造成极大的损害。

软件项目难以按进度安排实现,这种情况极为常见。软件开发中充满许多未知的因素,因此工数估算是一项很重要的工作,必须综合项目复杂程度、开发阶段、人员的生产率等来进行综合性的评估,如果在工数上进行妥协,寄希望于员工加班,将直接影响项目的质量。如果工数过于不切实际,将直接导致团队成员的心理发生变化——不可能完成的任务让人沮丧。

理论上,最高效的团队规模应该是一个人,因为这样就不用交流,团队的人数越多,依赖关系越复杂,交流的成本随之增加。然而实际项目中,由于时间等原因,必须组建一个团队来进行项目开发。每个公司都希望以最小的成本完成项目,项目组织过小将导致人手不足,成员过多也未必是好事,因为个人效率降低而成本提高了。另外一种情况是,项目组的成员技术水平还达不到项目要求,这看上去似乎问题不大,好的员工应该会提升自己以适应项目,而实际上一旦项目启动,破窗理论和短板理论就会发生作用。软件乃是人类自以为最有把握,实则最难掌控的技术,它不同于建筑——工人越多则房子盖的越快,软件开发更像是一群人共同绘制一幅图画。

没有良好的开发计划和开发目标,项目的成功就无从谈起。制定开发计划,首先涉及的是工作分配,若项目组织结构不明确,将导致重复的工作或一些工作根本无人负责,因此必须设立检查点,以定期规范责任范围。若无法良好的实施进度管理方法,则整个团队便像是一盘散沙。

如今我们的项目还未完成,团队中已经有两位成员选择离开,虽然新增加了成员来接替他们的工作,但根据《人月神话》中提到的布鲁克斯法则——往已延误的项目中补充人力,只会使其继续延误。团队合作必须要有交流沟通,交流总会有遗漏和疏忽,尤其是在描述软件行为上面,这就导致新人加入团队时,不能充分了解项目,更不可能高效率的进行工作。

软件项目失败的原因显然不只是这些,代码界总是凶多吉少,没有人能够全身而退。

掩卷思索,似乎一个故事都没有讲。