所在位置:答疑 - 内容   
发现在写代码过程中对需求的认识更清晰了
 

大伟 2019-3-7 13:40:

是不是对需求能力不强的人来说,跳过需求工作直接写代码更好?我发现在写代码过程中对需求的认识更清晰了。

UMLChina潘加宇:

这是逻辑上的错误归因。我先说一个笑话作为类比。

*****************
女儿:妈妈,二年级是不是比一年级懂得多呢?
妈妈:是的。
女儿:那我有个好主意,从今天起,我不做作业了,等到二年级的时候,我再来做一年级的作业。等到三年级的时候,我再来做二年级的作业。
*****************

之所以"对需求认识更清晰",是因为随着时间的推移,开发人员和涉众的交流以及对需求的思考不可避免地增加了(就算交流和思考的方法再差),这个时间里干的活是不是写代码其实关系不大。如果这个时间有的放矢地用在需求上,"对需求认识更清晰"所需要的时间更短。

以下是针对此问题的扩展评论。

如果需求出了问题,在投入了分析设计的工作量之后再修正,损失的代价很高昂(Barry Boehm的研究是高达100倍以上)。所以需求是软件组织最值得改进的环节。这个道理大多数软件组织是懂的,即使有的组织暂时不懂,碰壁之后也很快就会意识到。于是领导下定决心,"下一次要重视需求的采集"。

可惜开发团队缺少需求技能,需求也不是蘑菇,乖乖地躺在森林里一采就得。

很多时候开发团队也匀了时间来做需求,但不知道具体该怎么启发,怎么建模。一拨人到了客户那里,随便看看,问一些问题,开个会,就不知如何往下走了。开发人员只好自己"头脑风暴",胡乱猜想系统的需求,然后投身于最擅长也最喜欢做的事情――编码。

更要不得的是,有些开发人员为了掩盖自己的无能,干脆假装需求技能不存在,以"敏捷"、"迭代"为名,放弃了这些技能的修炼。

"敏捷"、"迭代"只是一个底线,不是上限。

就像一名从护士成长起来的医生,只掌握了打针的技能,却缺少检查、诊断、拟治疗方案等技能,索性说:"唉,这些技能没用的,反正再高明的大夫,也不能一个疗程把患者治好,干脆我也别花那么多心思了,先随便给患者打一针看看吧,不好再来!"。

确实,再高明的大夫也没有把握一个疗程就治好患者,所以要按疗程试试看,但是每一个疗程中,依然要尽力检查、诊断、拟治疗方案。检查、诊断等技能越精湛,所需要的疗程就越少。