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

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

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问
我在这个课程的目标是	学习软件工程原理，锻炼团队开发技巧，与队友协同完成一次项目开发
这个作业在哪个具体方面帮助我实现目标	了解软件工程原理和团队开发技巧

1.如何对项目中的一个功能的重要性进行合理的评价？除了使用频率、安全性、稳定性等因素以外还应该有哪些参考指标？哪些看似不重要的功能一定要实现而哪些有时可以放弃？

    课上罗杰老师给了我们这么一个问题：

如果在某个商业产品中，一个功能只有百万分之一的使用频率，那么你是否希望实现它并且每次客户使用你的产品时不厌其烦的教他们如何使用？
A.根本不打算实现它
B.如果我们没有时间就把它砍掉
C.实现它，但是不需要告诉用户
D.实现它，并且告诉用户

    事实上，我第一反应对应的是浏览器的开发人员工具这一功能（尽管我并不知道实际这个功能的使用频率），显然这一功能绝大多数浏览器的处理方式都是C。因此我当时的想法是在BC中犹豫。
    而实际上书中也有这个题目的另一个版本，它的条件是这样的：

如果一架民用飞机上有需求……

    这两个命题的指向都是飞机的安全功能，因此都是应该实现且告诉用户的功能。然而这个答案并不是由题目中最显眼的使用频率这一指标得到的，而是在第一个版本甚至被隐藏的“飞机上”这一条件得到的。对于飞机的配套设施来说，人命关天的事肯定要不厌其烦的提示；而普通的商业产品，又要考虑用户对某些可有可无却不断弹出提示的功能会非常反感。

2.结对编程真的能实现“不间断的复审”的效果吗？如果不能，其实际效果通常能在结对编程的阶段减少多少复审查出的错误呢？

结对编程让两个人所写的代码不断地处于“复审”的过程，程序员们能够不断地审核，提高设计和编码质量，可以及时发现并解决问题，避免把问题拖到后面的阶段去。

    前文也提到过自我审查不一定有效。开发者由于思维方式的局限性和一致性，很难审查出自己开发中出现的问题是很正常的。同理对于结对编程中交流相当密切的两人而言，他们会不会因为长期“肩并肩、平等地”进行开发工作而落入同一个思维死角或犯相同的错误（例如旁人根本看不懂但二人很习惯的代码风格等），导致对对方工作的审查出现严重的纰漏？这样结对编程的效果真的能达到代码复审的效果吗？

3.“与顾客合作”的含义是否发生了变化？或者说“与顾客合作”在当前已经不是一条重要的准则？

    在敏捷流程与MSF的基本原则中都提到了“与顾客合作”或表意类似的原则，然而如今的软件面向的“顾客”趋向复杂并且用户需求存在冲突。
    例如一个视频内容创作平台，有发布内容并为流量付费的客户，有为高质量内容付费的客户，有为免受广告、推广流量等不想看到的内容侵扰而付费的客户，也有希望广告内容可以被尽可能多的人——包括上述为此付费的人——而付费的客户。这些客户的需求不仅不同，甚至存在激烈的矛盾。而当前也有选择不满足其中任何一方完整需求，而是分化客户，通过其中矛盾获益的例子存在。这是否“与顾客合作”在当今时代已经不再那么适用？还是说这条准则本身的含义发生了变化？

4.在当今时代杀手功能中的辅助需求的重要性是否被过分低估？如果是，对它的处理办法应该抬高至何种级别？如果不是，应该如何在同样都能做出差异化的杀手功能中分出态度截然相反的必要与辅助需求？

功能划分的第四象限即杀手功能且辅助需求——建议采用“维持”的办法，或者现在“不做”，等待好的时机或者小规模实验。

    对于同样属于杀手功能的第一象限（必要需求）和第四象限（辅助需求），书中给出了反差最大的两组态度——前者建议“差异化”即第一优先级，而后者建议“维持”甚至“不做”。这样的态度是否两极分化过于严重？
    在我的思考里，无论是否必要，杀手功能都是指那些可以做出差异化以吸引用户的功能。事实上在如今的存量时代，哪怕是很小的辅助需求似乎也能影响用户的去留。例如某些音乐软件针对小语种歌曲的歌词显示，会额外添加标准且详尽的注音以便听众练习，而其他音乐可能只会添加自动生成的注音或者压根没有。这个功能在我的理解里的确属于第四象限，但显然采用“维持”或“不做”的态度对竞争力的影响并不小，或者至少比第三象限的影响更大。由此是否应该提高第四象限功能的重要性？还是说应该将这样的功能从第四象限中划出？

5.既然软件产品的顾客不一定是软件的直接用户，在从典型用户出发的功能设计应该在何种程度上体现客户的需求？

    既然为软件付费的顾客不一定是软件的直接用户，甚至有可能需要从直接用户的身上榨取属于他们的利益，从典型用户到场景再到任务这套流程中应该在那一阶段以哪种形势插入顾客的需求呢？如果过分估计顾客的需求，是否会反过来影响对典型用户所在场景的模拟产生阻碍？