敏捷开发（名字起得很帅，很忽悠人）原则 括号里面加了自己的理解笔记

敏捷开发，名字起的很帅，很忽悠人（不知道有多少BOSS被这个名字给忽悠了，敏捷！节省成本啊，太好了）。
下面是一个培训的PPT内容，后面括号中备注了我的理解，心态平静没有愤青（感觉敏捷概念就是打擦边球的东西，怎么都能解释的实践，不像教科书那样标准，如果团队全是高手，什么方式都能成功，如果很多毕业生我觉着还是统一规划的方式比较好，估计敏捷就是建立在高手团队实践出来的经验吧，很多概念说起来，都会让人理解为当场拍脑袋）

看过培训PPT总结的敏捷核心含义如下：（我没有照套路实践过敏捷开发，这个概念一定会受到追捧原因是多方面的符合心里需求，但最后很有可能误导做成了小作坊式）

1.写代码最重要，什么都可以让程序员来兼职，项目来了就开始写代码，有问题的时候，大家一起聊一些，聊完了之后改需求（他们叫积极应对变化）加班忙的要死。没有问题的时候大家闲着想做什么就做什么或者安排重构。

2.任务不停的迭代，写代码凭感觉，自由发挥，大胆实践，反正最后一定会有大重构的环节托着，管他谁来维护谁来重构，用重构去解决所有问题，用重构解释这个“敏捷"带来的一切问题，不知道BOSS们算过了这高效开发的代价了没有（哪里是重构，比重写还让人头痛）。

在某些方面我不会这么做，因为成本太高（员工要求高，进度迭代压力大，代码质量不好控制，重构代价大，维护成本高，程序员走了谁来维护这天马行空出来的实践了N多种框架为一身的代码啊），不好控制，而剩下的方面又全部都是所有书中必须写到的，也许敏捷实践对我用处不太大了。

这篇文章也用了一次敏捷，写完就先发上去，也没有管写的好不好，有没有错别字，全当实践敏捷了，等大家看到错误了，告诉我，我先下班回家，回头重构文章时候再改：），这我理解为《尽快交付可用版本》。

注：原文来自培训的PPT

<!-- 这部分可以注释，都是垫场子的词

程序员最头疼的问题

•需求的不断变化

•代码混乱，没注释、乱使用全局变量等等

•没有跟代码对应的设计文档

•需求很急，加班都做不完的任务

•计划老在变化

•对客户的需求细节了解不够，只能根据经验猜测客户需求

•自制力差，工作效率低

•得不到别人的帮助，只能通过网络找资料

敏捷（Agile）的起源

•1998年末Kent在wiki上发表关于eXtreme Programming的一些观点

•1999年慕尼黑OOP大会上第一次全员讨论

•2001年成立敏捷联盟，发表敏捷宣言

•2003年陆续出书，来描述敏捷的意义

•2004年陆续演化出多种敏捷开发的方法：XP方法、各色水晶方法、

敏捷宣言 （宣言就是好几个利益相同的人坐在一起约定好了，大家就这么干，错了也这么干，想出名就得弄出来点新鲜的）

•我们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。通过这项工作，我们认为：

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

•可以工作的软件 胜过 面面俱到的文档

•客户合作          胜过 合同谈判

•响应变化          胜过 遵循计划

•虽然右项也有价值，但我们认为左项具有更大的价值。

-->

敏捷宣言 – 个体和交互

•个体和交互

1.每个团队成员。(？)

2.发挥每个成员的特点和长处。 为个体塑造弹性的发挥空间。(干吧，想怎么干就怎么干，公司给你开工资怕啥)

3.合作、沟通比单纯的写程序更重要。（这个不是敏捷特有的吧，就是不学敏捷不懂也不能憋着不说啊）

4.团队的意义所在 – 你不是一个人在战斗！（统一过程更讲究团队，甚至主要讲的就是团队）

•过程和工具

1.过程追求标准化，限制了个体的发挥。（相反，过程标准化可以让代码更容易维护）

2.工具-越强大的工具学习成本越高。目标是软件开发，不是学习工具。（你是说框架吗，这个同意，不追捧框架）

3.选择合适的工具。（是啊，写dotnet 不用VSTS，难道还用记事本装大牛吗）

敏捷宣言 – 可以工作的软件

•可以工作的软件

1.开发的目的是交付可以工作的软件 （只有软件，不写任何文档了吗？误导我们，给我们想象的空间？）

2.对用户来说文档还存在一定的想像空间，会造成沟通障碍。（先做原型出来沟通啊，空说当然不行）

3.最好的文档是代码和团队。（没有说不沟通啊，什么都没有，说了一堆，谁能马上记住呢？你总找人沟通，一会别人做其他的事情去了，等待吗？）

•面面俱到的文档

1.没有文档的项目是个灾难

2.文档的目的是沟通和总结，让大家明白要做什么、怎么做

3.提倡的文档方式-看图说话

4.必要的时候也是需要完善文档的

（是本书都会教上面这些）

敏捷宣言 – 客户合作

•客户合作

1.绝大多数软件系统是不能直接带来效益的（这个意思是说，想通过不断的客户需求打民工，赚人力认可吗？）

2.客户对自己的需求也不是很明确的，我们需要充当顾问（很正常）

3.跟客户是一起来完成一件事情的，需要客户的不断反馈（客户不会天天见你们，特别是那些可以拍板的客户更不会见你，他们只有等你做完了之后才会给你提出反馈）

•合同谈判

1.软件公司是指着合同来生存的（没理解，做产品卖不能生存吗，难道敏捷只针对项目开发）

2.谈判只能暂缓变化，不能阻止变化（这是一定的，不升级，要版本做什么呢）

3.合同和谈判是必须的，客户合作是企业长期发展的选择（那还用说，是买卖都要有合同）

敏捷宣言 – 响应变化

•响应变化和遵循计划

1.计划赶不上变化（什么都不去思考，拿出来就做，当然会有变化）

2.需求在变化、开发人员对业务的认识在变化、技术点在变化（为什么不培训一下呢）

3.长期计划稳定，短期迭代。2周到详细计划、一个月的粗计划、三个月的目标计划。（迭代是一定的，但不是拿迭代来做为解决问题的唯一）

4.当变化没发生的时候不要猜测变化（大家可以闲等着，为什么不把变化与客户沟通来确定变化需求呢，早些知道需求变化，就会更好的应对需求变化，这么搞不大重构3个月才怪呢！）

5.着力完成本计划内的工作任务，不需要为后期工作预留过多的接口和功能冗余（没有任何设计，想留也不知道留什么）

6.力求设计简单清晰、降低耦合、模块可以自说明、大胆重构（都是刚毕业的，又没有规定怎么做，他们知道怎么低耦合，什么是对的，怎么大胆重构，重构对于很多程序员来说，就说以重构为目标清闲）

总结

•目标是完成可以工作的软件（这个是必须的）

•文档是用来沟通的中间产物（也是必须的，当然不会有用没有用乱写一堆）

•团队合作和内部沟通是很重要的，每个人都要为团队负责同时团队也要为每个人负责。（是啊，又不是上托儿所）

•沟通需要争吵，不是一定要和谐。个体要极力为自己观点补充细节，更要聆听不同意见。但最终要统一意见。（可以啊，但是争吵的气氛就算了）

•工作是需要方法的，同样沟通也是（当然了，按你说的方法”争吵“吗？）

•工作氛围是可以相互影响的，不需要太安静（这是肯定的，不过这个是理论吗）

•积极面对变化（必须地，但不是谁说的变化我都做）

•工作要：快乐、积极、学习、合作

（我的总结，敏捷就是平日没有项目的时候大家闲着打游戏，不用规划，不用设计，来项目忙的像无头苍蝇？）

敏捷宣言的原则

•我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意（什么方式这都是必须的，降低成本那个老板不高兴）

•即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。（后期啦还该需求呢，之前做啥去了，天啊。不过当然可以，时间延长嘛，但我相信敏捷一定会更费时间）

•经常性地交付可以工作的软件，交付间隔可以从几周到几个月，交付时间间隔越短越好。（做项目这样当然最好，做产品呢，交完了，不断打补问题，改需求？）

•在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。（很理想，封闭开发吗？，那个开发人员不希望呢？，但是做项目业务人员又不是甲方，最后的结果还是改，大改，反正我有心理准备）

•围绕被激励起来的个人来构建项目。给大家提供所需的环境和支持，并且信任大家能够完成工作（项目组？看来每个人都有项目经理的能力啊，充其量他给个小组激发一下）

•在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。（肯定的，但是谁会时刻陪着你）

•衡量进展的重要尺度是可运行的软件。（一定的，软件公司就是做软件的）

•敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期、稳定的开发速度（我认为敏捷很难保证这点，很难。大实话）

•不断地关注优秀的技能和好的设计会增强敏捷能力。（本来就是技术能力的提高，为什么偏要写成敏捷能力呢，敏捷能力是建立在高手团队基础上的吗）

•高质量完成本次迭代中最简单的工作是根本。（有时间压着，又要发挥，又不设计，拍板的人没有，高质量完成？）

•最好的构架、需求和设计出自于自组织的团队。（大家一起来考虑对吗？非技术型的技术总监表示赞同。）

•每隔一定时间，团队会在如何才能更有效的工作方面进行反省，然后相应地对自己的行为进行调整。（自我检讨，我不应该在没有需求和问题的时候打游戏）

敏捷开发实践 - 团队组成

成员分类：

•团队长

•业务及需求代表

•开发人员

（没有测试，没文案，没有实施。。。。哦，也许你的解释是这只是做开发的，但是一个开发小组至少要有测试啊，天啊。）

敏捷开发实践 – 结对编程

•两个人在一台机器前共同开发一个功能模块（从来没有见到过，真的，很期待结果。）

•随时沟通、讨论、画图，随时争抢键盘编码（呵呵，晕倒了，两个人抢键盘！有噱头，有新意）

•共同对本模块负责（两个人都负责？，谁做？）

•每天有3-4个小时结对编程就够了，其余时间对系统和技术点研究、测试（呵呵，你还有时间吗？代码还没有写完吧）

•结对编程的个体要经常变换，以便相互学习（hello，我用Castle，你用什么吗？我们一起尝试一下两个框架在这个项目里面会出现什么样的效果？）

（看过以上的这段，我更喜欢用分工）

敏捷开发实践 – 任务分解

•每周项目组长把任务分解成功能点，由队员来结对选择。每个功能点由两个人共同负责，一个人主负责。（我会小组分工的，但是负责要是有程度的，工作室有分工的绝对不会两个人都负责，我会按工作内容分工和搭配，比如一个做业务层，两个做UI，再搭配一个测试，让做业务层的同事负责）

•选择的任务必须按时完成。（真美好啊，但是直接分配什么都不管，什么都程序员一个人管，不确定因素这么多，加班吧你。）

•指定时间对任务的收回以可工作的软件为最高依据。（出东西就行，不管你里面写的有多糟糕，出东西就行，管他谁去维护呢）

•任务尽可能短小，到Function级别（一个函数的任务？美国程序员的工作量啊！太好了）

•任务要分优先级别（做啥不分优先级？）

•鼓励队员选择非专长功能点，要有相对专长的人配合（中国老板要的是你什么都会什么都能做，不是花钱培养你）

敏捷开发实践 – 重构（这个就是敏捷的托儿，解释不了的了，就说重构可以解决）

•单一职责原则

就一个类而言，应该仅有一个可以引起它变化的原因

•开放封闭原则

软件实体（类、模块、函数）应该是可以扩展但不可修改的

•替换原则

子类必须能够替换基类

•依赖倒置原则

细节依赖于抽象。细节是外层，抽象是内层。

•接口隔离原则

不强迫客户依赖他们不使用的方法。接口属于客户，不属于所在类的层次结构。

（呵呵，把设计模式粘贴上来的吧）

总结（也是重构的时候加上的）

开发项目首要的是解决项目成员之间的合作与分工，解决这个问题之后再选用一个适合团队项目开发和分工的框架引用其中的部分做指导。

开发还是要尽可能的考虑到位，拿过来就干，每个人依赖沟通，可以培训一下，分析规划和设计是有必要的，总结经验很重要，套路是可变的。

2009年9月8日 20：13：00，文章已经重构了好几次了