技术人员经常会把自己限定于技术领域，对于需求的实现不是很感兴趣，这是国内的普遍情况。需求和技术是两个不同的东西，如果技术人员把自己限定于只懂技术，那么一般技术人员只会按部就班的做事情，不懂得灵活变通。
技术人员懂需求的好处有：
- 1.了解需求的来龙去脉，可以准确的一次性把事情做对
- 2.减少需求文档，高效沟通，提高生产力
- 3.高屋建瓴地有质量完成代码编码，减少技术债务
瀑布模型和敏捷开发模型是软件开发的两大重要模型，瀑布模型简单来说就是由需求，设计，开发，测试，部署，维护等一系列的项目阶段组成，每个阶段需要划分不同的角色来完成不同阶段的任务，每个角色需要在每个阶段对应的输出对应的文档。敏捷开发模式是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于"非敏捷"，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。
瀑布模型拥有悠久的历史，其一整套机制按部就班，结构严谨，和工厂流水线一样紧凑；敏捷开发是解救这种低效的开发的模式的良药，如果使用得当可以大大提高生产率，国内的软件开发多半是介于两者之间，更多的其实两者都不是，杂乱无章，还处于原始社会阶段。
最近参加了Thought Works关于需求的培训，才真正了解了敏捷开发的全貌。在国内很多公司我们经常听到有人说敏捷开发很好，不需要写文档，项目开发效率非常高，交付速度很快；这是我经常听到的见解，但是世界是遵循质量守恒定律的，既然文档消失了，我们凭什么能做到最好，难道之前的瀑布模式都是错误的？其实是有些人对敏捷的理解浅尝辄止，囫囵吞枣了，文档其实并没有消失，而是转为了另外一种形式存在，那就是各种卡片，沟通和各种模型，以及单元测试等形式，更加的简单和直观罢了。正如我在培训期间提问所说的，没有银弹；敏捷其实是对团队人员的素质要求非常高，需要PO，SM和Teamer都对需求有相当的理解，同时对PO和SM的管理和掌控能力严苛，对开发和测试都需要是全栈。所以，技术人员对需求的理解是相当必要的，不然你根本没法跟人沟通，每个技术人员都需要对需求的来龙去脉搞清楚。
最重要的一点是团队的每个成员要粮草未动，思想先行。要想在团队展开敏捷开发模型，必须每个人对敏捷的理解要正确的价值观，同时要提高自己的沟通意愿，对需求需要积极的参与，而不是机械的参与各种站立会议，在没有文档的情况下，而且对需求还不清晰的情况下就去下任务和做各种开发。作为团队的PO和SM要有全局管控能力，包括对需求的理解和阐述，正确组织各种迭代计划会议，迭代启动会议，站立会议，迭代回顾会议以及迭代本身；作为团队成员需要提高自己的沟通水平，业务水平，以及技术编码和测试水平，同时对团队事务参与要有相当的积极度，同时对各种不清楚要敢于提问，对各种不认同要敢于挑战和发言。
很羡慕欧美国家软件开发的成熟度和技术氛围，国内软件企业和技术方兴未艾，虽然近些年略有成绩。但是在软件开发思想和模式方式缺落后人家一大截，软件技术的软实力不是一天两天能炼成的，也不是靠砸钱能砸出来的，都说中国人有钱，但是钱只能在一些不要软实力，成效快的领域才能发挥作用，软件实力的提高需要软件开发人员和项目管理人员以及各种IT技术人员角色的认知水平的普遍提高才能看到成效。
所以眼界很重要，需要每个人提高自身的素质，包括技术能力，认知水平，需求和测试水平等。未来的世界IT的竞争力是残酷的，如果不提高自己的各种水平那么就很难把握软件行业的发展节奏，那么就很容易被软件行业所淘汰。冰冻三尺非一日之寒，同时作为软件从业人员如果缺少志同道合的伙伴也是很孤单的事情，能力的提供需要各位管理人员和老板，以及各位认知水平达到了的伙伴的慷慨传播，让我们为中国的软件事业共享一份力量。
网友评论