责任人、开发者和用户应该能够保持个长期、恒定开发速度敏捷相对以前软件Software工程最大革新的处在于把人作用提高到了过程至上正如敏捷宣言第条“个体和交互胜过过程和工具”所说

　　1、敏捷是“个”过程

　　敏捷不是个过程是类过程统称它们有个共性就是符合敏捷价值观遵循敏捷原则

　　敏捷价值观如下:

　　◆个体和交互 胜过 过程和工具

　　◆可以工作软件Software 胜过 面面俱到文档

　　◆客户合作 胜过 合同谈判

　　◆响应变化 胜过 遵循计划

　　由价值观引出12条敏捷原则:

　　◆我们最优先要做是通过尽早、持续交付有价值软件Software来使客户满意

　　◆即使到了开发后期也欢迎改变需求敏捷过程利用变化来为客户创造竞争优势

　　◆经常性地交付可以工作软件Software交付间隔可以从几个星期到几个月交付时间间隔越短越好

　　◆在整个项目开发期间业务人员和开发人员必须天天都在起工作

　　◆围绕被激励起来个体来构建项目给他们提供所需环境和支持并且信任他们能够完成工作

　　◆在团队(Team)内部最具有效果并且富有效率传递信息思路方法就是面对面交谈

　　◆工作软件Software是首要进度度量标准

　　◆敏捷过程提倡可持续开发速度责任人、开发者和用户应该能够保持个长期、恒定开发速度

　　◆不断地关注优秀技能和好设计会增强敏捷能力

　　◆简单是使未完成工作最大化艺术??是根本

　　◆最好构架、需求和设计出自于自组织团队(Team)

　　◆每隔定时间团队(Team)会在如何才能更有效地工作方面进行反省然后相应地对自己行为进行调整

　　建立敏捷联盟17位大师所创立敏捷思路方法包括:极限编程Scrum特征驱动开发动态系统开发思路方法自适应软件Software开发水晶思路方法实用编程思路方法这些思路方法统称为敏捷思路方法

　　其实每个人都可以从敏捷宣言和原则出发明确问题找出些解决思路方法形成自己过程我觉得国内软件Software环境这么复杂员自主精神又这么强敏捷思路方法应该是在中国首先提出才对只是国人都有唯标准唯规范标准至上心理定式即使找出好办法也觉得不规范标准没有深入形成理论无法提升高度始终是跟着鬼子屁股后面走我想这也是国外软件Software行业不成熟表现的吧！

　　2、敏捷仅仅是个软件Software过程

　　如果仅仅从软件Software过程角度去认识敏捷实施敏捷效果不会太好敏捷相对以前软件Software工程最大革新的处在于把人作用提高到了过程至上正如敏捷宣言第条“个体和交互胜过过程和工具”所说

　　涉及到人问题就已经不再是过程所能覆盖了就到了企业管理层面上了包括企业价值观和文化这也是敏捷在国内实施最大障碍:

　　把客户当作合作伙伴而不是对手从客户角度出发去想问题充分跟客户沟通而不是出了问题推诿责任目标是让软件Software实现客户价值而不是收钱就完事儿

　　把人能动性调动起来给动力而不是给压力

　　要实用而不是要规范标准让开发人员理解并实施体验到敏捷好处而不是盲目机械地实施规范标准

　　没有绝对权威每个人都有可取的处

　　3、迭代就是敏捷UP属于敏捷

　　看到这么多人都把UP归入敏捷我都开始怀疑是不是自己搞错了但是在我印象中:

　　UP是重型过程虽然引入了迭代但是其原则和价值观和敏捷是区别敏捷注重是反馈迭代周期尽量短重在客户参和通过客户参和获取持续反馈不断调整使整个项目走在正确方向上同时也给客户个感受和研究机会对于大多数客户而言目标是明确(不排除有些客户目标也不明确)但是具体如何做开始时是没有想法只有看到具体东西时候才知道“噢原来可以这样那我想把这里调整下”

　　4、敏捷是彻底革命

　　敏捷特别是XP让人有耳目新感觉觉得以前所有软件Software工程理论设计思路方法都可以抛弃掉了推翻切从头再来抱着这种想法实施敏捷那就错了敏捷不是“石头里蹦出个孙大圣”以前软件Software过程中也有敏捷影子只是没有像敏捷样上升到价值观和原则高度比如快速原型法敏捷是在对已有软件Software过程思路方法改进抛弃是传统软件Software工程低效外表以往软件Software过程中很多窍门技巧都是很实用实施敏捷应该以现有软件Software过程为基础从敏捷宣言和原则出发利用敏捷思路方法来改善过程

　　5、敏捷是反文档

　　文档只是为了达成目标种手段如果这种手段是低效那就换种手段可是完全抛弃了文档怎样解决沟通问题?难道你想每次沟通都完全用手比划用嘴说跟区别人重复表述同样想法那样更是低效

　　应该清楚文档本质是把知识显性化在个项目中存在很多需要沟通知识知识具备两种形态显性和隐性传统观念是尽量把隐性知识显性化即文档化而忽略了这其中代价(特别是更新同步文档代价)

　　因此在实施敏捷时候需要在团队(Team)内明确哪些知识是必须显性这些知识可以通过文档交流哪些知识是可以隐性这些知识则完全可以通过口头方式进行交流以达到沟通最佳效率

　　文档不是目有效沟通才是目

　　6、为了敏捷而敏捷

　　“嗯敏捷这么好我们也敏捷吧”可能很多人会有这种想法忘了以前是在哪儿看大师采访录:

　　Q:“我们现有过程很好不知道如何用敏捷改进?”

　　A:“既然很好那就不要用敏捷”

　　做什么事情都要有明确目标敏捷虽好得看你需不需要能不能解决你现在头疼问题如果不是那就不要给自己找麻烦了



　　7、敏捷是CMM反义词

　　在讨论中很多人把CMM作为敏捷反义词我觉得这不是很合适CMM只是种衡量软件Software成熟度标准并非过程和敏捷不是类概念如果要给敏捷找个反义词我觉得传统瀑布式开发应该更合适些

　　并且我认为如果CMM还能继续流行下去话应该会有公司可以用敏捷改善过程通过CMM认证

　　8、敏捷是自由无约束

　　敏捷强调是自组织团队(Team)发挥人能动性以动力代替压力让人有绝对自由错觉但是应该清楚凡事都是要讲究个平衡人也是两面消极面和积极面同时并存绝对自由会放纵人消极面敏捷并非是绝对自由无约束作为管理者有个职责就是引导团队(Team)成员用自己积极面去压制消极面不能放任团队(Team)中出现搭便车现象否则将打击整个团队(Team)士气如果实在无效那就只能将其排除出团队(Team)了这个惩罚够有约束力吧?

　　9、重做就是重构

　　重做不等于重构很多场合这两个概念是混淆但是在敏捷中重构个特征是必须可控当对系统结构进行大调整时如果没有测试驱动辅助话那么可控性就会很差这不能叫做重构