读《移山之道》&《现代软件工程讲义》 —— Ever

这是我们软件工程的个人阅读作业，然后我就把邹欣老师的《移山之道》和《现代软件工程讲义》读了，还是有些体会的，这里说一下。作为大学生，没有真正的软件工程实践，必有目光短浅，言语欠缺之处。。

我主要想说敏捷这一部分，还有一些关于团队角色的问题

敏捷

先说敏捷，英文是aglie，是一种现在十分流行的开发模式。敏捷开发的价值观和之前的软件工程的价值观不同，如下：

Individuals and interactions over processes and tools
个人和交互 重于 过程和工具

Working software over comprehensive documentation
可用的软件 重于 完备的文档

Customer collaboration over contract negotiation
和客户协作重于 合同谈判

Responding to change over following a plan
响应变化 重于 遵循计划

从其价值观可以看出，敏捷开发强调变化和交流重于计划和工具。这并非是否认计划的重要性，而是敏捷更关注于前者，认为在开发过程中的变化对于软件最终质量的影响，要大于项目起始阶段就定下的各种条条框框；认为开发者之间的交流商讨，比单纯的依靠优秀的工具更能提升软件产品的质量。

那么，如果一个软件决定采用敏捷的开发模式，是不是就要完全地遵循敏捷的步子呢？这里，邹欣老师在讲义中讲到了两种敏捷，其一是We follow an agile process，另一是We follow the Agile process。前者的意思是团队比较灵活，而后者则是完全遵照敏捷的“章程”去行事。显然，后者应该被舍弃，正如敏捷一词的本意，灵活而快速，如果完全地遵照一个“章程”，何谈灵活和快速？重在本质而非表象，不仅仅是在敏捷这里如此，在其他地方有何尝不是如此。

说了这么多，敏捷的特点在哪里？我以为，其最大的特点就是快速的迭代以及对于改变的包容性。在多次的迭代过程中，不断修正问题，解决问题，应对变化，从而逐渐产生了一个优质量的软件产品。

什么样的团队可以使用敏捷模式呢？从《移山之道》和《现代软件工程讲义》中，以及自己的一些看法，我认为，团队人数不多，成员之间相互熟悉、配合默契，技术上无大困难，成员负责任，成员了解敏捷的精髓等。

敏捷是万能的吗？显然不是，而且显然，对于软件工程而言，不会出现silver bullet，任何方法都会有其长处和短板。这一点邹欣老师已经在他的博客中阐述了。在这里，我有一个问题，这同时也是在邹欣老师的博客评论中，争议最多一个问题——敏捷是否意味着可靠性低？“不高，容忍经常出错”是博客中邹欣老师对于敏捷的一个看法，但是显然下面的一堆评论对于这一点有很大的异议。还有就是，其应用范围是什么？什么样的工程绝对不能使用敏捷的方法，而什么样的工程最适合于敏捷的方法？

对于敏捷，还有不少人对于其本身的理念就提出了质疑，比如@左耳朵耗子陈皓老师，自称敏捷开发恐怖分子，他的一些文章比如《多些时间能少写些代码》写出了一些他的看法。

角色

我这里说的就是PM、Dev和Test。在这里，我只是有几个问题，希望能得到解答，至于体会，因为自己没有经验，单纯的靠读，说出的东西可能也只是一些没有营养的东西。。

关于PM：负责沟通协调，掌握项目进度，PM的好坏对于软件的质量有重要的影响。

关于Dev：团队中最重要的一群人，在一个无老板的团队中，Dev应该是有权拍板的人（猪、鸡、鹦鹉中的猪）。负责代码编写，并对自己的代码进行单元测试，尽量不出Bug。

关于Test：负责找出项目中的Bug。现在，我有个问题，在我们当前的项目中，六个人，如果只有一个Test，那么这个Test是不是应该对项目的整体都应有一个比较清楚的认识？正常Test按理说应该负责模块测试和集成测试，但是我们的项目的各个模块是不能集成在一起的（做后端的各个功能，不做界面），这是应该怎么去做集成测试，还是说不做了？

就到这里了。