这学期，我们分了方向，专业方向。也许向老师说的那样学习好的选了计科，我大概属于学习差的吧。高中的紧绷让我到了大学不知道该干嘛了，荒废了整个大一，到现在还不知道自己读了大学学会了干什么。现在我要追赶了，毕竟差的不是一点半点。分了方向，有了任务，也大概自导自己该干嘛了。开始感觉还是挺无从下手的，不过信心还是有的。也算亡羊补牢吧。
这俩星期自己抽空看了看这本构建之法。粗略明白了点要想开发一个堪称完美的软件是十分困难的。需要大量人力时间。软件等于程序加软件工程，软件开发的阶段不同,我们所需要的标准花费的功夫都大大不同。而我们的软件工程是把系统的有序的可量化的方法都应用到软件的开发、运营和维护的过程上。软件工程包括下面这些领域：软件需求分析、软件设计、软件构建、软件测试和软件维护。我们的目标便是创造出足够好的软件来适应用户的各种需求。没有缺陷即没有bug，何为bug，软件的行为和用户的期望值不一样就叫bug。要想开发好的软件，必须要了解用户的期望功能，需求分析。而且软件还是很特殊的，和以往的传统工程还是有云泥之差的。它很复杂、不可见、易变、服从、非连续性。种种性质决定了软件工程与传统工程的大大不同。
开发出一个完备的软件是十分依赖一个分工明确，团结合作紧密的team。团队的模式有很多种。蜂窝模式、主治医师模式、明星模式、社区模式、业余剧团模式、秘密团队、特工团队、交响乐模式、爵士乐模式、功能团队模式、官僚模式等等。这么多的团队模式，各自有个自适应的地方。每个都有长短，适合自己的才是最好的。同样，开发流程也有模式的应用。如改了再写模式和瀑布模式。根据瀑布模式延伸出了回溯的方法，业提出了文档的重要性。一步步完善瀑布模型。而更高级的的统一 流程。rup把软件开发的各个阶段整合在一个统一的框架里。要完成一个发咋的软件项目，团队的各个成员就要在不同的阶段完成不同的事情，这些在rup中叫做规程或者工作流。如下：业务建模、需求、分析和设计、实现、测试、部署、配置和变更管理、项目管理、环境。rup还有四个阶段：初始阶段、细化阶段、构造阶段、交付阶段。这四个阶段从软件系统的大概构成，软件可行分析到编程测试。都一步一步走过。而在中国的一些企业中，不少开发流程是由行政领导主导，公司老板驱动的。这种模式也不是没道理。他更加了解市场需求，软件的功能由他们确定。当然这个模式也有缺点。现在在1996年由steve提出的渐进交付的流程，MVP和MBP。大抵是在开发、发布、听取反馈做改进不断的循环了。MVP为最小可行产品，又称最小功能集。是把产品最核心的功能用最小的成本实现出来，然后快速征求用户意见。MVP的指导思想和渐进交付相似，他更早的强调获得用户反馈，也强调产品的核心价值。和它相对应的是MBP最强最美产品。如果对用户的需求了然于心，或者产品团队比用户更了解用户的需求，就要把产品最全面、最美的形态展现出来。
但是一个团队的完美配合毕竟太难，每个人都有每个人的特点风格，俗话说江山易改本性难移嘛。每个人的长处也不同，所以我们应该对症下药充分利用不同的长处和谐发展。对于团队的管理也十分重要。这里就要说到绩效管理了。其实在软件工程中的绩效管理很麻烦，众说纷纭。研究来研究去还是看团队的贡献度吧。评判标准还是整个团队中分析。团队合作实属不易。我们也分为几个阶段，萌芽阶段、磨合阶段、规范阶段、创造阶段。一个团队从对个人的定位模糊，做事不严谨慢慢转变相互配合相得益彰。最终爆发很强的凝聚力、创造力。这才是一个成熟的团队。人人各司其职，有条不紊。而我们团队的效能曲线也是一个先减后增的曲线随着团队效率的提高继而团队的影响力也会增加。我们最终都会成长，至于那些软件工程师，没个人都该明白自己的定位，清楚地把自己的职业道德谨记在心。