软件工程M1/M2总结

已经清楚的问题：

1. 什么是“没有银弹”论断？

      通过阅读Brooks最著名的这篇文章，我知道了在软件开发过程里是没有万能的终杀性武器的，只有各种方法综合运用，才是解决之道。而各种声称如何如何神奇的理论或方法，都不是能杀死“软件危机”这头人狼的银弹。在软件工程中，虽然各种高阶语言的使用有效地移除了次要复杂度的问题，但是软件本身的必要复杂度却无法被移除掉。就比如我们平常的作业，面向课程中的电梯调度，电梯的状态变化和各种属性都必须考虑和实现，如果参考现实生活中的一些实际例子，情况就变得更加复杂。总而言之，要得到一个理想的程序，必须考虑多方面的问题，多人合作开发一个复杂的软件时，因为每个人的想法各有不同，团队初期的磨合过程也很费劲。

 

2. 团队模式和项目的开发模式有什么关系，怎样选取效率最高最适合的模式？

• 大教堂模式（The Cathedral model）：源代码在软件发行后公开，但在软件的每个版本开发过程中是由一个专属的团队所控管的。作者以GNU Emacs及GCC这两软件为例。

• 市集模式（The Bazaar model）：源代码在开发过程中即在互联网上公开，供人检视及开发。作者以Linux核心的创始者林纳斯·托瓦兹带领Linux核心的开发为例，亦引用fetchmail的开发为例。

      此篇文章用“大教堂模式”来形容互联网世界里封闭的、集中式的开发模式（例如最典型的苹果公司的封闭模式），用“集市模式”形容互联网世界里并行的、动态的多人协同开发模式，从传统公司角度来看“大教堂模式”显然更能维护其自身的利益，但如果从软件开发和IT发展角度来看“集市模式”则是必行之道。

      经过我们小组的讨论，我认为，效率较高的做法是，将一个具有价值的集市转化为大教堂。也就是说，先将一个半成品公开，最后逐步完善形成最终的项目。在转化的过程中，需要许多因素的推动。初始项目可以是一个不完善的、具有许多缺陷的项目，但是它要有一个项目的雏形，也要具有能吸引投资和人才的价值。大教堂模式虽然品质一般来说较高，但是它所耗费的周期长，市集模式是人数的智慧的叠加，在这方面，市集模式具有更大的竞争潜力。

 

3. 结对编程的时候，合作伙伴的性格等因素对合作的影响。

      具体实践的时候，我认为合作伙伴最重要的性格因素是责任感和积极的态度。这两点对于我们的合作具有非常重要的作用。责任感证明他会按时提交所布置的任务，而积极的态度会影响整个团队的士气。

 

4. 敏捷开发或其他高级方法对于团队的要求，方式的选取的技巧。

      通过查阅资料，我对这个问题有了更加深入的了解。

主要的敏捷方法：

极限编程（ XP ）

　　极限编程（ XP ）的主要目的是降低需求变化的成本。它引入一系列优秀的软件开发方法，并将它们发挥到极致。比如，为了能及时得到用户的反馈， XP 要求客户代表每天都必须与开发团队在一起。同时， XP 要求所有的编程都采用结对编程（ pair-programming ）的方式。这种方式是传统的同行审查（ peer review ）的一种极端表现，或者可以说是它的替代方式。

过程：

　　 XP 定义了一套简单的开发流程，包括：编写用户案例，架构规范，实施规划，迭代计划，代码开发，单元测试，验收测试等等。

思想：

　　像所有其他敏捷方法一样， XP 预期并积极接受变化。

 

Scrum

　　 Scrum 是一个敏捷开发框架，它由一个开发过程，几种角色以及一套规范的实施方法组成。它可以被运用于软件开发，项目维护，也可以被用来作为一种管理敏捷项目的框架。

　　在 Scrum 中，产品需求被定义为产品需求积压（ product backlogs ）。产品需求积压可以是用户案例，独立的功能描述，技术要求等。所有的产品需求积压都是从一个简单的想法开始，并逐步被细化，直到可以被开发。

过程：

　　 Scrum 将开发过程分为多个 Sprint 周期， Sprint 代表一个 2-4 周的开发周期。每个 Sprint 有固定的时间长度。首先，产品需求被分成不同的产品需求积压条目。然后，在 Sprint 计划会议（ Sprint planning meeting ）上，最重要或者是最具价值的产品需求积压被首先安排到下一个 Sprint 周期中。同时，在 Sprint 计划会上，将会对所有已经分配到 Sprint 周期中的产品需求积压进行估计，并对每个条目进行设计和任务分配。在 Sprint 周期过程中，这些计划的产品需求积压都会被实现并且被充分测试。每天，开发团队都会进行一次简短的 Scrum 会议（ Daily Scrum Meeting ）。会议上，每个团队成员需要汇报各自的进展情况，同时提出目前遇到的各种障碍。每个 Sprint 周期结束后，都会有一个可以被使用的系统交付给客户，同时进行 Sprint 审查会议（ Sprint review meeting ）。审查会上，开发团队将会向客户或最终用户演示新的系统功能。同时，客户会提出意见以及一些需求变化。这些可以以新的产品需求积压的形式保留下来，并在随后的 Sprint 周期中得以实现。 Sprint 回顾会随后会总结上次 Sprint 周期中有哪些不足需要改进，以及有哪些值得肯定的方面。最后整个过程将从头开始，开始一个新的 Sprint 计划会议。

角色：

Scrum 定义了 4 种主要的角色：

Ø       产品拥有者（ Product Owner ）：该角色负责产品的远景规划，平衡所有利益相关者（ stakeholder ）的利益，同时确定产品需求积压的优先级等。它是开发团队和客户或最终用户之间的联络点。

Ø       利益相关者（ Stakeholder ）：该角色与产品之间有直接的利益关系，通常也是由客户或最终用户代表组成。他们负责收集编写产品需求，审查项目成果等。

Ø       Scrum 专家（ Scrum Master ）： Scrum 专家负责指导开发团队进行 Scrum 开发与实践。它是开发团队与产品拥有者之间交流的联络点。

Ø       团队成员（ Team Member ）：即为项目做实际开发工作的开发人员。

　　 Scrum 提供一个敏捷开发框架，其他许多敏捷方法都可以被集成到 Scrum 中。比如测试驱动开发（ test-driven development ）和结对编程（ pair programming ）等都可以被整合到 Scrum 中。

 

精益开发（ Lean Development ）

　　精益软件开发模式是从丰田公司的产品系统开发方法中演化而来。它主要包括两个部分：一部分是核心思想及原则，另外一部分由一些在相应的工具构成。

　　精益开发的核心思想是查明和消除浪费。在软件开发过程中，错误（ bugs ），没用的功能，等待以及其他任何对实现结果没有益处的东西都是浪费。浪费及其源头必须被分析查明，然后设法制止。

　　精益软件更重要的是不断完善开发过程的一种思维方式。因此，将精益模式与其他敏捷开发模式一起使用将会取得很好的效果。

 

如何选择一种敏捷方法：

　　选择一种合适的方法取决于多种因素。在做出决定之前，我们需要充分考虑以下这些方面：

Ø       方法的复杂度。确保团队或组织能够应付这种复杂度。

Ø       社区支持。流行的方法可能并不是你最理想的选择，但流行的方法至少有较多的社区及行业支持，可以使你受益匪浅。

Ø       实用工具。选择一种可以为你提供许多支持工具的方法。一个良好的自动化工具可以帮助团队有效的处理日常工作，促进团队协作，并减少管理成本。

Ø       你目前的开发方式和你目前团队关于敏捷方法的认识程度。选择一些与你当前开发方式比较接近的敏捷方法将有助于推动该方法的实施。

Ø       你的团队规模。较小规模的团队最好从简单的方式入手。当然，这并不意味着你必须选择那些本身就比较简单的方法如 Crystal Clear 。你可以选择一些相对比较全面的方法，但从简单入手。当你的团队规模逐渐扩大，再增加相应的细节。

Ø       你不需要只遵从一种方法。你可以为团队选择一个主要的方法（如 Scrum ），然后从其他方法中借鉴对你的团队或组织有所帮助的其他方式加以整合。

敏捷总是在不断发展演变，因此，没有一个人能保证目前的敏捷方法都是正确的。每个采用敏捷开发的团队都可以通过发现并形成自己的想法和最佳实践，对敏捷开发做出自己的贡献。

 

仍有疑问的问题

      我们对于Scurm meeting的演示流程，比较流于形式化，我今天做了什么？明天准备做什么？有什么问题……所以仍然希望能够知道有没有更加高效、科学的开会方式。

 

新的问题

      1、关于代码风格，每个人有不同的风格，如何能够更好地将它们整合到一起？是否要在项目初期要求一个统一的代码规范？

      2、在团队协作的过程中，通过一个什么样的机制才能调动大家的积极性？

      3、怎样才能让项目组的每一名成员都找到适合自己的工作岗位，使他能发挥他的最大价值？项目分工按照什么依据才能更加科学？

 

关于8篇软件工程相关的论文或博客的新体会

      软件工程包括三个要素：方法、工具和过程。

      关于软件工程，关于团队合作，在以上许多种疑问的解答中，永远逃不开方法的选取和规则的定义。如同Linux和苹果系统，它们的开发模式完全不同，然而最终结果却殊途同 归，不是所有的“好”方法都适合自己，也就是说，选择一个“适合”的方法才会对项目有很大助力。同时，管理也是非常重要的一个环节，好的管理团队的方式在某种意义上来说也是统筹全局的一个表现。

      成事在人，团队的氛围很重要，一个好的PM也很重要，因为课业太多经常性地会忘记一些deadline，这个时候PM就起到了监督和提振士气的作用，感激。

 

在项目的 需求/设计/实现/测试/发布/维护 阶段中都学到了什么 “知识点”

Ø       需求：NABCD模型需求分析方法 

Ø       设计：从功能需求抽象成图形建模，循序渐进

Ø       实现：敏捷编程、大教堂与市集开发模式

Ø       测试：黑箱和白箱

Ø       发布：尽量在更多的平台上发布软件，收取更多的用户反馈

Ø       维护：结构化维护，从设计文档开始着手修改与复审

 

博客链接：

http://www.cnblogs.com/yuccalan/p/4826577.html