[I.1] 个人作业：阅读和提问

前言

项目	内容
这个作业属于哪个课程	北航《软件工程》
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问
我在这个课程的目标是	完成一个团队开发项目并在实践中学习软件开发理论
这个作业在哪个具体方面帮助我实现目标	软件工程的理论（如何合作开发一个软件？），学习如何提问

阅读提问

注：以下内容基于第三版《构建之法：现代软件工程》第3版，人民邮电出版社，邹欣著
Q1：如果一名成员只是完成交付的分内任务，即所谓”游离于团队之外“，会给整个项目或合作者带来什么影响？

全力投入团队的活动：就像一些评审会议，代码复审，都要全力以赴地参加，而不是游离于团队之外。
《构建之法：现代软件工程》P51

Q2：在一次结对编程中，两人应该怎样尽快度过磨合期，提高效率？一个新组成的团队呢？有没有可能因为思路不合，或产生事故，而导致很难进行下去的情况，这时候该怎么解决矛盾呢？

两人合作的不同阶段与技巧：萌芽阶段、磨合阶段、规范阶段、创造阶段、解体阶段……
《构建之法：现代软件工程》P88

Q3：既然一位PM在软件团队中通常并不拥有行政权力，那么主要依靠什么来驱动团队达成目标？

PM 如果得到团队成员的支持，会是什么样的呢？
你将成为项目流程的主人——驱动流程，组织会议，实践Scurm，保证进度……
反之，如果得不到团队的支持，PM 会是什么样的呢？
你会在各种会议或流程中浪费大家的时间，发一些大家不读的“Status Mail”；不能凝聚团队，无法形成共识……
《构建之法：现代软件工程》P199

Q4：有些开发人员认为编写说明书是繁琐且低效的负担。一份高质量的说明书应当如何平衡“描述有效”与“保持更新”？

规格说明书分为以下两种
软件功能说明书（Functional Spec），主要用来说明软件的外部功能和用户的交互情况（把软件当成一个黑盒子）。
软件技术说明书（Technical Spec），又叫设计文档（Design DOc），主要用来说明软件内部的设计规范（把软件当成一个透明的箱子）。
《构建之法：现代软件工程》P223

Q5：在面临发布截稿日期的情况下，如何判断一个Bug“必须修复”还是“可以留待下个版本”？最好能结合现实中的例子来认识。

对于每一个 Bug，会诊小组要决定采取下面哪一种行动：
修复（Fix）。小组同一修复这一问题。
设计本来如此（As Designed）。用户或测试人员可能对功能有误解，或者功能的解释不完备。
不修复（Won't Fix）。这是一个问题，但是这个软件版本不打算修复。
推迟（Postpone）。如果我们的软件是真正解决用户问题的，是有价值的，那它一定会有下一个版本。
《构建之法：现代软件工程》P331

总结

软件工程是一门实践学科，所以我有一种深刻的体会：自己提出的每一个问题并不是都很有意义。有些问题之所以显空泛，与脱离实践有很大关系。它们固然是具有指导意义的先验理论，然而，在具体的实践中体会到的问题，才最具有一而再、再而三地求索的价值。