标签：
构建之法第三次阅读笔记
这次读了构建之法的第五六章，对于五六章讲的内容，让我深有感触。在第五章中书中讲到了团队与流程。先给出了团队与非团队的特点，团队的特点是所有人都有一致的集体目标，集体要共同完成此任务，不一定要同时工作，但一定互相依赖合作，共同完成任务。
对于一个团队，有自己不同的模式，适用于不同的人员和需求。不管是什么模式的，但主要是一群人共同做软件开发，我们在开发，运营，维护软件的过程中，有许多的技术，做法，习惯和思想。但是我觉到这些模式当中最好的还是那个子瀑布模式，在这种模式下，要把各个子系统统一到最后做一个系统模式，另外这种模式只有到最后用户才能看到结果，但是用户等不起。由于各种模式都有自己的缺陷，因此在瀑布模型的各种形式都有一个共同点，比较注重计划，重事先设计，重文档表达。
要完成不同的任务，就要理解目前用户的业务流程，但是精通计算机语言的工程师并不能马上理解用户的活动和期望值的各种自然语言描述，为了解决这个问题，业务建模流主要用于分析和设计，初始阶段以此阶段的目标是分析软件系统大概的构成，工作流的目的，主要对于一个未成熟的团队来说，只能靠外力来驱动，不断地改进，直到让用户满意。
再看看第六章，对于第六章的内容，主要讲了敏捷开发，敏捷这个词我还真没有懂她的意思是什么，对于敏捷的流程，尽早完成并交付有价值的作品交付于用户，敏捷流程欢迎需求的变化，并利用这种形式来来提高用户的竞争优势，在敏捷开发的过程中，一般会有敏捷流程图，主要有MSDN的敏捷流程图，燃尽图，看版图，在解决敏捷流程的问题时，都要把美妙的理论变为现实，就是在要知道昨天我做了啥，今天我要做啥，在做的过程中遇到了什么问题，每天这样进行，将自己团队的目标一步步实现，对于衡量一个软件工程团队的质量问题，必须要自我管理，自我组织，多功能型，敏捷流程的经验教训 ，敏捷的用户范围，主要是用户可以随时向团队提供需求帮助，用户反馈BUG，这些问题都要一步步解决，在这里作者很形象的运用了便衣警察这个例子，敏捷不是万能的敏捷的方法能帮助你，敏捷的方法能帮助你更早的完成任务，仅此而已，敏捷的方法让你更清楚地看出看到用户项目的信息，让你尽早的知道用户的部分从价值。敏捷虽然说比较好，然而人的认识总是在一步步进步，软件工程界也时常有不同的思想出现，但是更多的是让用户看到了部分系统，或者让人神清气爽，或者让人比较迷惑，总之敏捷开发对于现在的软件工程来说无疑于最好的方式。
标签：
原文地址：http://www.cnblogs.com/lipengpengpeng/p/5469860.html
