其实说是敏捷，我们一点都不敏捷。从某种角度来说，敏捷分为三部分：敏捷软件管理，敏捷需求分析，敏捷软件开发。
敏捷项目管理：
敏捷软件管理，是一个可大可小的东西，是凡牵扯到管理，都离不开人，沟通，范畴，成本，进度等等，其通常包含制定计划，里程碑设置，成本核算，人员配置等等，这个不去细谈。
敏捷需求分析：
而对于敏捷需求分析，其相对于传统的需求分析，不是一个好或者坏的问题，而是一个更适合的问题，找到适合自己的方法爱是才是真正的方法，没有放之四海皆可的真理。敏捷期望有个现场客户，可是实际中，很难做到，所以在此种环境，出现了强悍的商务分析师，他们去了解，沟通需求，甚至挖掘，跟客户探讨如何才是客户想要的，如何给客户提供他最想要的，最直接的东西，可是有多少公司有这样子的业务分析师？又有多少公司或者愿意花这么多时间去在需求上来回的折腾？最起码我们公司目前没有。所以在这种情况下，需求通常无法准确的获取，都是通过中间很波折的变更修改前进，因此大部分的项目，起点就已经出现了问题（当前我们公司是通过前期画详细的Mockup来尽量避免后期的一些变更，这个方法挺好的，我觉得这对于Story的划分也是有很好的效果，唯一的欠缺是前期需要不少时间在这上面）。理想的敏捷需求分析中，对于商务分析师的要求是相当强的。不谈这些理想的情况，对于我们当前没有很好的需求分析人员的情况下，如何才能够即获取敏捷需求分析的简单直接高效的优点，又能解决当前这些问题呢？还有一种现实情况是大部分的公司（最起码我们公司），需求是项目经理和业务人员去交涉的，在此中情况，项目经理的角色就已经拥有了很强的商务分析的角色，此时，项目经理可以在某个层次，结合自身对于技术的掌控，对业务快速的了解，以及可能的架构，成本等等综合因素去分析和探讨一个相对满意的方案，这也就要求项目经理能够超脱出当前的身份（毕竟大部分的项目经理是从技术出身的，这是优势也是劣势，当然超脱不了技术的项目经理也不是个合格的项目经理），而一般这个角色项目经理来担任也是比较靠谱的，唯一欠缺的可能是项目经理本身对于这件事情的态度，跟客户沟通的能力，运筹能力等软实力。
记得前些日子跟客户沟通一个生物项目的时候，让我受益匪浅，先记录如下：
- 对于沟通的过程，如果不停的记笔记，会让过程被打断，显得很不自然，而且让客户会对自己说的话更加小心，这样子会失去一些好的氛围，客户的小心谨慎导致他会很小心的说出观点，往往不能讲出自己对于一些事情的完整态度，进而对于需求挖掘的原始信息会造成损失；而且过程中，不可能什么都记下来，所以难免会忘记些什么，所以用手机录音整个过程回来慢慢分析，不失为我这种笨人的一个好方法。
- 沟通一定站在对方的角度，最起码要让他感觉到你是站在他的角度，不要讲专业术语，尽量通俗化，客户的观点，尽量自己用自己的理解重复一遍给对方，目的就是为了发现客户到底想要什么，而不是去防御客户什么，也不是骗他钱。
- 沟通的过程，尽量有所依据，并且沟通前做好准备，有的放矢，防止浪费大量的时间当场消化，浪费自己的时间，也浪费别人的时间。
- 给客户描述一个问题，尽量从客户的公司流程去描绘，不要用一些虚无的假设和假象
待续。。