个人阅读作业3
以前的博客：
以下是我之前问题的博客地址：
请说明哪些问题现在自己已经清楚了，请阐明一下，是如何通过看书，实践，或者讨论弄清楚的
真的敏捷应该是一种理念。核心在于关注用户的需求与实际，核心在于应对现在快速变化的市场。敏捷的典型应用场景确实就是应该在那些用户不需要100%的可靠性但是可能会经常改变需求，需要尽快拿出解决方案的地方。敏捷开发需要很多轮的迭代。我觉得文中有一点说的很好。敏捷开发的手段可以帮助我们确定在规定的时间内到底能不能完成要求。因为敏捷的原则就是我们每次都尽快做出一个可发布的版本，然后通过与用户的交流和反馈，我们就可以知道某些功能是不是已经做到了要求，那么我们就可以不在那些功能上再花费时间（以后的几轮迭代中可以继续）；我们也可以知道哪些功能用户已经不需要了，那么当然，我们也不用再花费时间去做了。这样，实际上，去掉了以前形式化开发方法的桎梏。显得更加灵活，当然，这就是敏捷的意义。
哪些问题还不明白，请分析
l 说了这么多，敏捷的特点在哪里？
我以为，其最大的特点就是快速的迭代以及对于改变的包容性。在多次的迭代过程中，不断修正问题，解决问题，应对变化，从而逐渐产生了一个优质量的软件产品。
l 什么样的团队可以使用敏捷模式呢？
从《移山之道》和《现代软件工程讲义》中，以及自己的一些看法，我认为，团队人数不多，成员之间相互熟悉、配合默契，技术上无大困难，成员负责任，成员了解敏捷的精髓等。
产生了哪些新的问题，请提出
l 敏捷是否意味着可靠性低？“不高，容忍经常出错”是博客中邹欣老师对于敏捷的一个看法，但是显然下面的一堆评论对于这一点有很大的异议。还有就是，其应用范围是什么？什么样的工程绝对不能使用敏捷的方法，而什么样的工程最适合于敏捷的方法？
l 在我们当前的项目中，六个人，如果只有一个Test，那么这个Test是不是应该对项目的整体都应有一个比较清楚的认识？正常Test按理说应该负责模块测试和集成测试，但是我们的项目的各个模块是不能集成在一起的（做后端的各个功能，不做界面），这是应该怎么去做集成测试，还是说不做了？
同时我们还读了8篇软件工程相关的论文或博客，你回头再看看这些文章，有没有新的体会
l 第三篇：Big Ball Of Mud
人们常讨论高级架构，但实际上很多软件的架构是“大泥球”。有些架构很随意。而且很多经典的软件架构也很平庸。文章主要讨论了为何会出现这一问题以及解决之道。
简单的一次性程序会产生大泥球。需求的变更和零碎的增长也会使设计良好的架构肢解成大泥球。这在我实现编译课程设计时深有体会。
最开始我编写的词法分析程序可读性很好，逻辑清晰，即使有bug也可以很快发现出错的地方。然而由于需求所致，程序的大部分都充斥着if else判断语句组成的控制流，并且模块性很不好。当发现一种没有考虑到的情况时，只好在最后面加上一个“定制”的if else语句来修复特定的bug，这样随着bug的一个一个修复，程序的可读性越来越差。到最后我甚至都不知道词法分析到底是怎么返回一个单词的了—活生生的“大泥球”。产生这泥球的原因，一是我认为自己设计的算法不够好，不能全面地覆盖到每一种情况，二就是这个函数本身需求也一定程度上的增加了“泥球”出现的可能性。
l 瀑布模型
我觉得瀑布型最大的特点是整个软件开发过程是按照流程一步步走下去的，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。并且文档在瀑布模型的开发过程中有重要的作用。这种开发模式最大的问题就是需求更改的成本太高。
| 你(用户) 提出要发动机, 车身, 车窗, 方向盘, 加速踏板, 刹车, 手刹, 座位, 车灯…
生产商按照瀑布模型流程给你设计, 生产, 六个月后交付。 看到样车后… 你提出– 我当初忘了一件小事, 要有倒车灯 § 当倒车的时候, 倒车灯会亮 生产商说: § 我要重新设计车尾部，加上倒车灯，把车底拆开，安装线路, 修改传动装置把倒车档和倒车灯联系起来。。。我得重新开始 你说: 这不是很小的一件事么? |
邹老师在现代软件工程讲义中讲软件开发的各种方法，提到了瀑布模型（在这里），并用制造汽车做例子说明了瀑布模型的最大问题：
我觉得在软件开发的过程中，可能瀑布模型并没有敏捷开发那么敏捷，但是它也有很多优点：
1）为项目提供了按阶段划分的检查点。
2）当前一阶段完成后，您只需要去关注后续阶段。
3）可在迭代模型中应用瀑布模型。
请问你们在项目的 需求/设计/实现/测试/发布/维护阶段（一共6 个阶段）中都学到了什么 “知识点”， 每个阶段只要说明一个知识点就可以。
l 需求：
如何使用NABCD模型进行需求分析
l 设计：
divide and conquer—首先学会如何divide
l 实现：
感触最深，体验了MSF基本准则，尤其是为了共同的目标工作，相互信任充分理解，对项目负责，其乐融融。
l 测试：
黑盒测试和白盒测试，要做到完整性、有效性、可理解性、清晰性
l 发布：
推广计划指定，预期目标设定
l 维护：
关注客户需求变化
