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

项目	内容
这个作业属于哪个课程	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2025_LR/
这个作业的要求在哪里	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2025_LR/homework/13365
我在这个课程的目标是	在实践中学习软件工程的理论和思想
这个作业在哪个具体方面帮助我实现目标	了解了软件工程的多种理论

问题一：软件bug的界定标准

一、问题产生

• 原文：第一章 P17

是虫子（Bug），还是肉芽？不同的人有不同的答案。软件行业也有一句著名的笑话：这不是缺陷，这是一个功能（It＇s not a bug，it＇s a feature）！很多人认为有Bug就是质量不合格，没有Bug就是质量完美，其实这也未必。

……为什么还有人买那些质量“不够好”的汽车呢？对于某些顾客来说，某一类的汽车满足了他们的需求，他们就会买。

书中这一部分讨论了bug和feature的辩证关系，通过汽车质量的类比，指出软件质量未必完全由是否存在bug决定，而是由用户的需求决定。然而，我对此产生了以下的问题：

1. 软件工程中，是否存在客观的bug判定标准？
2. 在判定标准的基础上，如果存在用户（比如将功能认为是bug）与开发者认知产生冲突，又该如何界定bug？

二、调研

查阅资料后，我发现以下bug定义：

1. 当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误
2. 当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误

一般是指不满足用户需求的则可以认为是bug，狭义指软件程序的漏洞或缺陷，广义指测试工程师或用户提出的软件可改进的细节、或与需求文档存在差异的功能实现等

总结来说，可以认为：软件缺陷的客观标准源于基线需求文档（BRD）与功能规格说明书（FSD）。IEEE 610.12标准将缺陷定义为"与预期需求相偏离的系统行为"，这意味着：用户最终掌握缺陷的定义权。

三、新的困惑

然而，这种解释使我产生了新的困惑：

• 用户需求是流动的、主观的，开发和测试人员难以在开发过程中充分把握用户需求来界定bug，那么真正客观的标准存在吗？应该如何制定？
• 开发者需要在何种程度上，为了用户需求对软件进行迭代？客户即上帝的观念适用于软件工程吗？

问题二：构造燃尽图时如何估算工作量

一、问题产生

书中P113提出，列出任务数目的燃尽图无法展现项目的拖延情况，引入了以时间为度量的燃尽图。

​ 再说说燃尽图。有些燃尽图只是列出了任务的数目，这种图无法展现项目的拖延情况，一个任务有大有小，它们在图表中都是一个点，一个16小时的任务需要3天完成。一个2小时的任务出于种种原因也花了3天时间，它们在图表中的表现是一样的。在实践中，我个人认为以时间为度量的燃尽图更有效果。
​ 下面是一个实际项目的燃尽图，有三个每天跟踪的时间值：

• 实际剩余时间（Remaining Hour）:每个团队成员所有任务的剩余时间的总和。
• 预估剩余时间（Projected Remaining Hour）:根据每个人每天的理论进度推算的剩余时间。
• 实际花费时间（Completed Hour）:实际花费的时间。

这看起来很美妙，但是当我设想真实投入使用的时候产生了以下问题：

• 如何预估实际剩余时间？如何推算预估剩余时间？

二、调研与解决

查找资料后，我发现现在制作燃尽图和进行敏捷估算的主流方法是使用故事点，并且为了有效识别差异，使用修正后的斐波那契数列来估算故事点，即1、2、3、5、8、13、20、40、100、∞。

使用故事点首先需要确定基准故事线，Pingcode马小河在知乎回答中提到可以尝试使用1人天的工作量作为一个故事点。（Pingcode是一款可以用于Scrum团队的在线协作软件）

对于初次实施敏捷的团队，对故事点的评估可能还是不太容易理解，根据我的实践经验，初次评估故事点时，可以尝试使用1人天的工作量作为一个故事点。如果团队成员的水平参差不齐的话，那就建议用其中一个中等水平的研发作参考，使用他的1人天的研发产出作为1故事点的参考。——Pingcode马小河的知乎回答

与此同时，需要综合考虑工作量、复杂度和不确定性来敲定故事点的具体数目；通常情况下，会在小组会议上用估算扑克进行匿名投票，来保证大家对一项工作的故事点达成共识。

这样问题就迎刃而解了。

问题三：实战中软件工程的冲突解决方案

一、问题产生

• 原文：第七章P133

  问:如果我要做一件事情，但是周围的人有不少不同意见，短时间又不能完全说服他们，
  怎么办？
  答:对此事负责任的角色要自己拿主意。

• 原文：第七章P141

  问:那有冲突怎么办？
  答：那就吵呗。各个角色的利益是有一定冲突的，MSF没有掩饰这一点。MSF团队模型的核心是，成功的技术项目必须符合各种利益相关人（Stake holder）完全不同且常常对立的质量观点。

关于实战中的软件工程，书中给出了微软的MSF团队模型：MSF模型支持开发中的不同角色，为自己职责内的部分各自负责人；在发生冲突时，通过争吵来达到平衡。

这听起来实在太恐怖了！！！在各自负责的情况下，很容易设想：大家都会优先保证自己的部分不出错，而很难优先考虑项目整体的质量，在这种情况下如何推进项目是一个很艰难的问题；同时，争吵的结果并不必然带来解决方案或者平衡，而有可能是僵持。书中并没有就这一点展开论述，但是在现实中这简直是天大的问题！

• 在软件工程实战中，存在比较成熟的冲突解决方案吗？

二、调研

查询资料时发现，软考中有一个知识点叫做冲突管理。某个博客中给出了软考冲突处理的五种策略：回避、妥协、适应和容忍、强迫、合作。除此之外，书中第十七章给出了一些方案：追求全体共识、投票、咨询、独裁、交换决定权。

但是这并没有解决我的问题TAT。

书中关于PM的章节中，似乎否定了“和事佬”形式解决问题的方式：

任何方法或文化都有优点和缺点，如果很多PM没有强烈的责任感和强大的推动力（参见“猪，鸡和鹦鹉”一节），而是满足于通过平等而反复的讨论折中得到团队的共识，一个可能的负面后果便是“委员会设计”（Designed by Committee），一些产品不能很快跟上市场变化，在用户体验方面，这么设计出来的东西大多中规中矩，了无新意。严重的话，甚至连“委员会”成员都会恨这样的设计。

• 那么，如果出现难以达成共识的问题，是“保持争吵直到达到全体共识”，还是“由类似组长orPM的角色独裁”，或者“投票”呢？

问题四：猪和鸡的辩证问题

• 原文：第十七章P393

  有些人是猪……对他们来说，要想项目成功，就要拿出自己身上的肉，背水一战……他们的投入级别是——全身心投入（Committed）。

  有些人是鸡……能做重要的贡献，但是项目一旦失败，他们的损失并不大……他们的投入级别是——参与（Involved）。
  有些人是鹦鹉……能提出很多建议，很多点子。但是他们不执行……他们的投入级别是——围观（Bystander）。

  ……

  在遵循敏捷原则的团队里，成员们并不忌讳谈论不同的投入和负责程度——因为这就是现实。但是他们一般有一个原则：
  重大决定由“猪”来定夺

成员们不忌讳谈论不同的投入和负责程度这句话简直是天堂级别的……实际上，大家都会努力让别人觉得自己很投入，主动承认自己并非很努力的人往往会受到他人的侧目。而重大决定由“猪”来定夺的前提显然是，能明显区分出谁是“猪”，谁是“鸡”。

除此之外，根据个人的经验，投入级别会根据成员的现实情况（如其它重大日程或者身体状况）改变，也就是说，投入级别往往是流动的。

总结来说：

• 不忌讳谈论不同的投入和负责程度现实吗，如何才能做到？
• 在投入级别流动的情况下，“猪鸡鹦鹉”的相关理论框架是否与现实相悖？

问题五：如何进行绩效评估

• 原文：第十七章P401

为了更客观地反映员工绩效的不同因素，有些公司实施过二维的评价体系：

• 完成任务维度：主要由团队成员和直接经理商量年度目标，直接经理有较大的自由度决定“超额完成/完成/未完成”的比例。例如大部分成员都可以得到“完成”这一评价。
• 团队贡献维度：还是严格根据人员百分比，评出团队中最好的20％、中间的70％，以及需要改进的10％。

书中提出了绩效评估的可能方案，然而在具体实施上仍存在很多小问题：

• 在各自分工的情况下，如何定夺某个成员的贡献程度？
• 书中也提到过，实际的开发中会出现被忽略/被低估的任务，这部分工作该如何敲定贡献程度？
• 除了具体的工作，一些不具体的工作该不该，该如何纳入贡献度评判标准？（例如PM的沟通任务等等）