谈需求的时候，不谈技术实现。在软件行业中，这是一句耳熟能详的话，是软件工程师必备的素质。
在敏捷开发的团队里，任何一个成员的职责都不再是单一的，而是系统的，担任的职责要从需求的获取与分析，概要设计，详细设计到编码实现与测试。因此，作为一个软件工程师，需求和技术实现两种思维的掌握和自如的切换，就是必不可少的素质了。
体会这句话，是在最近的工作中，与同事共同开发一个备份升级的模块。这件任务的需求由同事负责，我负责的技术的研究。时间过去大半个月，这个模块的需求仍然范围广泛，功能点不明确。花了大量的时间调研和开会，需求最终给确定了下来。
我观察了同事的整个调研过程，他一边问市场部调研需求，一边问我技术实现的难度，一边又召开会议听大家的观点。事情做了很多，但是需求仍然是模糊的，根本无法交付。
在这个过程中，我认为同事犯了三个错误，首先是将谈需求和谈实现混合在一起，给不懂技术的市场部增加了沟通难度，给不懂市场的技术人员提供了不明确的信息。其次是越俎代庖，过多得考虑了我后台技术的实现，没有给任务设定边界，无限度的扩展到不该考虑的部分。最后是过分的完美，从设计的一开始就想要一个完美的解决方案，这样的任务不多，大多数事情都是探索出来的，要接受不完美，从不完美上重构，直到完美。
需求工程在程序猿的眼中，不算重要的，往往把技术实现看得很重。这种态度往往造成编码完成的产品在实际需要的东西南辕北辙，还存在着技术过度设计的风险。需求澄清明确之后，技术上往往是简单明了的，很容易解决。
在一个敏捷的开发团队里，程序员担任的职责是多样的，一是需求分析员，二是码农，三是架构师。
刚进入一个敏捷开发团队中，发现程序员会花费大量的时间澄清需求，没有明确的需求，规格书作为软件开发的基础。每做一样功能就需求反复的和市场确认需求，召开会议，最后敲定板子开始编码。在前不久看到一篇文章，是对比团队的开发效率和个人的开发效率的，个人的开发效率犹如火箭，而团队的开发效率还属于拖拉机，而我，深有体会。这是必然的，一个人朝着目标奔，和一群人朝着目标奔，一个人的效率更高，但是一群人的成果更庞大，更贴近市场，贴近用户的需求。
《国富论》一书中提到分工合作给社会文明带来巨大的效益，明确的分工不仅提高了产品的生产效率，而且充分发挥了流水线中人员的生产效率。对于单个人而言，做单一重复的劳动，不仅在熟练度上有所提升，而且也减少了事情与事情之间却换的损耗。
分工的好处很多，显然，敏捷开发团队并没有遵循这一原则。程序员担任了多个职责，他们的工作在这些职责中不停的切换，而这样的切换不仅耗费时间，而且耗费精力，长期以往，不仅造成团队的效率低效，而且会助长员工的惰性。
在团队中个人的效率犹如机械硬盘，离开团队，个人的效率犹如CPU。在敏捷的团队中，很明显的感觉到，做的事情更加糅杂。如果不进行规划，很容易失去效率渐渐变得懒惰。在这样的工作中，我认为一个很重要的因素是要及时定位自己角色。现在的工作需要扮演一个什么样的角色。是需求工程师，程序员还是测试人员。分清界限之后，就要切换思维。在未分工的状态下，达到优化切换思维的成本。最搞糟的就是将不迁移思维，把需求和实现混为一谈，像同事一样，明明可以半小时之内解决的问题，偏偏要用半个多月。
