最近公司研发部在注重流程化、标准化的基础上，引入了敏捷的概念，并在刚刚做完的一个小项目中做了初次的尝试。
同时，最近自己在看《敏捷软件开发：原则、模式与实践》，研究关于敏捷的东西，有一些基本的想法，在此分享。
角色：
1、客户：定义产品的特性并排列这些特性优先级的人或者团体。
2、开发人员：响应客户的需求，实现这些特色的人或者团体。
个人认为敏捷开发中适宜采用的几个方式为：
一、和客户在一起工作，让客户融入团队。
彼此知晓对方所面临的问题，并共同去解决这些问题。
最好的交流方式，就是面对面的交谈。
客户合作胜过合同谈判。
我们项目中做的就是：固定的每天早晨有一个小型的、简短的、但是保证有效的沟通例会，
共同的任务：先跟踪前一工作日若干问题的解决情况，并标注那些尚未能解决问题的原因、并提高其优先级。
产品人员：提出对需求的新的想法、对已有功能的修改要求以及一些需要从技术角度进行解释的疑问等。
开发人员：确认对变化的理解，并给出对应的响应。然后提出在开发过程中对需求的疑惑，或者说是不看明确的地方，由产品人员确认。最后，给出具体的计划。
二、尽早的、频繁的交付软件，哪怕是未成形的，存在着很多bug的初级版本。
根据XP理论，初期交付的系统包含的功能越少，最终交付的产品，质量也就越高。个人理解，这句话是提醒我们，应该尽早的让客户完全融入到系统的形成流程中来。
由于项目较小，迭代周期保持在三到四个工作日。初期未形成可堪使用的图形界面时，开发人员用图表、简易图的方式向开发人员尽量描绘清楚设计的基本框架，
并得到双方确认。图形界面开发出来后，及时提供给产品人员，与之前的心里预期进行比对，并在每次晨会提出修改意见。
这样，在项目完结时，我们提供的产品是倾注了开发、产品人员的共同思考的，基本是符合双方心理预期的。
三、欢迎需求的变更
需求的变更，一直是被开发人员所深恶痛绝的事情，但是，随着客户对需求有了更深刻的认知，甚至开发人员对需求有了更清晰的理解，都有可能带来需求的变更。躲不掉！
而XP的精髓，恰恰是，欢迎变更需求，敏捷过程的参与者不惧怕变化。因为那些改变意味着团队已经学到了很多如何满足市场需求的知识，那么我们该怎么做？
保持软件结构的灵活性（这个正在研究，以后补充）
欢迎，并不是意味着毫无原则，而是，和客户一起来分析变更的需求，评估变更所带来的预算、工期等一系列影响，制定变更与否、甚至变更程度的计划。
待续......
