敏捷软件开发的原则

f10w

敏捷软件开发的原则
和传统重设计，重文档的软件过程相比，敏捷过程是一种轻型的开发过程，很适合小团队的开发。它重视发挥人的主观能动性，重视人的沟通交流，以人的作用把握不断变化的外部世界，推进软件开发。和人的作用相比，过程和技术是第二位的。敏捷软件开发的几条原则：
1．我们最高的优先级的工作是向用户初次和持续提供有价值的软件。 这是显而易见的，但是MIT Sloan Management Review 2001年对软件开发过程的一项分析发现的结果很有意思。分析报告指出，第一，初次发布的功能越少，最终发布的质量越好。第二，发布越频繁，最终发布的质量越高。
2．欢迎对改变需求，即使是在开发的后期。敏捷过程应该将改变转化成软件的竞争优势。其实，敏捷开发的这些原则就是用来应对改变。
3．频繁发布能工作的软件。一般几周发布一次，越短越好，功能有改变就可发布，但是要保证能工作。既然要做成一个软件，最终要发布，就是希望有人用的，所以经常会有人说软件以用为本，这样就是说软件很功利主义了，不管你使用的技术怎么样高明，做出来得东西不好用就不行，就比如一个人再怎么聪明没钱还是白搭。比如做一个CFD模块，可以先实现一个很简单的功能，但是非常的实用，保证有人会用，这个功能做好了，就可以发布第一个版本，可以给同事，学生使用，这样你会收到来自用户的反馈：可能有错误，用户说算出来不对？用法不对？采用的算法有问题？算法的实现问题？也可能需要新的功能等等。下面可以考虑改进方案，修改问题，增加新的功能。频繁发布能让开发者及早的发现问题，很多东西只有做了才知道问题在哪里，做之前讨论的那些远远不够。要让用户来帮我们。
4．客户和开发人员一起工作。这个有时候没法做到，也可以有个客户代表，他熟悉业务流程，可以作为开发者和客户之间共同的桥梁，经常性的沟通。一天不和客户沟通，一天的工作就有可能白干了：做出来的东西不是客户需要的，想当然是一犯再犯的错误。和客户在一起能保证项目不会偏离方向。
5．小组成员要有激情。要尽力给他们提供所需的资源，相信他们能完成工作。很显然了，没有激情能干好什么事情呢？薪水不够高当然也不就不会有激情了。当然，开发商业软件是这样的。但是，无论是商业的还是开源的，有一点还是很重要的，就是一个项目的远景，这个远景应该是让小组成员兴奋的，有成就感。如果你觉得自己做的东西没有什么价值，那么激情只能来自薪水了，这个项目的远景可能就是项目奖金。
6．小组内部，面对面的交谈时最有效的沟通方式，同步交流效率最高。讲和听同写和读比起来，效率当然高得多了，其次，通过文档，email这种异步的沟通还更容易引起曲解，面对面的时候，不明白的地方马上可以指出来。所以小组之间的交流不需要通过文档的方式。文档是在绝对不能省的时候才写的，比如要和外界接口，客户索要使用安装手册等等。设计文档是不用写的，实在说不清楚的时候画画uml图也是可以的，无论如何比文字要直观！面对面沟通效率高，其实代价也是高的，如果不是小组的内部的成员，很多时候大家不容易在一起，所以在一起的时候尽量多交流。
7．项目的进度用能工作软件来衡量。不是说我写完了设计的文档，我就完成了一半的进度，不是，如果一个客户要求的功能都没有实现，只能说完成了0%。
8．敏捷过程促进持久的开发，要保持一个一致的步调。不要把自己搞得太累，当然也不能松懈。疲劳影响软件质量，结果往往得不偿失。
9．要关注技术的发展，要采用良好的设计。不断的优化改良自己的代码，代码总是有改进的余地的，你只要对着代码看几分钟，你会发现你注视的那段代码可以改的更好，更加具有复用性，或者可以采用某个设计模式，等等。最起码的，把垃圾代码删除掉，已经注释掉的代码，不会编译到的代码，运行的时候不可能执行到的代码，统统是垃圾，要坚决删除。注释也是代码的一部分，很多时候代码更新了，注释没有更新，这样的注释不仅是垃圾，而且有毒。所以，要保持你的代码整洁，源代码有一段时间不整理就会发霉发臭，要经常整理，这点很重要，源代码是软件过程的最终产品。
10．简单原则---最大化不需要做的工作。我们的软件以满足需求为准，不把问题搞得很复杂，采用最简单的设计原则。举个非常简单的例子，写一个计算器，如果客户的需求只要两个操作数的‘+’运算，那么我就不去构造表达式分析的数据结构了。到客户要求‘+-*/（）’运算的时候，我再去修改代码。
11．小组是一个整体，成员之间的关系是平等的。小组成员在项目的所有方面共同合作，不是说某个人只负责架构，某些人只负责测试。有的成员可能对算法熟悉一些，那么在分工上，他可能多做一些这方面的工作，但是，不是说以后算法出了问题就是他的责任了，绝对不是，谁都可以去修改算法的代码，小组成员共享所有的代码。结对编程能让成员熟悉整个系统，测试驱动开发能保证这种修改不会出问题。这是敏捷开发很推崇的实践。
12．每过一段时间，小组需要反思前面工作的得失，改进效率。
由上述这些原则，敏捷过程有一系列很好的实践：客户参与，简单设计，测试驱动，结对编程，代码共享，持续集成，重构等等。
主要内容来自《敏捷软件开发》一书，加入一些个人体会，有一些开发经验的人可能会有共同的感受，这些东西都是从很多项目的失败教训中总结出来的，共同学习。

赵玉心

谢谢，我们所做的工作刚刚开始，您看有什么更为适合我们的思路呢？
我现在正在做网格，并且是以CGNS为基础的，希望能够很快做出界面实现通用化。

f10w

我觉得对于几个人组成的开发小组,上面的原则都是可以借鉴的,我说过了很多问题只有经过了才知道问题在哪里,这些原则也是一样的,这里是个学习的过程,没法超越,但是有意识的借鉴还是有好处的.
我对cgns不太了解,哪里有这方面的资料? 所以我也只能介绍一些原则,如果你能介绍一下你们这个项目的背景,我可能会有点技术层面上的建议.当然,作软件首先是功能上的考虑,这是最重要的,这些你们比较清楚.