敏捷软件开发笔记（一）------敏捷实践

敏捷开发宣言

谈及敏捷开发不得不提到敏捷开发宣言，主要是四点：

• 个体和交互 胜过 过程和工具
• 可以工作的软件 胜过 面面俱到的文档
• 客户合作 胜过 合同谈判
• 响应变化 胜过 遵循计划
  在《敏捷软件开发：原则、模式与实践》的第一章中所提到的那句诗：“教堂尖顶上的风标，即使由钢铁制成，如果不懂得顺应风势的艺术，一样会被暴风立即摧毁。”这是由德国诗人海涅所写的诗，用在软件开发上也照样适用。“暴风”就如现在项目所面临的巨量的需求，而“风标”就如项目的响应能力，如果不能够做出快速响应，就会被巨量的需求所压垮。

敏捷开发宣言中提到的四点就是针对这种现实需求所提出的更好的软件开发方法，是顺应现代发展的一种必然趋势。

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

工具就是为了团队的效率提升而存在的。而一味的追求工具放弃了团队之间的交互，就是本末倒置的行为。工具应该是在发现它无法适用的时候才去更换它。一切工具都应该先从最简单的小工具开始，从轻量化开始，而不是重量级工具。工具的增多也大大增加了团队成员的学习成本。另外，我认为最好的沟通方式就是面对面的沟通，就好比现在的微信，确实是很好的实时通讯工具，但是人的表情，语气，手势等都是传递不了的，这些在沟通时都会造成误解。
团队成员之间的沟通也极其重要，所谓“三个臭皮匠抵得过一个诸葛亮”。一个优秀的团队成员未必就是一个一流的程序员。良好的沟通，能够引导团队集思广益，积极碰撞出灵感的火花。近来在工作中，也体会很深，一个程序员必定是考虑不全所有的异常情况的，如果能够多个开发人员同时去思考异常情况，必定会考虑的更全面。

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

这一点其实是很明显的。过多的文档会造成文档维护起来非常麻烦，不能保证文档的版本与软件版本一致。对于团队来说，维护一份短小而且主题突出的文档是至关重要的。就如平时开发过程中，代码简洁，注释短小一样，文档也是要做到这一点。
人与人之间的交互是把系统的脉络图传授给他人最快，最有效的方式。代码是唯一没有二义性的信息源，代码真实表达了它所做的事情。

客户合作胜过合同谈判

成功的项目需要有序，频繁的客户反馈。在合同中所提出的需求一方面可能会不切实际，一方面可能在开发过程中会发生变化，不能顺应市场变化，所以死板地遵循合同中的计划，不如灵活多变的在开发过程中进行反馈。客户最好是和开发团队密切地在一起工作，很多开发中出现的问题能够快速反映出来，另外开发团队也能够清楚验收测试的细节。另外，客户和开发团队之间真诚的合作，也减少了无理的或者不切实际的需求提出。

响应变化胜过遵循计划

在上一份工作中，我任职于一家银行，使用的是传统的开发模式，规定了计划无论如何都要完成。每次产品经理说“我不管，这星期我就要结果，不管你怎么实现”，如此死板的要求必定会造成软件质量的崩坏，带来的是大量的修补还有潜在的隐患。
初定计划时，不能定得太远，没人能想到后面会发生什么，市场环境在不断变化中，这也会引起需求的变动。
在施行计划时，也不能死板地去根据计划的日期来决定，可能会出现人力的减少，造成项目的延期。
比较好的计划就是：下两周做详细的计划，下三个月做粗略的计划，再之后做极为粗糙的计划。根据距离当前时间点的由近到远，计划也逐渐模糊。这才是科学的计划方式。
将精力放在当前迫切解决的需求上，而且由于仅仅只是详细制定几周的计划，不会耗费太多的精力，另外也给后续计划留下灵活改变的空间。