读《用户故事与敏捷方法》有感（一）
进入软件工程专业之前，对工程二字几乎没有什么概念，光知道大家都这么称它，那时候就想着，工程这么高端的词不应该是一个巨大的项目而且会有着巨硕的成果吗？为什么软件也会有工程一说？通过进一步的学习和阅读了解，想想当时还是太年轻。软件工程一个项目的完成，意味着需求分析->数据库设计->功能编码实现->软件测试->发布与维护这五个步骤的紧密结合，缺一不可。那么今天，我开始阅读《用户故事与敏捷方法》,算是从第一步开始慢慢了解一个项目的研发。
谈读后感之前，先件数自己对需求分析的理解，结合之前老师教授的课程。我认为需求分析是软件工程一个项目的开端，奠定全局的基石。要保质保量完成一整套流程必须有坚实的底座为支撑。所以做需求分析一定要全面、严谨而且细致，不然中后期可能导致牵一发二动全身的严重后果，甚至是项目失败，项目失败了不单单是一个项目的事了，涉及到整个团队，让人绝望人心涣散，所以需求分析这第一步一定不能草率，要坚实地迈下。那么问题来了，怎么做需求分析呢？
让我们从用户故事开始逐步领会需求分析的微妙之处，自计算机问世到普及以来，一直有程序员这个称谓的存在，然而大部分人心中都认为程序员就是那种一身老土的夹在裤腰带里的衬衫，戴着厚重的眼镜框呆板的形象，在这里我要对他们说不，真正的程序员，应该说是软件工程师，他们绝对都是一种高情商思维灵动的生物，软件工程师是贯彻一整个软件项目的全局人员，之前提到的五个方面对于软件工程师而言简直要面面俱到，就从软件需求说起。软件需求是一个沟通问题。需要新软件的人（使用或销售软件的人员）必须与开发新软件的人交流合作。一个项目的成功，依赖于很多不同的信息，这些信息来自各有不同的人员：一方是客户和用户，有时还有分析人员、领域专家或组织视角来审视软件的人；另一方是技术团队。一旦任何一方在沟通中把持绝对地位，项目就会遭受损失。如果业务方把持绝对地位，他们就回关注软件功能和交付日期，却很少关注开发人员是否能够同时满足这两个目标，或者开发人员是否确切地了解需求。如果开发人员把持绝对地位，技术术语就回代替业务语言，从而导致开发人员无法请业务方的实际需求。我们需要一种协同工作的方法，让双方都不占绝对主导地位，共同面对感情用事和办公室政治化的资源分配问题。若资源分配问题完全落在一方，项目必定会失败。如果只让开发人员来承担这些问题（他们通常会被告知“我不关心你们怎么做，但请你们在某月份之前完成”），他们可能会牺牲质量来换取额外的特性，也可能只实现一个特性，或者自行做出一些本该在有客户和用户参与情况下才能做出的决定。如果只是客户和用户承担资源分配的责任，那么我们通常会在项目开始时看到一些漫长的讨论，项目中的特性逐渐减少。之后，在最终发布软件时，只剩下很少的功能，甚至少于被剪掉的功能。
由此可见，从最初步的软件需求分析就要考虑到开发人员和需求方对项目的实际参与度问题，各种权衡利弊还要通过真正使用者的业务流程总结对应的功能。所以需求分析很重要，程序员并不只是呆板的码农。
