我对敏捷价值观和原则的理解 --待续

敏捷的价值观如下：

 　　个体和交互 胜过 过程和工具
 　　可以工作的软件 胜过 面面俱到的文档
 　　客户合作 胜过 合同谈判
 　　响应变化 胜过 遵循计划

很多人在不理解敏捷的情况下，简单的从字面去曲解和批驳敏捷。我就从我的敏捷实践出发谈谈我的感想。

1、“个体和交互胜过过程和工具”。

我认为这条主要是针对流程和管理上的观念。过程和工具是很重要的，但是不能以为有了工具和流程就能无往不胜，而忽略了对执行流程和使用工具的主体——人的关注。德鲁克早就指出，对知识型员工的管理，不能简单的和生产线上的工人一样对待，而是需要其自我管理。这就需要知识型员工在工作过程中积极的和其他人之间交互，而不是照章办事、机械执行。只有充分的交流才能掌握需求，才能彼此配合，才能开发出优秀的软件。敏捷不排斥工具，在敏捷过程中，工具往往具有极其重要的作用，比如CI和TDD对工具就非常依赖。
2、“可以工作的软件 胜过 面面俱到的文档”
敏捷从来都没有说不要文档，注意定语。我的理解是不要追求面面俱到的文档，最终的目标应该是可以工作的软件。文档可以分成两部分，需要提供给客户的和内部开发需要的。对于提供给客户的文档，这是交付的一部分，必须要有的，大家应该没有异议（这是资料部门的工作）。而对于内部的文档，必要的文档还是必须的，具体需要什么文档应有开发团队来决定（例如接口文档、规格书等）。从价值的角度分析的话，最终产生价值的是可以工作的软件，工作的中心和焦点一定要是它。对于客户不产生价值的工作都是对资源的浪费。
3、“客户合作胜过合同谈判”
现在的社会节奏很快，软件需求的变化也很快（有时是因为客户的需求是逐步明晰的）。如果用合同来约束客户，往往是双输的结果；客户没有得到实际需要的，开发团队按照合同办事没有问题，但失去了未来的客户，劳动没有产生价值，没有成功感。只有拥抱客户需求的变化才能得到双赢，当然合同也要根据实际情况来调整（这是前提）。实际情况是：这一点可操作性太差，除非是内部客户否则外部客户很难参与到项目开发。比较普遍的做法是把Marketing、SE作为项目的客户代表，或者邀请客户参与你的Sprint Demo。
4、“响应变化胜过遵循计划”
世界上永恒不变的恐怕就是变化了，想靠制定计划来完成软件开发太难了（软件开发已经达到了非常复杂的程度，制定详细计划非常困难，当然生产线上的计划可能比较简单、准确）。与其耗费大量人力物力去制定一个并不可信的计划，还不如随时根据变化做出相应的响应。当然初期会制定一个初略的计划，然后根据实际情况去不断的调整和变化。完全按照作战计划去指挥的将军一定会失败，所以才会有“将在外君命有所不受”，才会有与时俱进。

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

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

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

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

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

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

 　　在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。

 　　工作的软件是首要的进度度量标准。

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

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

 　　简单,使未完成的工作最大化的艺术,是根本的。

 　　最好的构架、需求和设计出自于自组织的团队。

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

参考文章 转自:http://webservices.ctocio.com.cn/comment/340/7731840_2.shtml

转载于:https://www.cnblogs.com/li_lzw/archive/2009/07/18/1526284.html