这是一篇偏重于介绍方法学（特别是Agile方法）实践的文章。其读者对象是那些希望在自己的软件团体中引入某个过程方法，但又不知从何入手的开发人员、项目经理们。本文中所提到的内容更适合于应用在小型的软件团队中。对于较大规模的软件团队，本文中的部分内容也适用。 本系列包括：知识接力、代码是最终目、一致性的思考、活跃和混乱、严谨和死板、短期利益和长期利益的权衡。
软件管理和软件开发是截然区分的吗？
对于项目经理来说，其职责是软件项目的管理，而对于架构师、编码人员来说，其职责是软件设计和开发。虽然在一些小型的团队中，这两种职责有时候是同一个人担任的，但两种角色的区分是必要的。从事过软件开发的人都能或多或少的感受到软件管理和软件开发之间客观存在的沟壑。
我常常听到来自两个方面的声音。一边抱怨说设计师、编程人员阳奉阴违，难以管束，导致已订立的软件过程形同虚设。另一边抱怨软件过程存在诸多不恰当的地方，变成了软件开发的绊脚石。
现代的方法学理论以及相应的过程实践为我们奠定了软件开发科学管理的基础，个中的翘楚包括RUP和XP，纵观这些方法、过程，都非常强调过程的流畅、生命周期的延续。而在实际的应用中，我们却常常能够看见对它们的不恰当的理解，不正确的使用。尤其是那些希望在自己的软件团体中引入新型的方法过程新手们。对于他们来说，最容易犯的一个错误就是忽视了如何利用一个软件过程来创造一个成功的软件。
关于如何建立一个软件过程的资料很多，但是这些资料并没有把为什么需要过程，过程的目的是什么之类的问题说清楚。而这些资料的读者们，往往需要花费大量的时间，亲自进行实践之后，才能获得这些问题的答案，而付出的代价是教训和挫折。同样的，我和我的伙伴们也经历了这样一个过程。因此，我希望把我在过程应用、过程改造中涉及到的问题例举出来（采用过程模式的方式）。如果大家能够利用到这些经验（哪怕是一些），那本文的目的也就达到了。因此，本文并不是一篇专门讨论如何建立过程的文章，也没有涉及建模、设计、编码等方面的内容。但是本文中所讨论的内容都可以对以上的活动起到部分的指导作用。
文章来源于领测软件测试网 https://www.ltesting.net/
