[答疑]发现在写代码过程中对需求的认识更清晰了
大伟 2019-3-7 13:40:
是不是对需求能力不强的人来说，跳过需求工作直接写代码更好？我发现在写代码过程中对需求的认识更清晰了。
UMLChina潘加宇：
这是逻辑上的错误归因，把“并存”等同于“因果”。我先说一个笑话作为类比。
*****************
女儿：妈妈，二年级是不是比一年级懂得多呢？
妈妈：是的。
女儿：那我有个好主意，从今天起，我不做作业了，等到二年级的时候，我再来做一年级的作业。等到三年级的时候，我再来做二年级的作业。
*****************
之所以"对需求认识更清晰"，是因为随着时间的推移，开发人员和涉众的交流以及对需求的思考不可避免地增加了（就算交流和思考的方法再差），这个时间里干的活是不是写代码其实关系不大。如果这个时间有的放矢地用在需求上，"对需求认识更清晰"所需要的时间更短。
以下是针对此问题的扩展评论。
如果需求出了问题，在投入了分析设计的工作量之后再修正，损失的代价很高昂（Barry Boehm的研究是高达100倍以上）。所以需求是软件组织最值得改进的环节。这个道理大多数软件组织是懂的，即使有的组织暂时不懂，碰壁之后也很快就会意识到。于是领导下定决心，"下一次要重视需求的采集"。
可惜开发团队缺少需求技能，需求也不是蘑菇，乖乖地躺在森林里一采就得。
很多时候开发团队也匀了时间来做需求，但不知道具体该怎么启发，怎么建模。一拨人到了客户那里，随便看看，问一些问题，开个会，就不知如何往下走了。开发人员只好自己"头脑风暴"，胡乱猜想系统的需求，然后投身于最擅长也最喜欢做的事情――编码。
更要不得的是，有些开发人员为了掩盖自己的无能，干脆假装需求技能不存在，以"敏捷"、"迭代"为名，放弃了这些技能的修炼。
"敏捷"、"迭代"只是一个底线，不是上限。
就像一名从护士成长起来的医生，只掌握了打针的技能，却缺少检查、诊断、拟治疗方案等技能，索性说："唉，这些技能没用的，反正再高明的大夫，也不能一个疗程把患者治好，干脆我也别花那么多心思了，先随便给患者打一针看看吧，不好再来！"。
确实，再高明的大夫也没有把握一个疗程就治好患者，所以要按疗程试试看，但是每一个疗程中，依然要尽力检查、诊断、拟治疗方案。检查、诊断等技能越精湛，所需要的疗程就越少。
===广告分隔线===
| ||||||||||||||||||||
[训练介绍] 软件开发中，需求是解决“产品怎样好卖”的问题，设计是解决“降低生产成本”的问题。二者相辅相成，缺一不可。而且，不能相互取代。要迈向“低成本制造好卖的产品”的境界，并非喊喊口号就能达到，需要静下心来，学习和实践各种技能。 在这个强调“做减法”的时代，建模是正确帮助您“做减法”的绝佳工具。 本训练就是教授如何使用UML2.5相关的需求和设计技能来全程实例剖析一个系统的过程。 本训练对每个开发工作流，结合讲解、做练习巩固、应用到实际项目三种方式，展示使用UML2.5相关技能开发软件系统的全过程，解答实际应用中的疑难细节问题。 [学员要求] 有一年以上项目经验的需求或设计（编码）人员。不需要您有“UML基础”，只需要您有项目经验。欢迎学员携带自己的项目来听课，由专家在现场进行剖析。 [专家] UMLChina首席专家 潘加宇。在1999年还是一名程序员时，利用业余时间创建了UMLChina，潜心研究软件需求和设计技能。2002年开始对外提供UML需求和设计的技术指导和训练服务，到现在为止，已经上门为超过280家的软件组织提供服务，覆盖了国内各个领域的领袖企业，包括通信、企业管理、电子商务、房地产、网络游戏、地理信息、物流、数码设备、医疗设备、工业控制.....等领域。 [课程大纲] 1. 概论 以上时间分配会根据项目特点和训练进程调整。 |