敏捷开发可所谓吹遍了大江南北，在各个IT行业以及公司都开始逐渐在实践以及运用，接触有敏捷理论一段时间了，并且有在实际项目中有过实战经验，可谓是从理论到实践走了一趟。先来说说自己的感受吧，敏捷开发确实是加快了发布的频率，降低了风险，但同时也会让人不断的忙于迭代中，一个迭代刚刚完成，紧接着一个迭代就会到来，会让团队一直处于应战的状态，这跟蹦紧的玄久了容易导致大家都觉得特别的累，这个时候就需要一些鼓励以及让团队成员成就感的东西，让他们觉得一直以来的辛苦付出是值得的。
敏捷开发想要顺利走下去，离不开三大基石。
- 第一是透明
一个可交付的产品，必须要在团队内做到完全的透明，要尽量让每一个人都知道你的目标是什么，大家往一个方向在走，从文档、代码、会议都要做到透明化，而且作为product owner也要不断的去给大家灌输这些思想，首先要讲明白你要做什么。透明性的把控也很重要，对项目内部成员透明，包括代码、文档、会议记录、架构设计等，对外部用户透明，让他们能够时刻看到我们的进度以及做的内容，那么问题来了，如果让用户看到了进度以及内容，那么一定会增加很多的沟通成本，但是对最终交付是有利的。
- 第二是不断的核查/校验
敏捷开发实践周期比较短，其实是没有太多实践给你犯错的，如果有人理解错了，方向错了，如果部及时纠正，那最后交付根本无法实现，所以在开发过程中，就需要不断的去校验/核对 开发人员理解的对与否，与客户确认，目前的方向是否正确。
- 第三是要适应变化
如果校验发现方向不对，那么就要立即修改，往正确的方向上走，这对程序员来说其实很难，业内曾经发生过很多的事情，都是因为开发与产品之间的矛盾，程序员从心里来说部希望在这个sprint有太大的改动，一旦改动就又要重新设计，重新编码等，又会要加班，要让团队成员觉得拥抱变化，愿意去修改，如果想要少修改，就要求在第一阶段将需求弄清楚。
敏捷开发也有他的核心理念
- 以目标为导向
传统瀑布式开发也有目标，但是目标周期有些长，容易走着走着就走歪了，而敏捷开发目标周期较短，2周或1月，一定能够找到非常清晰的目标，所以project owner在给scrum team布置任务的时候，就必须要确保做的内容是可以衡量的，SMART原则就非常的实用。在设置目标的时候，就非常考验个人经验的时候了，目标工作量的衡量，目标的分解，目标的工作分配，人员分配，时间的评估等等，总而言之，定下来了，所有人必须要朝着一个方向走。
- 重视沟通
无论在那个项目中，沟通都很重要，但是在敏捷项目中，沟通又是重中之重，时间压缩了，在2周内必须要交付成果，如果大家都不加强沟通，那么在交付的时候就会互相职责，互相妥协责任，这种沟通，必须要从上到小的培养出沟通的习惯。
- 尊重客户的意见
作为一个技术人员，其实是很不希望非技术人员在旁边提意见的，因为他们考虑的角度与程序员完全不一样，但是现在我们必须要洗耳恭听他们的意见，因为这是我们的目标以及交付标准，如何改变心态，这点非常重要。
- 拥抱变化
不变的就是不断的变化，可以来说明敏捷开发的整个过程，不要因为客户忽然新增功能点或者移除了某些功能而感到愤怒，不要抱怨用户变来变去，系统的开发就是在不断的改进之上的，没有人能够一次性做到位。
